Building Oasis Node with jemalloc on Fedora adds lots of dynamically-linked libraries

[tjanez]

SUMMARY

The addition of jemalloc in #4040 results in lots of dynamically linked libraries in Oasis Node when built on Fedora.

ISSUE TYPE

• Bug Report

OS / ENVIRONMENT

• Fedora 33
• GNU ld version 2.35-18.fc33
• Go 1.16.3

STEPS TO REPRODUCE

• Install jemalloc as described in https://docs.oasis.dev/oasis-core/development-setup/build-environment-setup-and-building/prerequisites and compile Oasis Node.

ACTUAL RESULTS

Checkout 71d231e.

[tadej@toronto oasis-core ((71d231e4f...))]$ cd go
[tadej@toronto go ((71d231e4f...))]$ make oasis-node
*** Building oasis-node...
... output trimmed ...
[tadej@toronto go ((71d231e4f...))]$ ldd oasis-node/oasis-node
	linux-vdso.so.1 (0x00007ffc7e9f5000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc21269f000)
	libjemalloc.so.2 => /usr/local/lib/libjemalloc.so.2 (0x00007fc2123fb000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc2122b5000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc2120cd000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc2120c6000)
	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fc2120a4000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc211ed7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc2126e2000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc211ebc000)

EXPECTED RESULTS

Checkout 42301db.

[tadej@toronto oasis-core ((42301dbc5...))]$ cd go
[tadej@toronto go ((42301dbc5...))]$ make oasis-node
*** Building oasis-node...
... output trimmed ...
[tadej@toronto go ((42301dbc5...))]$ ldd oasis-node/oasis-node
	linux-vdso.so.1 (0x00007ffe6fdaa000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd9dfe2d000)
	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fd9dfe0b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fd9dfc40000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd9dfe70000)

ADDITIONAL INFORMATION

The newly added dynamically-linked libraries appear to all come from dgraph-io/ristretto/z/calloc_jemalloc.go#L10:

#cgo LDFLAGS: /usr/local/lib/libjemalloc.a -L/usr/local/lib -Wl,-rpath,/usr/local/lib -ljemalloc -lm -lstdc++ -pthread -ldl

And curiously, the created Oasis Node binary also appears to have symbols from the statically-linked libjemalloc included:

[tadej@toronto go ((71d231e4f...))]$ nm oasis-node/oasis-node | grep "je_malloc"
0000000001892400 T _cgo_db11c91d1e7d_Cfunc_je_malloc_stats_print
000000000192b450 T je_malloc
0000000002efb3c0 V je_malloc_conf
0000000001970f50 t je_malloc_cprintf
000000000192a690 t je_malloc_default
0000000001928410 t je_malloc_initialized
0000000003102e08 B je_malloc_message
0000000001971550 t je_malloc_mutex_boot
0000000001971390 t je_malloc_mutex_init
0000000001971080 t je_malloc_mutex_lock_slow
00000000019714a0 t je_malloc_mutex_postfork_child
000000000040d73e t je_malloc_mutex_postfork_child.cold
0000000001971490 t je_malloc_mutex_postfork_parent
0000000001971440 t je_malloc_mutex_prefork
0000000001971350 t je_malloc_mutex_prof_data_reset
0000000001970fe0 t je_malloc_printf
0000000002d7cbc8 d je_malloc_slow
0000000001970e70 t je_malloc_snprintf
0000000001932dd0 T je_malloc_stats_print
000000000196eb10 t je_malloc_strtoumax
0000000001995820 t je_malloc_tsd_boot0
00000000019958a0 t je_malloc_tsd_boot1
0000000001995810 t je_malloc_tsd_cleanup_register
0000000001995800 t je_malloc_tsd_dalloc
00000000019957f0 t je_malloc_tsd_malloc
0000000001932e30 T je_malloc_usable_size
0000000001970f00 t je_malloc_vcprintf
000000000196ed80 t je_malloc_vsnprintf
000000000040d73e t je_malloc_vsnprintf.cold
000000000196ea80 t je_malloc_write
000000000192ed20 T je_mallocx

Also, on Ubuntu, the changes in PR #4040 didn't result in newly added dynamically-linked libraries for Oasis Node.