Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Feb 2017 10:12:20 +0000 (UTC)
From: Jason Cosby <>
To:  <>
Subject: Possible Header Issue

Hi all. I'll try to keep this succinct, but I've worked this issue for an ungodly amount of hours, so it may not be all that short. I'm posting here because I suspect my issues may stem from libstdc++'s cstdlib and musl's stdlib.h not playing well together. I'm at a loss here, because musl-cross-make and sabotage obviously aren't having the issues I'm having with gcc-6.3.0 or they wouldn't be updated to the latest version. 

I'm on pass two of a gcc cross build. Pass one gcc, musl, libstdc++, and both passes of binutils install without a hitch. readelf confirms that libstdc++ is properly dynamically linked to musl. I verified that the new (6.3.0) pass one versions of gcc, g++, ranlib, ar, and ld are being used. binutils is dynamically linked to musl, gcc's specs correctly looks for, and ld is pointed at the correct (musl) lib dir. I get exactly the same error every time, regardless of config options, C/CXX flags, or anything else I've thrown at it:

checking for string.h... In file included from ../../gcc/system.h:266:0,
                 from ../../gcc/gengenrtl.c:22:
/home/cos/musl/build/include/c++/6.3.0/cstdlib:75:25: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
compilation terminated.
Makefile:2495: recipe for target 'build/gengenrtl.o' failed
make[2]: *** [build/gengenrtl.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from ../../gcc/system.h:266:0,
                 from ../../gcc/genconstants.c:28:

Rooting around in config.log doesn't shed any light, it just repeats the fact that stdlib.h can't be found. The build obviously knows where to find the headers or it wouldn't dig up cstlib. stdlib.h is in the top level include dir right where musl put it and there's nothing funky with permissions. Taking a look in cstdlib (installed by libstdc++) to see what's up I see:

// Need to ensure this finds the C library's <stdlib.h> not a libstdc++
// wrapper that might already be installed later in the include search path.
#include_next <stdlib.h>

// Get rid of those macros defined in <stdlib.h> in lieu of real functions.

Then a bunch of undefining/redefining of functions. Taking a look at musl's stdlib.h I see:

#ifdef __cplusplus
extern "C" {

#include <features.h>

#ifdef __cplusplus

#define NULL 0L
#define NULL ((void*)0)

I've never completely wrapped my head around C programming, but is stdlib.h telling cstdlib to pound sand and to leave its functions alone? Thanks much for any insight. 

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.