On Fri, 14 Apr 2023 00:54:22 GMT, Jiangli Zhou <jian...@openjdk.org> wrote:
>>> I'm not familiar with the details of symbol scoping and linkage with >>> libraries, but I would have hoped there was a way to have symbols like this >>> shareable throughout the code that comprises the library without exposing >>> them to users of the library. It used to be IIRC only functions we listed >>> in the mapfiles were exposed, and these days we use explicit attributes to >>> export them. Is there not some equivalent thing for data? >> >> If my understanding is correct the mapfile is for exported symbols, which >> are in the export table. Those symbols can be dynamically looked up, e.g. >> via dlsym. By default, '-fvisibility=hidden' is used >> (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). >> The symbols are '.hidden' by default if not exported. E.g. jmm_interface is >> 'hidden' as objdump shows below. However, the linker error that we are >> seeing here for statically linking the libraries together is a different >> issue. The linker founds multiple ones in different object files, hence the >> failures. We'd have to change to use internal linkage for the affect >> variables to resolve the failure if feasible (without renaming). Please let >> me know if I'm missing anything. >> >> objdump: >> ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: >> not a dynamic object >> SYMBOL TABLE: >> 0000000000000000 l df *ABS* 0000000000000000 management_ext.c >> ... >> 0000000000000000 g F .text 0000000000000068 JNI_OnLoad >> 0000000000000008 g O .bss 0000000000000008 .hidden jvm >> 0000000000000000 *UND* 0000000000000000 JVM_GetManagement >> 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface >> 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version > >> If we were to do this then we should have a naming convention of some kind >> e.g. `<lib-name>_<var-name>` but it strikes me as wrong as the code >> shouldn't need to know what library it is part of. In this case we do >> something as a simple point-fix, but to me it says there is a bigger problem. > > Using a naming convention as you suggested sounds good. I'm not completely > clear what's the bigger problem though. Could you please clarify? David, I was doing some more reading on the topic for our discussion in the thread and just found this: https://stackoverflow.com/questions/61663118/avoid-multiple-definition-linker-error-when-not-using-the-redefined-symbols. It has some good information on the symbol collision issue. It describes using 'objcopy' to localize or redefine symbols. It also mentions '--allow-multiple-definitions', which I didn't know before. However, '--allow-multiple-definitions' doesn't seem to be a good approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166209365
