[
https://issues.apache.org/jira/browse/ARTEMIS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720382#comment-16720382
]
ASF GitHub Bot commented on ARTEMIS-2181:
-----------------------------------------
Github user jdanekrh commented on the issue:
https://github.com/apache/activemq-artemis/pull/2440
Works on my machine...
> libartemis-native-64.so: undefined symbol: closeDumbHandlers, when
> recompiling artemis-native on Fedora 29
> ----------------------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-2181
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2181
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: fc29, gcc 8.2.1
> Reporter: Jiri Daněk
> Priority: Major
>
> When I compile libartemis-native using a new gcc (such as that in fedora 29),
> it will then not load from System.loadLibrary, due to error
> {noformat}
> libartemis-native-64.so: undefined symbol: closeDumbHandlers
> {noformat}
> I believe that the reason is a changed behavior of newer compilers for inline
> functions, compared to older ones, such as the one in RHEL 7, where all works
> just fine.
> h3. Steps to understand/simulate the issue.
> Use Fedora 29 or Ubuntu.
> {noformat}
> [fedora@jd-testboss ~]$ gcc --version
> gcc (GCC) 8.2.1 20181105 (Red Hat 8.2.1-5)
> Copyright (C) 2018 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.
> {noformat}
> Create a file
> {code}
> [fedora@jd-testboss ~]$ cat native.c
> double square(double x) { return x*x; }
> static inline double sisquare(double x) { return x*x; }
> inline double isquare(double x) { return x*x; }
> extern inline double eisquare(double x) { return x*x; }
> int call_square() {
> sisquare(1);
> isquare(1);
> eisquare(1);
> square(1);
> }
> {code}
> Compile it and list the symbols
> {noformat}
> gcc -c -fPIC native.c -o native.o; gcc native.o --shared -o libnative.so
> [fedora@jd-testboss ~]$ nm libnative.so
> 0000000000001158 T call_square
> 0000000000004030 b completed.7286
> w __cxa_finalize@@GLIBC_2.2.5
> 0000000000001060 t deregister_tm_clones
> 00000000000010d0 t __do_global_dtors_aux
> 0000000000003e10 t __do_global_dtors_aux_fini_array_entry
> 0000000000003e18 d __dso_handle
> 0000000000003e20 d _DYNAMIC
> 0000000000001143 T eisquare
> 0000000000001143 t eisquare.localalias.0
> 0000000000001194 t _fini
> 0000000000001110 t frame_dummy
> 0000000000003e08 t __frame_dummy_init_array_entry
> 0000000000002100 r __FRAME_END__
> 0000000000004000 d _GLOBAL_OFFSET_TABLE_
> w __gmon_start__
> 0000000000002008 r __GNU_EH_FRAME_HDR
> 0000000000001000 t _init
> U isquare
> w _ITM_deregisterTMCloneTable
> w _ITM_registerTMCloneTable
> 0000000000001090 t register_tm_clones
> 000000000000112e t sisquare
> 0000000000001119 T square
> 0000000000004030 d __TMC_END__
> [fedora@jd-testboss ~]$
> {noformat}
> As you can see, there is one Undefined symbol in the library, {{isquare}}.
> When I try to load this from java, using System.loadLibrary, I get link error
> there.
> Now, when the same is done on RHEL 7
> {noformat}
> [jdanek@dhcp-144-231 ~]$ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
> Copyright (C) 2015 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.
> {noformat}
> The native.c file is created and compiled, and symbols are listed, as above
> {noformat}
> [jdanek@dhcp-144-231 ~]$ nm libnative.so
> 0000000000201030 B __bss_start
> 000000000000076a T call_square
> 0000000000201030 b completed.6355
> w __cxa_finalize@@GLIBC_2.2.5
> 0000000000000610 t deregister_tm_clones
> 0000000000000680 t __do_global_dtors_aux
> 0000000000200e00 t __do_global_dtors_aux_fini_array_entry
> 0000000000200e10 d __dso_handle
> 0000000000200e18 d _DYNAMIC
> 0000000000201030 D _edata
> U eisquare
> 0000000000201038 B _end
> 00000000000007a4 T _fini
> 00000000000006c0 t frame_dummy
> 0000000000200df8 t __frame_dummy_init_array_entry
> 00000000000008b0 r __FRAME_END__
> 0000000000201000 d _GLOBAL_OFFSET_TABLE_
> w __gmon_start__
> 00000000000007b8 r __GNU_EH_FRAME_HDR
> 00000000000005a0 T _init
> 0000000000000743 T isquare
> w _ITM_deregisterTMCloneTable
> w _ITM_registerTMCloneTable
> 0000000000200e08 d __JCR_END__
> 0000000000200e08 d __JCR_LIST__
> w _Jv_RegisterClasses
> 0000000000000640 t register_tm_clones
> 000000000000071c t sisquare
> 00000000000006f5 T square
> 0000000000201030 d __TMC_END__
> [jdanek@dhcp-144-231 ~]$
> {noformat}
> It can be seen there are no undefined symbols with the old gcc.
> I am not filling the "Affects Version/s" field, because the correctly built
> .so is checked into git and rebuilding the native lib is not part of the
> normal build. Meaning nobody is really affected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)