Linking libjulia.so yields undefined symbol in 1.6.0

[Clonkk]

Hello,

I tried upgrading to Julia 1.6.0 for my Nimjl package but I get error when linking to libjulia.so.1.6.

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_symbol' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_string_ptr' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_atexit_hook' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_init__threading' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_get_global' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_call0' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_exception_occurred' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_eval_string' are not defined
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: warning: type and size of dynamic symbol `jl_call' are not defined

From my question on the forum it appears that there the way symbo lwere linked changed.

ldd on a v1.5.4 binary :

✔ rcaillaud ~/Workspace/localws/nimjl/examples [devel|…2]$ ldd bin/dummy_154 
	linux-vdso.so.1 (0x00007ffd367eb000)
	libm.so.6 => /lib64/libm.so.6 (0x00007ff1e20b2000)
	librt.so.1 => /lib64/librt.so.1 (0x00007ff1e1eaa000)
	libjulia.so.1 => /home/rcaillaud/Workspace/julia-1.5.3/lib/libjulia.so.1 (0x00007ff1e16db000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007ff1e14d7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ff1e111c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff1e23ea000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff1e0efd000)
	libunwind.so.8 => /home/rcaillaud/Workspace/julia-1.5.3/lib/julia/libunwind.so.8 (0x00007ff1e0cc4000)
	libLLVM-9jl.so => /home/rcaillaud/Workspace/julia-1.5.3/lib/julia/libLLVM-9jl.so (0x00007ff1dd561000)
	libstdc++.so.6 => /home/rcaillaud/Workspace/julia-1.5.3/lib/julia/libstdc++.so.6 (0x00007ff1dd1e3000)
	libgcc_s.so.1 => /home/rcaillaud/Workspace/julia-1.5.3/lib/julia/libgcc_s.so.1 (0x00007ff1dcfcb000)
	

ldd on v1.6.0 (that do not work) binary :

✘-1 rcaillaud ~/Workspace/localws/nimjl/examples [devel|…2]$ ldd bin/dummy_160 
	linux-vdso.so.1 (0x00007fffd1109000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f64ce9c9000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f64ce7c1000)
	libjulia.so.1 => /home/rcaillaud/Workspace/julia-1.6.0/lib/libjulia.so.1 (0x00007f64ce59b000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f64ce397000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f64cdfdc000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f64ced01000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f64cddbd000)

[KristofferC]

What happens if you link to libjulia-internal instead?

[vtjnash]

These are warnings, not errors. What is your copy of ld (try ld -v and ld -V)? We can try adding .size and .type to silence these (e.g. like these ENTRY and END macros for x86 https://github.com/JuliaMath/openlibm/blob/master/i387/bsd_asm.h#L78-L80)

[Clonkk]

What happens if you link to libjulia-internal instead?

I'll try and report -> Linking only libjulia-internal instead of libjulia has link error on undefined symbol (on jl_main_module ).

On the other hand, linking both libjulia and libjulia-internal seems to work. I don't mind if I have to introduce a separation between pre-v1.6.0 and post v1.6.0 - I'd just like to be sure it's the correct solution and not a workaround.

These are warnings, not errors.

Binary created linking v1.6.0 segfault during jl_init().
Since neither this nor the warnings were present with Julia v1.5.4 - and the linked libjulia version is the only change - I assumed (maybe wrongly ?) that it was a link error.

This happens using OpenSUSE Leap v15.2 on x86_64 Intel CPU (in case architecture / OS change anything - it should be a fairly standard configuration).

What is your copy of ld (try ld -v and ld -V)? We can try adding .size and .type to silence these (e.g. like these ENTRY and END macros for x86 https://github.com/JuliaMath/openlibm/blob/master/i387/bsd_asm.h#L78-L80)

• ld -v

✔ rcaillaud ~/Workspace/localws/nimjl/examples [devel|…3]$ ld -v
GNU ld (GNU Binutils; openSUSE Leap 15.2) 2.35.1.20201123-lp152.4.6

• ld -V

✔ rcaillaud ~/Workspace/localws/nimjl/examples [devel|…3]$ ld -V
GNU ld (GNU Binutils; openSUSE Leap 15.2) 2.35.1.20201123-lp152.4.6
  Supported emulations:
   elf_x86_64
   elf32_x86_64
   elf_i386
   elf_iamcu
   elf_l1om
   elf_k1om
   aarch64linux
   aarch64elf
   aarch64elf32
   aarch64elf32b
   aarch64elfb
   armelf
   armelfb
   aarch64linuxb
   aarch64linux32
   aarch64linux32b
   armelfb_linux_eabi
   armelf_linux_eabi
   elf64alpha
   alpha
   armelf_linux
   armelfb_linux
   avr2
   avr1
   avr25
   avr3
   avr31
   avr35
   avr4
   avr5
   avr51
   avr6
   avrxmega1
   avrxmega2
   avrxmega3
   avrxmega4
   avrxmega5
   avrxmega6
   avrxmega7
   avrtiny
   elf32epiphany
   elf32epiphany_4x4
   hppalinux
   hppa64linux
   elf64_ia64
   m68kelf
   elf32btsmip
   elf32ltsmip
   elf32btsmipn32
   elf64btsmip
   elf32ltsmipn32
   elf64ltsmip
   elf32ppclinux
   elf32ppc
   elf32ppcsim
   elf32lppclinux
   elf32lppc
   elf32lppcsim
   elf64ppc
   elf64lppc
   elf64lriscv
   elf64lriscv_lp64f
   elf64lriscv_lp64
   elf32lriscv
   elf32lriscv_ilp32f
   elf32lriscv_ilp32
   elf32rx_linux
   elf_s390
   elf64_s390
   shlelf_linux
   shlelf_fd
   elf32_sparc
   elf64_sparc
   elf32xtensa
   ppcmacos
   elf32_spu
   i386pep
   i386pe

[staticfloat]

Thanks for the detailed information @Clonkk; indeed we did change many things about how things are linked in Julia v1.6 (and there will be more changes in v1.7/v1.8) so it's good to keep on top of the packages that are linking against libjulia to ensure that there is no interruption in service.

First off, is there any degraded functionality, or is it just the ld warnings that are bothering you? libjulia should be automatically loading libjulia-internal so any usage of symbols/datatypes within those should function. To quash the warnings, I think Jameson is correct and we can add some symbol annotations to help ld not freak out here. I have a potential PR here, can you build that version (or download that version of Julia from the buildbots) of Julia and try linking against it to see if your issues are fixed?

[Clonkk]

First off, is there any degraded functionality, or is it just the ld warnings that are bothering you?

Currently, linking libjulia v1.6 gives a warning at linkage and segfault when jl_init() is called (according to gdb the last stacktrace is jl_symbol()). Ideally, I should have neither warnings nor segfault (like it was in libjulia v1.5.3 😄 ). The only way I'm able to make things works is explicitly linking libjulia-internal.so.

I have a potential PR here, can you build that version (or download that version of Julia from the buildbots) of Julia and try linking against it to see if your issues are fixed?

I'll check it out and report the result. Using #40575, everything seems to runs smoothly again 👍 .

The strange part that I can't understand is that the continuous integration that compile and execute tests works on my project.
The CI file is here https://github.com/Clonkk/nimjl/blob/master/.github/workflows/ci.yml#L18 . The actions runs periodically to check against new versions of Julia specificially for this purpose.

[staticfloat]

Using #40575, everything seems to runs smoothly again 👍 .

Great! I'll merge that then. I've marked it for backport to 1.6, so it likely will show up in v1.6.2, since v1.6.1 is already making its way through the tubes. In the meantime, nightly Julias should pick up this fix within the next few hours.

The actions runs periodically to check against new versions of Julia specificially for this purpose.

This is probably compiler/linker dependent, since you're the first person we have received about this issue. I'm glad it was a pretty simple fix. The CI environment is probably using a newer/older linker that doesn't get confused for some reason.