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

Bug #492783 reported by Leslie P. Polzer on 2009-12-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

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:


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.

Changed in sbcl:
status: New → Confirmed
importance: Undecided → Low

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

--- sbcl-
+++ sbcl-
@@ -11,7 +11,7 @@
 -include Config

+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) wrote :

Are you sure this wasn't already fixed by


Nikodemus Siivola (nikodemus) wrote :

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) wrote :

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) wrote :

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) wrote :

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 made it seem like dlsym wasn't available on linux?

Nikodemus Siivola (nikodemus) wrote :

I stand corrected.

Nikodemus Siivola (nikodemus) wrote :


Changed in sbcl:
status: Confirmed → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers