ld.so mysterious behavior
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Wed Aug 7 20:05:44 GMT 2024
On 07/08/24 16:54, Olivier Langlois wrote:
> On Wed, 2024-08-07 at 15:02 -0400, Olivier Langlois wrote:
>> I have looked into elf/rtld.c source code.
>>
>> I am going to give you time to reply if you concur with my diagnostic
>> but this seems like I have stumbled into a possible ld bug.
>>
>> from my quick code review, it seems that the only criteria that the
>> code is using to not bypass a needed dependency is if the library
>> name
>> is not in the preloaded libs list.
>>
>> In my case it appears to be there. What is the problem?
>> The preloaded lib path length?
>> It is an absolute path?
>>
>> I forgot to include this detail in my first email:
>>
>> $ ld.so --version
>> ld.so (GNU libc) stable release version 2.40.
>> Copyright (C) 2024 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.
>> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>> PARTICULAR PURPOSE.
>>
>> Fortunately, I have a procedure that anyone can use to reproduce the
>> issue.
>>
>> let me know if you think this is bug material justifying opening a
>> bug
>> report.
>>
> as a follow up to my issue, I did move the bazel so file at the exact
> same location than the successfully loading lib.
>
> same path, different result. So the conclusion is that there is
> definitely something in the lib file that makes ld.so behave
> differently.
>
> I have tried use readelf -We to see if I could not spot anything that
> stands out that would explain what I see. I did not see anything
> special.
>
> Best case scenario, ld does the right thing but maybe there is a
> missign debug log statement somewhere that would help understand the
> situation.
>
> My best educated guess it is that the decision is taken somewhere in
> _dl_map_object_deps() (elf/dl-deps.c) but this is a very hard function
> to read for the uninitiated eye...
>
As Florian has pointed out, it is mostly likely a missing DT_SONAME:
$ cat lib.c
int foo (void) { return 42; }
$ gcc -Wall -fPIC -shared lib.c -o no-soname/libtest.so
$ gcc -Wall -fPIC -shared lib.c -o soname/libtest.so -Wl,--soname,libtest.so
$ gcc -Wall main.c -L`pwd`/soname -ltest -o main
$ LD_PRELOAD=soname/libtest.so ./main; echo $?
42
$ LD_PRELOAD=no-soname/libtest.so ./main
./main: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory
More information about the Libc-help
mailing list