[ARTEMIS-2181] libartemis-native-64.so: undefined symbol: closeDumbHandlers, when recompiling artemis-native on Fedora 29

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Component/s: Broker

Environment

fc29, gcc 8.2.1

• Assignee: Unassigned
• Reporter: Jiri Daněk
• Created: 24/Nov/18 20:46
• Updated: 14/Mar/19 18:29
• Resolved: 13/Dec/18 16:57

Description

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

libartemis-native-64.so: undefined symbol: closeDumbHandlers

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.

Steps to understand/simulate the issue.

Use Fedora 29 or Ubuntu.

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

Create a file

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

Compile it and list the symbols

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 ~]$

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

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

The native.c file is created and compiled, and symbols are listed, as above

[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 ~]$

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.

Issue Links

• links to: GitHub Pull Request #2440