MacOS: lost symbols strike back

Steps to reproduce:

cargo test --doc --package picodata -- instance::grade::has_grades --nocapture

We have faced a new reincarnation of the linker that stripes unused symbols on linkage (previous episode is #229). This time the problem happens if we run cargo test --doc (log):

  = note: clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
          Undefined symbols for architecture x86_64:
            "_decNumberFromInt64", referenced from:
                _decimal_from_int64 in libcore.a(decimal.c.o)
            "_decNumberFromUInt64", referenced from:
                _decimal_from_uint64 in libcore.a(decimal.c.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

An interesting part of the story is that even if we add RUSTFLAGS="-C link-dead-code=yes" to the repro, the problem remains.

added bug label

changed title from MacOS: -dead_strip strikes back to MacOS: lost symbols strikes back

changed title from MacOS: lost symbols strikes back to MacOS: lost symbols strike back

Well, the workaround I was able to find is to pass the following arg to the linker - --undefined=dynamic_lookup
The problem is that such usage only moves the problem from compile time to runtime, even though such errors do not occur during tests.

Another interesting fact that may be related is that I get different symbols in Picodata binary build on OS X and Linux (Ubuntu 20.04):
MacOS

~/work/picodata/picodata(da1501b✔️) nm target/debug/picodata | grep decNumberFrom
00000001006e2b60 T _decNumberFromInt64
00000001006e3600 T _decNumberFromString
00000001006e2c40 T _decNumberFromUInt64

Linux

~/picodata/picodata(da1501b8✔) nm target/debug/picodata | grep decNumberFrom
000000000181dc90 T decNumberFromInt32
000000000181dd60 T decNumberFromInt64
000000000181f9f0 T decNumberFromString
000000000181dc20 T decNumberFromUInt32
000000000181dce0 T decNumberFromUInt64
0000000001c71868 T uprv_decNumberFromInt32_62
0000000001c71c54 T uprv_decNumberFromString_62
0000000001c718c8 T uprv_decNumberFromUInt32_62

Moreover I managed to inspect doctests that are failing to link:

1. I used dynamic_lookup to be able to get the binaries
2. I used nightly build to be able to use --persist-doctests option in rustdoc
3. I got the rustdoc command with cargo test --doc --package picodata -- instance::grade::has_grades --nocapture -v to capture the rustdoc command (too big to be pasted here)
4. I ran the command from the 4-th step with persist-doctests option and inspected the symbols of the bin

doctests (OS X)

~/work/picodata/picodata(da1501b✗) nm doctest/src_instance_grade_rs_147_0/rust_out | grep decNumberFrom
                 U _decNumberFromInt64
00000001002235a0 T _decNumberFromString
                 U _decNumberFromUInt64

The I tried to build that code as a bin (I simply changed main.rs to match instance::grade::has_grades test and I got the following (no changes to build needed):

~/work/picodata/picodata(da1501b✗) nm target/debug/picodata | grep decNumberFrom
0000000100278300 T _decNumberFromInt64
00000001002784d0 T _decNumberFromString
00000001002783e0 T _decNumberFromUInt64

The difference I noticed is that doctests are built with --crate-type=lib and bin is build with --crate-type=bin (obviously). That is the point there I find myself lost.

mentioned in issue #242 (closed)

mentioned in commit 2c9d206f

mentioned in merge request !578 (merged)

closed with merge request !578 (merged)

closed with commit 2c9d206f

Solved by explictily specifying libdecNumber.a from tarantool sources by full path when linking, so that the compiler isn't confused about the version of the library we want.