Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#64683 closed defect (fixed)

bind-9.18.0 build fails when bind-9.16.26 is installed

Reported by: laughingtiger Owned by: jmroot (Joshua Root)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: monterey Cc: dluke@…, laughingtiger
Port: bind9

Description

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"


Attachments (1)

main.log (55.9 KB) - added by laughingtiger 3 years ago.
Log

Download all attachments as: .zip

Change History (20)

Changed 3 years ago by laughingtiger

Attachment: main.log added

Log

comment:1 Changed 3 years ago by laughingtiger

Cc: laughingtiger added

comment:2 Changed 3 years ago by 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).

comment:3 Changed 3 years ago by danielluke (Daniel J. Luke)

Port: bind9 added; bind9.18.1 removed

comment:4 Changed 3 years ago by danielluke (Daniel J. Luke)

Summary: bind-9.18.0 build failsbind-9.18.0 build fails when bind-9.16.26 is installed

comment:5 Changed 3 years ago by 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"

comment:6 Changed 3 years ago by danielluke (Daniel J. Luke)

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

comment:7 Changed 3 years ago by 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).

comment:8 in reply to:  7 ; Changed 3 years ago by 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.

comment:9 in reply to:  8 ; Changed 3 years ago by 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?

comment:10 in reply to:  9 Changed 3 years ago by 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+}.

comment:11 Changed 3 years ago by 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.

comment:12 Changed 3 years ago by danielluke (Daniel J. Luke)

s/look/lgpl (thanks autocorrect)

comment:13 Changed 3 years ago by jmroot (Joshua Root)

Owner: set to jmroot
Resolution: fixed
Status: newclosed

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@…>

comment:14 in reply to:  13 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by 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.

comment:16 in reply to:  15 Changed 3 years ago by 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 :) ).

comment:17 Changed 2 years ago by 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

comment:18 in reply to:  17 Changed 2 years ago by 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 :) ).

comment:19 Changed 2 years ago by jmroot (Joshua Root)

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

Note: See TracTickets for help on using tickets.