Bug 76856

Summary:	-Wl,--no-undefined gives undefined references to libc symbols on OpenBSD
Product:	Mesa	Reporter:	Jonathan Gray <jsg>
Component:	Other	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	OpenBSD
Whiteboard:
i915 platform:		i915 features:
Attachments:	patch to disable no-undefined on OpenBSD

Description Jonathan Gray 2014-03-31 18:12:03 UTC

Mesa libraries no longer link on OpenBSD after the -Wl,--no-undefined changes due to missing symbols from libc.

ie:

/bin/sh ../../../libtool  --tag=CC   --mode=link gcc -pthread -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno
-builtin-memcmp -g -O0  -no-undefined -Wl,--gc-sections -Wl,--no-undefined -L/usr/local/lib -o libglapi.la -rpath /usr/mesa/lib entry.lo mapi_glapi.lo stub.lo table.lo u_curr
ent.lo u_execmem.lo -lpthread 
libtool: link: gcc -shared  -fPIC -DPIC -o .libs/libglapi.so.0.0  .libs/entry.o .libs/mapi_glapi.o .libs/stub.o .libs/table.o .libs/u_current.o .libs/u_execmem.o   -L/usr/loc
al/lib -lpthread  -pthread -O2 -O0 -Wl,--gc-sections -Wl,--no-undefined -pthread   -pthread
/usr/bin/ld: Warning: gc-sections option ignored
.libs/mapi_glapi.o(.text+0x79): In function `_glapi_add_dispatch':
../../../src/mapi/mapi_glapi.c:123: undefined reference to `memset'
.libs/stub.o(.text+0x5b): In function `stub_compare':
../../../src/mapi/stub.c:78: undefined reference to `strcmp'
.libs/stub.o(.text+0x8a): In function `stub_find_public':
../../../src/mapi/stub.c:87: undefined reference to `bsearch'
.libs/stub.o(.text+0x18b): In function `stub_find_dynamic':
../../../src/mapi/stub.c:136: undefined reference to `__assert2'
.libs/stub.o(.text+0x1cb):../../../src/mapi/stub.c:140: undefined reference to `strcmp'
.libs/stub.o(.text+0x458): In function `stub_get_addr':
../../../src/mapi/stub.c:226: undefined reference to `__assert2'
.libs/table.o(.text+0x1e): In function `noop_warn':
../../../src/mapi/table.c:39: undefined reference to `getenv'
.libs/table.o(.text+0x2f):../../../src/mapi/table.c:39: undefined reference to `getenv'
.libs/table.o(.text+0x5e):../../../src/mapi/table.c:42: undefined reference to `__sF'
.libs/table.o(.text+0x7a):../../../src/mapi/table.c:42: undefined reference to `fprintf'
.libs/u_current.o(.text+0x4a): In function `u_tsd_init':
../../../src/mapi/u_thread.h:111: undefined reference to `perror'
.libs/u_current.o(.text+0x54):../../../src/mapi/u_thread.h:112: undefined reference to `exit'
.libs/u_current.o(.text+0x239): In function `u_tsd_set':
../../../src/mapi/u_thread.h:135: undefined reference to `perror'
.libs/u_current.o(.text+0x243):../../../src/mapi/u_thread.h:136: undefined reference to `exit'
.libs/u_execmem.o(.text+0x31): In function `init_map':
../../../src/mapi/u_execmem.c:81: undefined reference to `mmap'


This is not limited to mapi, libglx fails in a similiar way.

Comment 1 Emil Velikov 2014-03-31 19:33:19 UTC

Hmm how "nice" :-)
As my *BSD fu is virtually non existent would you mind checking which library(ies) provides those functions, so that we handle this appropriately.

Unless of course *BSD have the policy of leaving those symbols unresolved.

Comment 2 Jonathan Gray 2014-04-01 03:09:59 UTC

As I said in the subject these are all symbols in libc.  It seems --Wl,--no-undefined has different behaviour on Linux.

Evolution for example does not enable this on FreeBSD/OpenBSD
https://mail.gnome.org/archives/commits-list/2010-December/msg06238.html

sdl does not enable it on OpenBSD
http://lists.libsdl.org/pipermail/commits-libsdl.org/2013-November/007649.html

Comment 3 Jonathan Gray 2014-04-01 04:39:29 UTC

So it seems DT_NEEDED entries are not added for libc and libpthread over concerns that specific versions of those libraries would be referenced in a way that would prevent changing the major version of those libraries in future.

So the problem here is the combination of --no-uneeded and -no-undefined.

If the relevant lines could be contained to a variable in configure.ac instead of mentioned in the various Makefile.am files that would allow them to not be specified on OpenBSD.

Comment 4 Matt Turner 2014-04-01 05:47:48 UTC

Maybe check with OpenBSD to figure out why this doesn't work?

Comment 5 Matt Turner 2014-04-01 05:58:23 UTC

(In reply to comment #4)
> Maybe check with OpenBSD to figure out why this doesn't work?

Oh, I missed the more recent comment.

Comment 6 Emil Velikov 2014-04-01 17:05:12 UTC

Seems like a lovely case. There is a very nice 10+ old topic wrt this behaviour and libtool [1]. To make things even better sometimes the linking rules differ between versions (FreeBSD 5 vs 4)[2].

Most annoying part IMHO is that the ld manual does not even hint about this *BSD "feature".

With that said, we should avoid using -Wl,--no-undefined for OpenBSD but I would prefer to keep this on "as needed" basis. I.e. other *BSD flavours can opt in if needed.

Jonathan
Feel free to prep a patch and use your comment 3 to prevent other zealots like me from ever touching that piece of mesa :)

Thank you

[1] http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00483.html
[2] http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00494.html

Comment 7 Jonathan Gray 2014-04-02 02:48:59 UTC

Created attachment 96753 [details] [review]
patch to disable no-undefined on OpenBSD

Comment 8 Emil Velikov 2014-04-09 14:13:49 UTC

Pushed to master

commit 11623be934f8573910484de2a5fb50c95f0a1d44
Author: Jonathan Gray <jsg@jsg.id.au>
Date:   Thu Apr 3 15:46:01 2014 +1100

    automake: don't enable -Wl,--no-undefined on OpenBSD

    OpenBSD does not have DT_NEEDED entries for libc by design,
    over concerns how the symbols would be referenced after
    changing the major version of the library.

    So avoid -no-undefined checks on OpenBSD as they will fail.

    v2: don't include the -no-undefined libtool option in the variable
        and change -Wl,--no-undefined references in Automake.inc as well.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856
    Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
    Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
    Reviewed-by: Matt Turner <mattst88@gmail.com>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.