[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAA5faHOffa6N3s5kDxNhd8OioHH9Ty6eK1df7EmZ5p6hVVQ1A@mail.gmail.com>
Date: Tue, 18 Jun 2019 14:49:17 -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 2:37 PM Rich Felker <dalias@...c.org> wrote:
>
> On Tue, Jun 18, 2019 at 02:19:06PM -0700, Reinoud Koornstra wrote:
> > I noticed that the -static gives me some weird stuff. If I use glibc
> > to compile gdb and then rerun the compile command with static I do get
> > to see it's a statically linked binary. It'll end up with warnings,
> > but ...
> > gdb compiles fine with musl as well. So after compiling i see:
> > ELF 32-bit executable, ARM, EABI5 version 1 (SYSV). dynamically
> > linked, interpreter /lib/ld-musl-armhf.so.1
> > When I add -static to the arm-linux-musleabihf-g++ command it compiles
> > seemingly fine as well.
> > However when i run file again over this I see:
> > ELF 32-bit executable, ARM, EABI5 version 1 (SYSV). dynamically
> > linked, interpreter, /usr/lib/ld.so.1 ....
> > So adding -static didn't seem to have the desired effect, it also all
> > over sudden showed a different interpreter.
> > Any ideas?
>
> What commands did you use to build musl-cross-make? Any config.mak
> file? What options did you use when linking?
in the config.mak for musl-cross-make I used:
TARGET = arm-linux-musleabihf
OUTPUT = /home/libnl/MUSL-ARM32
The rest I left default.
To configure gdb-8.3 i used:
Then I added OUTPUT to my path: PATH=/home/libnl/MUSL-ARM32/bin:$PATH
I configured gdb with:
CC=arm-linux-musleabihf-gcc CXX=arm-linux-musleabihf-g++
CFLAGS="-I/home/libnl/MUSL-ARM32/include"
LDFLAGS="-L/home/libnl/MUSL-ARM32/lib" ./configure --enable-static
--host=arm-linux-musleabihf --target=arm-linux-musleabihf
--build=x86_64-ubuntu-linux
after this I used make.
Thanks,
Reinoud.
>
> Rich
>
>
> > On Tue, Jun 18, 2019 at 11:43 AM Rich Felker <dalias@...c.org> wrote:
> > >
> > > 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.
