Re: Link (ordering??) problem

["Dr. David Alan Gilbert" <dave@xxxxxxxxxxx>]

* Michael Stahl (michael.stahl@xxxxxxxxxxxxx) wrote:
> 
> 
> On 20/03/2025 01:13, Dr. David Alan Gilbert wrote:
> > Hi,
> >    On my newly upgraded Fedora 41->42 beta desktop I'm seeing the link
> > error:
> > 
> > $ make debug=t
> > [LNK] Library/libsofficeapp.so
> > /discs/fast/core/desktop/source/lib/init.cxx:6354: error: undefined reference to 'ublock_getCode_77'
> > collect2: error: ld returned 1 exit status
> > make[1]: *** [/discs/fast/core/desktop/Library_sofficeapp.mk:10: /discs/fast/core/instdir/program/libsofficeapp.so] Error 1
> > 
> > $ rpm -qa|grep icu
> > libicu-76.1-4.fc42.x86_64
> 
> ...
> 
> > where the interesting bit is:
> >   -Wl,--start-group  -L/usr/lib64/pkgconfig/../../lib64 -ldbus-1  -L$W/UnpackedTarball/icu/source/lib -licui18n  -L$W/UnpackedTarball/icu/source/lib -licuuc  -L$W/UnpackedTarball/curl/lib/.libs -lcurl   -Wl,--end-group
> > 
> > so we've got -L/usr/lib64/pkgconfig/../../lib64 before -L$W/UnpackedTarball/icu/source/lib
> > nd /usr/lib64/libicuuc.so points to the .76.1 version
> 
> that is indeed a problem, it is obfuscated -L/usr/lib64 and that should
> never be explicitly on the link command as it will cause exactly this kind
> of problem
> 
> we already try to filter it in configure.ac:
> 
> >             case "$f" in
> >                 # let's start with Fedora's paths for now
> >                 -L/lib|-L/lib/|-L/lib64|-L/lib64/|-L/usr/lib|-L/usr/lib/|-L/usr/lib64|-L/usr/lib64/)
> >                     # ignore it: on UNIXoids it is searched by default anyway
> >                     # but if it's given explicitly then it may override other paths
> >                     # (on macOS it would be an error to use it instead of SDK)
> >                     ;;
> 
> but it was cunningly obfuscated so the filtering doesn't work for you.
> 
> you can try to search in config_host.mk which system library is responsible.

export DBUS_LIBS=$(gb_SPACE) -L/usr/lib64/pkgconfig/../../lib64 -ldbus-1

hmmm

> imho it's a bug in the packageconfig file of that system library, these
> should never contain system paths that are searched by default anyway.

dg@dalek:~$ cat /usr/lib64/pkgconfig/dbus-1.pc
prefix=${pcfiledir}/../..
includedir=${prefix}/include
libdir=${prefix}/lib64
....

it looks like the dbus-1.pc (and the librsvg-2.0.pc) are the only two
pkgconfigs that do that.

Dave

> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/