* Re: Possible Header Issue
2017-02-21 10:12 ` Possible Header Issue Jason Cosby
@ 2017-02-21 16:20 ` Markus Wichmann
0 siblings, 0 replies; 2+ messages in thread
From: Markus Wichmann @ 2017-02-21 16:20 UTC (permalink / raw)
To: musl
On Tue, Feb 21, 2017 at 10:12:20AM +0000, Jason Cosby wrote:
> 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 ld-musl-x86_64.so.1, 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:
>
You're getting a compilation error due to "file not found". Having a
working linker is little consolation for that problem.
> 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.
Sounds pretty simple to me. Somehow, musl's include directory isn't
showing up in the search list. It should be present as either -isystem
or -I (e.g. -I/home/cos/musl/buil/include or
-isystem /home/cos/musl/build/include). Ideally, that option would be
provided by gcc's spec file.
> 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:
Precisely not. It knows where to find cstdlib, because that file is
internal to the compiler, but not where to find stdlib.h.
>
> // 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.
> #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> #include_next <stdlib.h>
> #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
>
> // 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" {
> #endif
>
> #include <features.h>
>
> #ifdef __cplusplus
>
> #define NULL 0L
> #else
> #define NULL ((void*)0)
> #endif
>
> 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.
How did you get that from the snippet quoted? stdlib.h must define the
NULL macro. For C that is easy, most programmers expect it to be a zero
casted to pointer-to-void (although you can't rely on it). That works,
because in C anypointer can be converted to pointer-to-void (and back)
without explicit conversion.
In C++, this doesn't work. For some arcane reason, Stroustrup decided to
make conversions from and to pointer-to-void explicit. So for C++ we
need an integer 0 constant. Ideally of pointer width. For Linux, we can
use long for that, because on Linux a long must always be exactly as
large as a pointer, else syscalls won't work.
cstdlib must define the same symbols as stdlib.h, but in namespace std.
So, libstdc++'s cstdlib just includes stdlib.h and then puts all the
symbols from stdlib.h in there with the "using" directive. But if any of
those functions were implemented with a macro (in theory, the abs()
function can be expressed as a ternary, or rather, a statement
expression containing a ternary) then the line "using ::abs;" would turn
into a warning about the wrong numer of arguments in a macro invocation.
But this all has nothing to do eith your problem. Fix your include paths
and the problem should sort itself out.
Ciao,
Markus
^ permalink raw reply [flat|nested] 2+ messages in thread