[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Jun 2019 14:43:46 -0400
From: Rich Felker <dalias@...c.org>
To: Reinoud Koornstra <reinoudkoornstra@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: where to find musl-gcc wrapper script
On Tue, Jun 18, 2019 at 11:27:51AM -0700, Reinoud Koornstra wrote:
> On Tue, Jun 18, 2019 at 10:49 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Mon, Jun 17, 2019 at 08:28:12PM -0700, Reinoud Koornstra wrote:
> > > On Mon, Jun 17, 2019, 7:47 PM Rich Felker <dalias@...c.org> 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
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.
