On Sat, Sep 19, 2015 at 9:50 AM, Sebastien Marie <sema...@openbsd.org> wrote:
> While working on building llvm 3.7.0 on openbsd (-current amd64 and
> i386), I encounter a problem when linking a shared library, while
> -Wl,-z,defs was passed on command-line.
>
> I build a minimal reproductible testcase:
>
> $ touch test.c
> $ c++ -Wl,-z,defs -shared -o libtest.so test.c
> /usr/lib/crtbeginS.o: In function `atexit':
> (.text+0x18f): undefined reference to `__cxa_atexit'
> collect2: ld returned 1 exit status
If you want to use -zdefs when building a shared library, you MUST
include in the link the libraries that it depends on, including libc.
> According to ld(1), `-z defs' is:
>
>> -z keyword
>> The recognized keywords are:
>>
>> defs
>> Disallows undefined symbols in object files. Undefined symbols
>> in shared libraries are still allowed.
That's really "undefined symbols in shared libraries *included in the
link* are still allowed, as is made clear in the later description of
-z defs in the same page:
--no-undefined
-z defs
Report unresolved symbol references from regular object files.
This is done even if the linker is creating a non-symbolic shared
library. The switch --[no-]allow-shlib-undefined controls the
behaviour for reporting unresolved references found in shared
libraries being linked in.
> So, as in my case I am building a shared libraries (`-shared'),
> according to the documentation, undefined symbols shouldn't be an error
> when using `-z defs'.
I believe the current behavior is correct and matches other systems.
Philip Guenther
