From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14240 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: where to find musl-gcc wrapper script Date: Tue, 18 Jun 2019 13:49:26 -0400 Message-ID: <20190618174926.GN1506@brightrain.aerifal.cx> References: <20190617233023.GK1506@brightrain.aerifal.cx> <20190618024755.GM1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="190031"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Reinoud Koornstra Original-X-From: musl-return-14256-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 18 19:49:44 2019 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.89) (envelope-from ) id 1hdIEo-000nG9-RR for gllmg-musl@m.gmane.org; Tue, 18 Jun 2019 19:49:42 +0200 Original-Received: (qmail 13396 invoked by uid 550); 18 Jun 2019 17:49:40 -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 13369 invoked from network); 18 Jun 2019 17:49:39 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14240 Archived-At: On Mon, Jun 17, 2019 at 08:28:12PM -0700, Reinoud Koornstra wrote: > On Mon, Jun 17, 2019, 7:47 PM Rich Felker wrote: > > > On Mon, Jun 17, 2019 at 07:30:00PM -0700, Reinoud Koornstra wrote: > > > Ok the wrapper is included in the musl library itself in the obj > > directory. > > > > Yes, or installed in $prefix/bin if you install. If you don't install > > it won't be able to find its spec file. > > > > > c++ isn't supported yet? > > > > Right. Nobody I'm aware of understands the details of this, but > > apparently either GCC's actual C++ headers or its "precompiled header" > > versions of them pull in a bunch of stuff from glibc, and then it > > breaks when you try to reuse them with musl. It's probably not that > > hard to figure out the root cause and maybe even make it work, but > > nobody has done it and interest is low because it's still a big hack > > compared to just building a proper cross toolchain. > > > > > Currently I configure with CC=musl-gcc > > > CFLAGS="-I/home/me/MUSL/include" LDFLAGS="-L/home/me/lib" ./configure > > > the final g++ comand also add -lrt, need more changes for this to work? > > > > If you do that you're compiling against musl's headers but then > > linking against glibc, which is going to make a huge broken mess. > > Yes, I noticed, so how can I force it to link against musl as well? You can't, because things already went wrong as soon as you compiled against glibc's C++ headers using the glibc-based host g++. > > If you need C++, you really should just build a cross toolchain with > > musl-cross-make. It's as simple as clining the mcm repo and running > > "make TARGET=x86_64-linux-musl OUTPUT=/some/dir install" -- it will > > download, check hashes on, and patch all the components you need and > > give you a clean self-contained cross toolchain in the OUTPUT dir. > > > > Also done that, in that case should I just use the compiled gcc as cc? You can pass the resulting x86_64-linux-musl-gcc and x86_64-linux-musl-g++ as CC and CXX, but for software using the standard tuple prefix conventions, you'd tell it you're cross compiling for x86_64-linux-musl (e.g. by passing --host=x86_64-linux-musl to configure) and it would automatically pick them up as long as they're in your PATH (which you probably need to add them to, e.g. PATH=$PATH:/path/to/mcm/output/bin). This is better if the software has reason to need to know it's being cross compiled, or if it uses other utilities like ar, ranlib, direct use of ld, etc. in the build process, since it will pick up the right ones from the cross toolchain. Rich