-Wl,--as-needed causes x86_64 build to fail

[Leslie P. Polzer]

Originally reported 2009-10-05 by Michael Bykov on sbcl-help under the heading "Failed contribs: asdf-install, sb-posix".

Nikodemus Siivola wrote:
> 2009/10/5 Michael Bykov <email address hidden>:
>
>> debugger invoked on a UNDEFINED-ALIEN-ERROR in thread #<THREAD
>> "initial thread" RUNNING {A8C4049}>:
>> Undefined alien: "waitpid"
>>
>> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>>
>> restarts (invokable by number or by possibly-abbreviated name):
>> 0: [ABORT] Exit debugger, returning to top level.
>>
>> (FOREIGN-SYMBOL-ADDRESS "waitpid" #<unused argument>)
>> 0]
>
> That's strange.
>
> Can you try adding "waitpid" to tools-for-build/ldso-stubs.lisp (eg.
> between "wait3" and "write"), and rebuilding. (Run clean.sh before
> rebuilding.)

Someone has posted an analysis of this here:

  http://bbs.archlinux.org/viewtopic.php?pid=667471#p667471

I don't know why it only fails on x86_64, but it's worrying that
the original error gets obscured, leading to the slightly unrelated
error about a missing waitpid().

The bottom line is that a "-Wl,--as-needed" in LDFLAGS causes
the compilation of tools-for-build/os-provides-dlopen-test.c
to fail.

[Christoph Egger (christoph-egger)]

Could be "fixed" as follows (good as workaround for e.g. ubuntu that forces as needed inside the linker binary ...)

--- sbcl-1.0.45.0.orig/tools-for-build/Makefile
+++ sbcl-1.0.45.0/tools-for-build/Makefile
@@ -11,7 +11,7 @@
 -include Config

 CPPFLAGS:=-I../src/runtime
-LDFLAGS:=$(LDFLAGS) $(OS_LIBS)
+LDFLAGS:=$(LDFLAGS) -Wl,--no-as-needed $(OS_LIBS)

 all: grovel-headers determine-endianness where-is-mcontext \
         modify-ldt-struct-name sigaction-sa-nodefer-works-test

[James Y Knight (foom)]

Are you sure this wasn't already fixed by 1.0.45.9?

http://repo.or.cz/w/sbcl.git/commit/210a34a1509426a3306fdc1c3cc69142967712b6

[Nikodemus Siivola (nikodemus)]

I suspect it's better to ad --no-as-needed anyways: otherwise sooner or later someone adds a foreign symbol that is there at runtime on his platform, but not elsewhere.

...the less we need to stubify, the better, I think.

[James Y Knight (foom)]

Uh? --no-as-needed should certainly not be necessary for linking the trivial test C programs in the tools-for-build directory...

I guess you mean for the build of the sbcl runtime binary, instead? Just in case someone wants to link sbcl against libfoobar, and reference foobar() at runtime, but ld ignored -lfoobar, because there was no C-side reference to the foobar() function?

Hasn't come up yet, so it seems unlikely to be an issue, but could happen!

[Nikodemus Siivola (nikodemus)]

Uh, for some reason I didn't realize this was for tools-for-build. You're right -- --no-as-needed should not be needed there.

For the runtime (particularly considering distros like Ubuntu) it seems to me --no-as-needed is TRT. That was the waitpid issue the ldso stub worked around, wasn't it?

[James Y Knight (foom)]

No; --as-needed only omits entire libraries that aren't referenced by anything in the link. waitpid is provided by libc just like wait$everythingelse.

Wasn't the issue there simply that the stub isn't necessary unless dlsym isn't available, and the bug fixed by 1.0.45.9 made it seem like dlsym wasn't available on linux?

[Nikodemus Siivola (nikodemus)]

I stand corrected.

[Nikodemus Siivola (nikodemus)]

In 1.0.45.9.