Order of library search paths

[Julien ÉLIE]

Hi all,

While checking that the latest LibreSSL version works fine with INN, I 
faced an issue with the order library search paths appear when building INN.

As a matter of fact, the build failed with:

libtool: link: gcc -pie -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -o .libs/nnrpd article.o auth-ext.o cache.o commands.o group.o 
line.o list.o misc.o newnews.o nnrpd.o perl.o perm.o post.o python.o 
sasl.o tls.o track.o zlib.o /home/news/work/inn/main/lib/perl.o -Wl,-E 
-fstack-protector-strong /home/news/work/inn/main/lib/canlock.o 
/home/news/work/inn/main/storage/.libs/libinnstorage.so 
/home/news/work/inn/main/history/.libs/libinnhist.so 
/home/news/work/inn/main/lib/.libs/libinn.so -ldb -L/usr/local/lib 
-L/usr/lib/x86_64-linux-gnu/perl/5.36/CORE -lperl -lpthread -lcrypt 
-L/usr/lib/x86_64-linux-gnu -lpython3.11 -ldl -lm -lcanlock 
-L/home/news/work/libressl/3.9.0/lib -lssl -lcrypto -lsasl2 -lz 
-Wl,-rpath -Wl,/home/news/lib

/usr/bin/ld: tls.o: in function `tls_init_serverengine':
/home/news/work/inn/main/nnrpd/tls.c:609: undefined reference to 
`SSL_CTX_set1_groups_list'


The culprit is "-L/usr/lib/x86_64-linux-gnu" coming from Python, listed 
before "-L/home/news/work/libressl/3.9.0/lib" where I built LibreSSL.

If I change the order of the search paths, or even remove the one of 
Python, the build is OK.

Other search paths added at build time are:

   -L/usr/lib/x86_64-linux-gnu/perl/5.36/CORE
   -L/usr/lib/x86_64-linux-gnu/mit-krb5

which both are specific, and do not interfere with other programs.

I did not notice the issue until now as Python 3.11 advertises on Debian 
bookworm "-L/usr/lib/x86_64-linux-gnu" as LIBDIR whereas Python 3.9 
advertises on Debian bullseye "-L/usr/lib/x86_64-linux-gnu/python3.9" as 
LIBDIR.  So I had not the problem when testing LibreSSL nor any other 
program.


I am not under the impression it is a regression in Python nor in its 
Debian packaging.  "-L/usr/lib/x86_64-linux-gnu" as LIBDIR is fine as 
libpython3.11.so is in this directory.

Yet, how could we solve the build issue?
Any program may somehow add a search path, so do we need to strip 
explicit -L search pathes when they are in the default search pathes of 
the linker?  It seems a bit overkill and tedious to do...

If someone has any suggestion, I would be happy to hear.

-- 
Julien ÉLIE

« – I see the world didn't end yesterday.
   – Are you sure? » (Alan Moore, _Watchmen_)