Static linkage of a program not otherwise using pthreads fails under Ubuntu 20.04

[bobfriesenhahn]

Using the development version of JasPer (which now uses thread APIs) I find that a statically-linked program which is not otherwise using pthreads will fail to link due to unresolved symbols:

/usr/bin/ld: /usr/local/lib/libjasper.so: undefined reference to `pthread_getspecific'
/usr/bin/ld: /usr/local/lib/libjasper.so: undefined reference to `pthread_key_create'
/usr/bin/ld: /usr/local/lib/libjasper.so: undefined reference to `pthread_once'
/usr/bin/ld: /usr/local/lib/libjasper.so: undefined reference to `pthread_setspecific'
/usr/bin/ld: /usr/local/lib/libjasper.so: undefined reference to `pthread_key_delete'

Adding -pthread to the build options for the statically-linked program solves the problem.

To solve this problem, the JasPer shared library should assure that it has an implicit dependency on -pthread (not expecting the linked program to provide this) so that linkage succeeds by default on systems supporting implicit dependencies. If JasPer is built as a static library, then there is no solution other than users adding the needed -pthread since static libraries do not support implicit dependencies.

[mdadams]

This is very strange since Ubuntu 20.04 is used as one of the configurations in the JasPer CI testing, which is done on every commit. So, JasPer has been working in this environment. Maybe this is due to the JasPer application programs having a direct dependency on the pthread library? In any case, I did see a target_link_libraries directive that did not list the threading libraries used. I have added this and committed the change to master. See commit 4a55343. If this does not fix the problem, please let me know what is printed for "Threading library:" during the configuration stage of cmake.

[bobfriesenhahn]

On Tue, 23 Nov 2021, Michael Adams wrote: This is very strange since Ubuntu 20.04 is used as one of the configurations in the JasPer CI testing, which is done on every commit. So, JasPer has been working in this environment. Maybe this is due to the JasPer application programs having a direct dependency on the pthread library? In any case, I did see a

Yes, if the dependent program is linked using -pthread then it will work as is (was?). However, if the JasPer library is linked using -pthread (so that ldd shows it as a depencency) then that should allow non-pthread programs to work as before due to implicit linkage dependencies (which are turned into implicit run-time dependencies). Not all systems support implicit linkage dependencies. Some systems only support implicit run-time dependencies. Bob -- Bob Friesenhahn ***@***.***, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[mdadams]

So, just to be clear, it works now, right?

[bobfriesenhahn]

On Tue, 23 Nov 2021, Michael Adams wrote: So, just to be clear, it works now, right?

I just checked, and YES, it works now! This won't fix all usages but it will certainly make Linux and other systems supporting implicit dependencies happier. Bob -- Bob Friesenhahn ***@***.***, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

[mdadams]

Thank you for the confirmation that the bug is now fixed.