When C++ libraries are built with libtool, they are linked with -nostdlib by default, which then causes flags such as -pthread to be ignored, resulting in shared libraries that do not have all necessary DT_NEEDED entries.
This happens to graphics/ilmbase, where libIlmThread.so is linked with -nostdlib -pthread and ends up not linking against libthr.so. With the recent work in HEAD to make lld use --no-allow-shlib-undefined by default when linking executables, we end up with failures like the one in graphics/krita (http://beefy12.nyi.freebsd.org/data/head-amd64-default/p496405_s345355/logs/krita-4.1.8_1.log):
ld: error: /usr/local/lib/libIlmThread.so: undefined reference to pthread_create
c++: error: linker command failed with exit code 1 (use -v to see invocation)
There are some old reports from Linux distros complaining about the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=661333 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468555
Distros have since just started patching ilmbase to make it use -lpthread instead of -pthread when linking: https://git.archlinux.org/svntogit/packages.git/tree/trunk/ilmbase-2.0.1-no_undefined.patch?h=packages/ilmbase and https://salsa.debian.org/debian-phototools-team/ilmbase/blob/master/debian/rules#L29, for example.
I wonder if we should change the libtool port, or just start patching ilmbase as well.
It won't be easy to remove -nostdlib from libtool. Linking is usually done with the C compiler which doesn't add -lc++ so libtool first obtains the list of libraries added by the C++ compiler (using -v) and then passes that list with -nostdlib to the C compiler. I suppose it may be possible to patch libtool to translate -pthread into -lpthread. This would have to be done by USES=libtool, not by a patch to the libtool port. It's certainly easier to patch ilmbase instead.
Created attachment 203090 [details]
patch to explicitly add -pthread -lpthread when linking IlmThread
Raphael, Tijl, is this what you have in mind as patch against graphics/ilmbase?
(In reply to Matthias Andree from comment #2)
> Created attachment 203090 [details]
> patch to explicitly add -pthread -lpthread when linking IlmThread
> Raphael, Tijl, is this what you have in mind as patch against
What Debian does is just set PTHREAD_LIBS in its equivalent of CONFIGURE_ENV, which also solves the issue here (and you wouldn't need to patch Makefile.in).
-lpthread comes in the linker command-line a bit earlier than it would with -pthread, but I think it's still fine.
A commit references this bug:
Date: Mon Mar 25 12:19:31 UTC 2019
New revision: 496818
Link against -lpthread to prepare for linker changes
Reported by: rakuco@
A commit references this bug:
Date: Mon Mar 25 13:00:23 UTC 2019
New revision: 496820
Simplify pthread + libtool workaround.
Improve upon r496818. Instead of setting both MAKE_ENV and patching ilmthread's
Makefile, just make sure PTHREAD_LIBS is set a configuration time. This is what
Debian does, and it achieves the same solution with fewer lines.
While here, add an explanation for why we need this.
Approved by: mandree (maintainer)
All versions of graphics/tesseract are affected by this as well. See comments in bug 234285 (which this bug should depend on) as well as the upstream github issue:
graphics/tesseract's issue is unrelated to libtool, I've posted a comment on that GitHub bug.