From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14242 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 14:43:46 -0400 Message-ID: <20190618184346.GO1506@brightrain.aerifal.cx> References: <20190617233023.GK1506@brightrain.aerifal.cx> <20190618024755.GM1506@brightrain.aerifal.cx> <20190618174926.GN1506@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="164514"; 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-14258-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 18 20:44:04 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 1hdJ5N-000gf2-V6 for gllmg-musl@m.gmane.org; Tue, 18 Jun 2019 20:44:02 +0200 Original-Received: (qmail 5208 invoked by uid 550); 18 Jun 2019 18:43:59 -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 5190 invoked from network); 18 Jun 2019 18:43:59 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14242 Archived-At: On Tue, Jun 18, 2019 at 11:27:51AM -0700, Reinoud Koornstra wrote: > On Tue, Jun 18, 2019 at 10:49 AM Rich Felker wrote: > > > > 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. > > Ok, this seemed to have worked nicely. Question, it does add -lrt in > the end, do I need this in musl or is it build in libc? > Also, is there a way to verify everything linked nicely by the musl-ld? You can include -lrt or omit it; it doesn't matter. musl provides librt purely as an empty static library file to allow link commands that include it (POSIX specifies that it must be accepted), so it makes no difference to the output. All functionality is in libc.a/.so. Rich