From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11070 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible Header Issue Date: Tue, 21 Feb 2017 17:20:51 +0100 Message-ID: <20170221162051.33a3r5bgq7slpniz@voyager> References: <1069545885.1675581.1487671940388.ref@mail.yahoo.com> <1069545885.1675581.1487671940388@mail.yahoo.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1487694074 28783 195.159.176.226 (21 Feb 2017 16:21:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2017 16:21:14 +0000 (UTC) User-Agent: NeoMutt/20170113 (1.7.2) To: musl@lists.openwall.com Original-X-From: musl-return-11085-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 21 17:21:10 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cgDBY-0006jr-0k for gllmg-musl@m.gmane.org; Tue, 21 Feb 2017 17:21:04 +0100 Original-Received: (qmail 19872 invoked by uid 550); 21 Feb 2017 16:21:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19852 invoked from network); 21 Feb 2017 16:21:07 -0000 Content-Disposition: inline In-Reply-To: <1069545885.1675581.1487671940388@mail.yahoo.com> X-Provags-ID: V03:K0:RBep33yeOghPOq1Ko8URVCbfwWQUldPDHJPdKhj6sLvDQL0J9pW q7HJvIG9j30ahfoQERjk1RiT9X9mT3MBT99Ao8IRVqXqjitv+NPwpmoE68xEpkiOznuliJU VXL6+yu4aP+oCMgATcxkvqtqGCL3iAJl8F5VgBaCkVITkcGGBCynTivziG00KJcAv5dUHKe xueRCg16iIzfn2tc/pAMQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:+xaJ0jG6Lf0=:CDsPuUDrw2lN3feuHgnkKS moImq2Cv40fq3yYJSsJBLybw4eQSqqhiE77BPlmh6ywUhADPSwtzMweriIMEGsrSigOIolITR 67Z/if8OOsseu7lG48gLicbOTq3pIXCYOFNlmwUwHFqB9P1gOqR2lIszBHyyE37iF/xutaz85 3ku4NfW0ROAstFTyEIJjoL2TkRA3pWx/cEQ+tVbOvVBn1D/9OpviRKP4GqU/aI3lrF1+Xv9QF WAh3i1L1RJlsI1iSwST/5ZxyiZS1EJxhqmV1iwY1+BFLvBAHCp32CIC10Ot/RpQELaoZn4ClF Q3hK0gTiS9FHj3dtpTkCAORb7sWLLD+SNVIMvHoerZhTn+7CiJ9yrivVesZSLIoTdUFd4mb5b BfZPUOddgDW0SSUGvK7e1A+KpKVdWWQp4v53698vQQ5obVDeAXLTM3qjg3aIGE9ROH5QUX3eR XeCzPgzAHCp37GTQ+JC1F6PjTvXx8WdW9rgll6vomi9teu7NbnDEUOxaJKhaFql3yDml97bRT UslfdjxlbMO5q/s6a8Rnn2m92MCIk7IMerRQu3OlQ99h+NfHP2hsQTPRF+xErR2V+8h7pWidt HGaETbRoiDvdAG1Q1W7oeO32WlT5Zf3YwFIZMtp3gFpM13ZCO1/nfl42adN/NcMjRSGjNbfye uxyQWPkaiaZwoV5kX0stsCg7e++YOYmWzoNppKqjHwQi4TCF65xVOxVrMSvkPAJA/NMeON6Ne 3btCoQ7HiZhcW83PfCdqczs3YFAoqmxQ+kaMAt29Amplqj7BGsVxq3ubmPposXJ/mehcxROh Xref: news.gmane.org gmane.linux.lib.musl.general:11070 Archived-At: 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 > ^ > 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 not a libstdc++ > // wrapper that might already be installed later in the include search path. > #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS > #include_next > #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS > > // Get rid of those macros defined in 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 > > #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