On Mon, Sep 20 2021, Stuart Henderson <s...@spacehopper.org> wrote: > On 2021/09/19 22:01, k...@openbsd.org wrote: >> http://build-failures.rhaalovely.net/sparc64/2021-09-18/devel/libidn2.log > > It's the usual one again with duplicate symbols. > > Comparing files from the libunistring and libiconv packages from > two builds, one having the problem one not, the only files with any > difference are the static libraries, and after sed'ing them to > replace timestamps of the .o files there is no remaining difference, > so the issue seem to be in the libidn2 build rather than one of the > ports it depends on.
Moving this to a wider audience: In the failing libidn2 build, libunistring.la is built a second time at fake time. I don't know why it's built at all given that there is a dep on converters/libunistring that seems properly detected. I think we want to look at the actual content of the .la file. For some reason our libtool lists libunistring.a twice in "-Wl,-whole-archive /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/gl/.libs/libgnu.a /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a -Wl,-no-whole-archive" -Wl,-whole-archive + the duplicate libunistring.a mention is the direct cause for those duplicate definitions. Trying to mimic the error condition in libidn2 is easy: just touch one of the source files in unistring/ between the make and make fake steps, eg unistring/c-ctype.h. This method also leads to an error on amd64 (dunno if this error has happened on non-sparc64 bulk build clusters) USE_LIBTOOL=gnu doesn't help: it breaks even earlier than base libtool. libunistring.la content in a successful build: # Libraries that this one depends upon. dependency_libs='-R/usr/local/lib -L/usr/local/lib /usr/local/lib/libiconv.la /usr/local/lib/libunistring.la -liconv' failing build: # Libraries that this one depends upon. dependency_libs='-R/usr/local/lib -L/usr/local/lib /usr/local/lib/libiconv.la /usr/ports/pobj/libidn2-2.3.0/libidn2-2.3.0/unistring/libunistring.la -liconv /usr/local/lib/libunistring.la' I guess that the proper way (tm) to solve this would be to understand why unistring/ is rebuilt during kmos' builds. There may be other approaches ranging from smart to blunt. Maybe we can easily a rebuild at fake time in unistring/, even without understanding the problem. > If the build machines are not yet cleaned, can you try > > (0. save a copy of the libidn2 build dir first) See above, you can reproduce it easily. > 1. cleaning libidn2 and attempt a rebuild as-is, is there any change? Worth a try. > 2. rebuilding libidn2 with USE_LIBTOOL=gnu? Hmm, maybe worth a try. *Maybe* USE_LIBTOOL=gnu would avoid a rebuild where base libtool doesn't. But once the rebuild is triggered GNU libtool performs worse. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
