[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAA5faHhLZtBGxgBEK5GDDUajzdHGgyLtapzQ-R9fLMqckAcWA@mail.gmail.com>
Date: Tue, 18 Jun 2019 11:27:51 -0700
From: Reinoud Koornstra <reinoudkoornstra@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: where to find musl-gcc wrapper script
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?
Thanks,
Reinoud.
>
> 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.
