Hmm. Fyi, your comparison is crossing branches (master to next).
I can see that indeed the last success was on a Trusty environment, while the failures begin on Xenial. Note that there was a break of a few months between runs during which the switch to Xenial occurred.
Trusty I see actually was released with PulseAudio v4.x, and that’s the version that was being installed by APT according the the log (according to the package version). New function symbols were introduced in PA since v4.x which are made use of by my library, and missing symbols in the installed system library result in link failure…
That confuses me as to why on earth things worked at all on the Trusty setup… It would have needed to have PA v8.0+ for any cargo test --all command (which involves linking unlike build) to be successful at all…
Regarding my build.rs falling back to a default value: When I started the project I did not have the PA dev package installed, thus no *.pc files for the PA system libs, thus relying upon pkg-config was a no go. When pkg-config support was added, that was left as a fallback, for those similarly lacking the dev package.
Sidenote: perhaps adding installation of the AP dev package into the travis environment to get the *.pc files would be a good move?
Regarding changes and building with different flags:
-
as pointed out above, you’re comparing master with next, and next indeed has significant changes to the flags, but there are far fewer such changes on master, which also is failing.
-
up to the point in the commit history of the last success i was making a mistake with my use of Cargo workspaces wrt. feature flags. The Cargo workspace was very minimal, just referencing the enclosed crates), and as you could see in the travis script I was using features with the expectation that they would just be passed on to them.
I fixed this (on master) by changing the workspace to a full lib-crate model, which depended on the enclosed crates and mapped the feature flags to them. This change was pushed recently, after the Xenial upgrade and is included in the failures.
if we review how things worked though at the point of the last success, you can see in the log that the pa_v12_compatibility flag is getting passed through, enabling PA v12 features, which worked on the old Trusty setup. Regardless, we come back to the fact that we were linking successfully code that uses PA v8+ symbols (the minimum supported version) on an environment apparently with only PA v4.x, which makes no sense…
So did the environment really have PA v4.x, or did it actually somehow have PA v12? If the former, then I don’t understand at all why cargo test commands (which involved linking) were successful, compared to now where the builds are failing complaining about the missing symbols.
Going back to build.rs and use of pkg-config, it surely cannot be the case that in the old setup this stuff was “bailing out” cleanly in seeing too old a version of PA. There is no dev package installed in the environment, so the pkg-config check would fail, going back to the basic fallback. It should thus find the lib, but fail to link due to missing symbols, just as seen in the failures.
