Hi David, thanks for clarification . Guess we can just remove the __ now and avoid one lookup.
I'll open a bug for this . Best regards, Matthias > On 18/12/2019 10:43 pm, David Holmes wrote: > > On 18/12/2019 7:43 pm, Baesken, Matthias wrote: > >> Hello, I recently worked a bit with the "verbose debugging > >> information" output about operations of the dynamic linker (to > >> sort out some lib loading issues) . > >> See > >> > >> https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html > >> http://man7.org/linux/man-pages/man8/ld.so.8.html > >> > >> about the LD_DEBUG flag. > >> > >> > >> By chance I noticed the following output when running a trivial Java > >> program : > >> > >> LD_DEBUG=libs /linuxx86_64/output-jdk- > test/images/jdk/bin/java Test > >> . . . > >> 12241: > >> 12241: > >> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol > >> lookup error: undefined symbol: > >> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) > >> 12241: > >> > >> What is wrong with > >> "Java_jdk_internal_reflect_Reflection_getCallerClass" ? > >> Does the error message occur because of the naming > >> Java_jdk_internal_reflect_Reflection_getCallerClass__ with the added > >> "__" at the end of the method (Reflection.c) ? > > > > That definitely looks like an error in the C source to me. The ending > > "__" should not be there. How is this working ?? > > Ah! It is a remnant of when there were overloads of getCallerClass. The > "__" should be followed by the signature - which is empty in this case. > So IIRC the lookup will first try to use the short name (without the > trailing "__") which will fail, then it will use the long name which > will succeed. > > It should be fixed so we don't waste time doing two lookups. > > David > > > > > David > > > >> > >> > >> Best regards, Matthias > >> > >>
