Hello LLVM community,
I am evaluating profitability of using the LLVM lld for linking our projects.
As a test, I tried to build the latest Boost with clang / lld on X86_64 Ubuntu and faced a problem at the very first step of doing this. One of the Boost’s auxiliary tools refers to the “environ” variable to access the environment variables. “environ” is defined in glibc and is actually a weak alias for the “__environ” variable. Here is a fragment of posix/environ.c:
char **__environ = NULL; // var pointing to env vars array
weak_alias (__environ, environ) // and two weak aliases to it
weak_alias (__environ, _environ)
When linking a program that accesses “environ” with binutils’ ld, the symbol is correctly marked as a weak object:
nm a.out | grep environ
0000000000601040 B __environ@@GLIBC_2.2.5
0000000000601040 V LLVM lld marks it as uninitialized data from the BSS section: 0000000000401168 environ Readelf also shows different symbols (readelf -s a.out | grep environ): - ld: 4: 0000000000601040 8 OBJECT WEAK DEFAULT 25 _environ@GLIBC_2.2.5 (2) 5: 0000000000601040 8 OBJECT WEAK DEFAULT 25 (2) ← environ is a weak object 6: 0000000000601040 8 OBJECT GLOBAL DEFAULT 25 __environ@GLIBC_2.2.5 (2) ← __environ itself is present as a global 54: 0000000000601040 8 OBJECT WEAK DEFAULT 25 63: 0000000000601040 8 OBJECT GLOBAL DEFAULT 25 __environ@@GLIBC_2.2.5 - lld 1: 0000000000401168 8 OBJECT GLOBAL DEFAULT 22 environ ← no __environ reference. Environ is a global, not weak 8: 0000000000000000 8 OBJECT GLOBAL DEFAULT UND environ 37: 0000000000401168 8 OBJECT GLOBAL DEFAULT 22 environ This leads to “environ” being nil when running the lld-linked binary. Is it a known problem? What is the fullness of ELF/Linux support? Where can I find the features list that are expected to work and what work is still in progress? Thank you! Kind regards, Oleg