[ 
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)

Reply via email to