bind-9.18.0 build fails when bind-9.16.26 is installed

[laughingtiger]

Running port selfupdate the latest bind9.18.0 build fails with this in the log…

:info:build make[3]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_bind9/bind9/work/bind-9.18.0/doc/misc'
:info:build   CC       cfg_test-cfg_test.o
:info:build   CCLD     cfg_test
:info:build Undefined symbols for architecture x86_64:
:info:build   "_isc_mem_create", referenced from:
:info:build       _main in cfg_test-cfg_test.o
:info:build   "_isc_mem_destroy", referenced from:
:info:build       _main in cfg_test-cfg_test.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[3]: *** [cfg_test] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_bind9/bind9/work/bind-9.18.0/doc/misc'
:info:build make[2]: *** [all-recursive] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_bind9/bind9/work/bind-9.18.0/doc'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_bind9/bind9/work/bind-9.18.0'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_bind9/bind9/work/bind-9.18.0'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_bind9/bind9/work/bind-9.18.0" && /usr/bin/make -j4 -w all 
:info:build Exit code: 2
:error:build Failed to build bind9: command execution failed
:debug:build Error code: CHILDSTATUS 94187 2
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"

[laughingtiger]

Log

[danielluke (Daniel J. Luke)]

Looks like a quick workaround is to uninstall the previous version of bind9 before building the new one (or wait for the buildbot to build it and you'll get the archive).

[danielluke (Daniel J. Luke)]

... and it won't end up as an archive because - "bind9" is not distributable because its license "MPL" conflicts with license "GPL-3" of dependency "libunistring"

[danielluke (Daniel J. Luke)]

it's actually MPL-2 so I've updated the port and triggered some rebuilds

[danielluke (Daniel J. Luke)]

forcing a rebuild doesn't actually get it to re-evaluate whether it's distributable or not (if the previous build succeeded). I bumped the revision and then bothered to check and MPL-2 is still considered conflicting with gpl-3 for MP archives. I guess there's nothing to do there. I'll try to set aside some time to look at getting the build to work when a previous version is already installed. (Insert continual wish that trace mode would be the default way to build everything to just avoid this problem).

[jmroot (Joshua Root)]

Replying to danielluke:

forcing a rebuild doesn't actually get it to re-evaluate whether it's distributable or not (if the previous build succeeded).

Distributability is in fact re-evaluated on every commit, the build is just skipped if the port's distributability hasn't changed and it was successfully built before.

[danielluke (Daniel J. Luke)]

Replying to jmroot:

Distributability is in fact re-evaluated on every commit, the build is just skipped if the port's distributability hasn't changed and it was successfully built before.

That’s what I get for assuming things instead of looking at the source :)

FSF says MPL-2 is gpl compatible (​https://www.gnu.org/licenses/license-list.en.html) - should we update the license code, or is there some reason that I don’t know of that they are actually incompatible?

[jmroot (Joshua Root)]

Replying to danielluke:

FSF says MPL-2 is gpl compatible (​https://www.gnu.org/licenses/license-list.en.html) - should we update the license code, or is there some reason that I don’t know of that they are actually incompatible?

It's slightly more complicated than that: MPL-2 is optionally GPL-compatible by way of a clause saying (effectively) that you can use the LGPL instead if the project authors didn't opt out of that clause. We list the license for projects that opt out and are thus available under the MPL itself only as MPL-2, while projects that don't opt out should say {MPL-2 LGPL-2.1+}.

[danielluke (Daniel J. Luke)]

Looks like gpl,look, and agpl (​https://gitlab.isc.org/isc-projects/bind9/-/blob/main/LICENSE). I’ll update the port later today.

[danielluke (Daniel J. Luke)]

s/look/lgpl (thanks autocorrect)

[jmroot (Joshua Root)]

In 2c676fdf6d3a41682e0bb239808034fd031c32b8/macports-ports (master):

bind9: fix include flag ordering (​https://github.com/macports/macports-ports/pull/14048)

Closes: #64683

Co-authored-by: Daniel J. Luke <dluke@…>

[danielluke (Daniel J. Luke)]

Replying to jmroot:

bind9: fix include flag ordering (#14048)

Did you want to try to push the atomics and flag_order patches upstream? They weren't receptive to the build fix for having MACOSX_DEPLOYMENT_TARGET set (possibly partially because I didn't initially identify that as the source of the problem), but I'm happy to try with these if you don't want to.

[jmroot (Joshua Root)]

I'd get to upstreaming them eventually, but by all means feel free to beat me to it. The Makefile.am changes are good to go as-is. The atomic stuff is a bit dicier in terms of upstream. They might want to check if a clang version that has the builtins is being used, which is harder than it sounds because Apple's versioning scheme is different to llvm.org's and AFAIK there's no feature test macro for those builtins. In my testing, Apple clang 425.0.28 offers the builtins but fails with an internal error when compiling the code that uses them, while Apple clang 77 doesn't claim to have them. The const thing is definitely a legitimate issue that they'll need to fix in order to support C11-compliant compilers, but casting just to remove the const is kind of gross. But the only other expedient fix would have been to remove const in a bunch of places where it is being applied to entire structs and apart from this issue is quite correct to use.

[danielluke (Daniel J. Luke)]

Replying to jmroot:

I'd get to upstreaming them eventually, but by all means feel free to beat me to it.

the Makefile changes are upstreamed, I didn't attempt to upstream the atomic stuff (it's unclear to me if they would accept it or not, but it's probably worthwhile to try - I'm hoping you get to it before I decide to try :) ).

[jmroot (Joshua Root)]

It looks like upstream's plan for future versions is to require C11 atomics, so I won't bother trying to get them to use the gcc-style ones with old clangs. I reported the const issue here: ​https://gitlab.isc.org/isc-projects/bind9/-/issues/3370

[danielluke (Daniel J. Luke)]

Replying to jmroot:

It looks like upstream's plan for future versions is to require C11 atomics, so I won't bother trying to get them to use the gcc-style ones with old clangs. I reported the const issue here: ​https://gitlab.isc.org/isc-projects/bind9/-/issues/3370

Looks like you got a similar aggressively unhelpful response (at least I'm not the only one :) ).

[jmroot (Joshua Root)]

At least they accepted the fallthrough patch. Maybe the trick is to work in a C2x feature. :)