The ELF specification indicates symbol resolution should be breadth first, not depth first. The dl-deps.c: dl_build_locale_scope function is processing in a depth first mode. This is causes certain symbols to be incorrectly reported when LD_TRACE_PRELINKING=1 is enabled. In the 'cross' prelink emulated RTLD, we had a similar bug and fixed the issue. glibc has the same problem.
Created attachment 9456 [details] Patch to fix the issue Attached is a patch that fixes the issue. This patch was independently developed by me. Wind River (my employer) has a copyright assignment on file with the FSF that covers glibc.
Yocto Project bug 9131 covers this issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9131 This also appears to have been reported to the libc mailing list as well: https://sourceware.org/ml/libc-alpha/2016-05/msg00034.html
FWIW if prelink is removed, this issue becomes obsolete as the code this fixes is removed.
(In reply to richard.purdie from comment #3) > FWIW if prelink is removed, this issue becomes obsolete as the code this > fixes is removed. That's kind of a useless tautology. Of course it's obsolete if it isn't used or is removed. I am always befuddled when bug reports are completely ignored when they have a succinct summation of issues, a clear violation occurring, and even provision of a fix. It would be nice to know why glibc has decided to be knowingly non-ELF compliant for at least 6 years, on a violation ongoing for at least 20 years ( http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies https://github.com/bminor/glibc/commit/32e6df3621edc5067dfd6e87a387e1751f67f708 ).
(In reply to Emma Jane Bonestell from comment #4) > (In reply to richard.purdie from comment #3) > > FWIW if prelink is removed, this issue becomes obsolete as the code this > > fixes is removed. > > That's kind of a useless tautology. Of course it's obsolete if it isn't used > or is removed. > > I am always befuddled when bug reports are completely ignored when they have > a succinct summation of issues, a clear violation occurring, and even > provision of a fix. It would be nice to know why glibc has decided to be > knowingly non-ELF compliant for at least 6 years, on a violation ongoing for > at least 20 years ( > http://www.sco.com/developers/gabi/latest/ch5.dynamic. > html#shobj_dependencies > https://github.com/bminor/glibc/commit/ > 32e6df3621edc5067dfd6e87a387e1751f67f708 ). Mainly because if you have followed up the prelink discussion recently done on libc-alpha you would see this is a very rarely used feature, that requires additional setup to actually test is, and that has bitrotten due lack of maintanance. Also, prelink project itself is not activelly maintained, Joseph, for instance, noted that a fix for aarch64 was never incorporated on prelinking-ng repo. Also, we have a limited volunters that is focused on diferent projects.
(In reply to Adhemerval Zanella from comment #5) > > Mainly because if you have followed up the prelink discussion recently done > on libc-alpha you would see this is a very rarely used feature, that > requires additional setup to actually test is, and that has bitrotten due > lack of maintanance. Also, prelink project itself is not activelly > maintained, Joseph, for instance, noted that a fix for aarch64 was never > incorporated on prelinking-ng repo. > > Also, we have a limited volunters that is focused on diferent projects. I misunderstood that it has already been marked for removal. And yes, I do understand the nature of open source/free software, though that's why I limited it to when one has been essentially handed the solution. A bit disappointing as I've been tinkering with updating the SLINKY linker, etc., to work on newer kernels, and it fundamentally depends on preloading. I suppose patching back in preloading in addition to this patch won't be anymore annoying than it already was :) .
Note that prelinking and preloading are two different things.
(In reply to richard.purdie from comment #7) > Note that prelinking and preloading are two different things. Yes, a mistake on my part. I did mean prelinking, not preloading, above.
(In reply to Emma Jane Bonestell from comment #6) > (In reply to Adhemerval Zanella from comment #5) > > > > Mainly because if you have followed up the prelink discussion recently done > > on libc-alpha you would see this is a very rarely used feature, that > > requires additional setup to actually test is, and that has bitrotten due > > lack of maintanance. Also, prelink project itself is not activelly > > maintained, Joseph, for instance, noted that a fix for aarch64 was never > > incorporated on prelinking-ng repo. > > > > Also, we have a limited volunters that is focused on diferent projects. > > I misunderstood that it has already been marked for removal. And yes, I do > understand the nature of open source/free software, though that's why I > limited it to when one has been essentially handed the solution. I only have been aware of this issue when it was pinged on libc-alpha some weeks before 2.35 release and then I restarted the prelink discussion. It turned out that prelink support is in a worse condition than I expected [1][2], which make fixing this bug not really an useful (it would be used in a limited environment, and it would require additional work such tests and checking on some architectures). [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135520.html [2] https://sourceware.org/pipermail/libc-alpha/2022-January/135520.html > > A bit disappointing as I've been tinkering with updating the SLINKY linker, > etc., to work on newer kernels, and it fundamentally depends on preloading. > I suppose patching back in preloading in addition to this patch won't be > anymore annoying than it already was :) .