where to find musl-gcc wrapper script

where to find musl-gcc wrapper script

[Reinoud Koornstra]

Hello Everyone,
I did get the sources and build from musl-cross-gcc at github.com.
Building works fine, however, I cannot find the musl-gcc script to compile.
So when I use this gcc to build I see warnings like:
warning: suggest parentheses around arithmetic in operand of '|'
[-Wparentheses] return __x>>24 | __x>>8&0xff00 | __x<<8&0xff0000 |
__x<<24;
Thanks,
Reinoud.

Re: where to find musl-gcc wrapper script

[Rich Felker]

On Mon, Jun 17, 2019 at 03:49:19PM -0700, Reinoud Koornstra wrote:
> Hello Everyone,
> I did get the sources and build from musl-cross-gcc at github.com.
> Building works fine, however, I cannot find the musl-gcc script to compile.

The musl-gcc wrapper script is for repurposing an existing host
toolchain for a different libc (glibc) to use it with musl. You don't
use it with a proper cross compiler toolchain or on a musl-native
system. The output of musl-cross-make will be a set of utilities
prefixed with the target tuple, e.g. x86_64-linux-musl-gcc, etc., in
the bin directory under wherever you installed the cross toolchain.

Rich

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

In this case, my application is simple, I need to compile and
application against musl, instead of glibc.
I do not need to musl compiled gcc for this?
Thanks,
Reinoud.

On Mon, Jun 17, 2019 at 4:30 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Jun 17, 2019 at 03:49:19PM -0700, Reinoud Koornstra wrote:
> > Hello Everyone,
> > I did get the sources and build from musl-cross-gcc at github.com.
> > Building works fine, however, I cannot find the musl-gcc script to compile.
>
> The musl-gcc wrapper script is for repurposing an existing host
> toolchain for a different libc (glibc) to use it with musl. You don't
> use it with a proper cross compiler toolchain or on a musl-native
> system. The output of musl-cross-make will be a set of utilities
> prefixed with the target tuple, e.g. x86_64-linux-musl-gcc, etc., in
> the bin directory under wherever you installed the cross toolchain.
>
> Rich

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

Ok the wrapper is included in the musl library itself in the obj directory.
c++ isn't supported yet?
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?
Thanks,
Reinoud.

On Mon, Jun 17, 2019 at 5:54 PM Reinoud Koornstra
<reinoudkoornstra@gmail.com> wrote:
>
> In this case, my application is simple, I need to compile and
> application against musl, instead of glibc.
> I do not need to musl compiled gcc for this?
> Thanks,
> Reinoud.
>
> On Mon, Jun 17, 2019 at 4:30 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Mon, Jun 17, 2019 at 03:49:19PM -0700, Reinoud Koornstra wrote:
> > > Hello Everyone,
> > > I did get the sources and build from musl-cross-gcc at github.com.
> > > Building works fine, however, I cannot find the musl-gcc script to compile.
> >
> > The musl-gcc wrapper script is for repurposing an existing host
> > toolchain for a different libc (glibc) to use it with musl. You don't
> > use it with a proper cross compiler toolchain or on a musl-native
> > system. The output of musl-cross-make will be a set of utilities
> > prefixed with the target tuple, e.g. x86_64-linux-musl-gcc, etc., in
> > the bin directory under wherever you installed the cross toolchain.
> >
> > Rich

Re: where to find musl-gcc wrapper script

[Rich Felker]

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.

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.

Rich


> On Mon, Jun 17, 2019 at 5:54 PM Reinoud Koornstra
> <reinoudkoornstra@gmail.com> wrote:
> >
> > In this case, my application is simple, I need to compile and
> > application against musl, instead of glibc.
> > I do not need to musl compiled gcc for this?
> > Thanks,
> > Reinoud.
> >
> > On Mon, Jun 17, 2019 at 4:30 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Mon, Jun 17, 2019 at 03:49:19PM -0700, Reinoud Koornstra wrote:
> > > > Hello Everyone,
> > > > I did get the sources and build from musl-cross-gcc at github.com.
> > > > Building works fine, however, I cannot find the musl-gcc script to compile.
> > >
> > > The musl-gcc wrapper script is for repurposing an existing host
> > > toolchain for a different libc (glibc) to use it with musl. You don't
> > > use it with a proper cross compiler toolchain or on a musl-native
> > > system. The output of musl-cross-make will be a set of utilities
> > > prefixed with the target tuple, e.g. x86_64-linux-musl-gcc, etc., in
> > > the bin directory under wherever you installed the cross toolchain.
> > >
> > > Rich

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

On Mon, Jun 17, 2019, 7:47 PM Rich Felker <dalias@libc.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?

>
> 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?

Thanks,

Reinoud.

>
> Rich
>
>
> > On Mon, Jun 17, 2019 at 5:54 PM Reinoud Koornstra
> > <reinoudkoornstra@gmail.com> wrote:
> > >
> > > In this case, my application is simple, I need to compile and
> > > application against musl, instead of glibc.
> > > I do not need to musl compiled gcc for this?
> > > Thanks,
> > > Reinoud.
> > >
> > > On Mon, Jun 17, 2019 at 4:30 PM Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at 03:49:19PM -0700, Reinoud Koornstra wrote:
> > > > > Hello Everyone,
> > > > > I did get the sources and build from musl-cross-gcc at github.com.
> > > > > Building works fine, however, I cannot find the musl-gcc script to
> compile.
> > > >
> > > > The musl-gcc wrapper script is for repurposing an existing host
> > > > toolchain for a different libc (glibc) to use it with musl. You don't
> > > > use it with a proper cross compiler toolchain or on a musl-native
> > > > system. The output of musl-cross-make will be a set of utilities
> > > > prefixed with the target tuple, e.g. x86_64-linux-musl-gcc, etc., in
> > > > the bin directory under wherever you installed the cross toolchain.
> > > >
> > > > Rich
>

[-- Attachment #2: Type: text/html, Size: 4322 bytes --]

Re: where to find musl-gcc wrapper script

[Rich Felker]

On Mon, Jun 17, 2019 at 08:28:12PM -0700, Reinoud Koornstra wrote:
> On Mon, Jun 17, 2019, 7:47 PM Rich Felker <dalias@libc.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.

Rich

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

On Tue, Jun 18, 2019 at 10:49 AM Rich Felker <dalias@libc.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@libc.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

Re: where to find musl-gcc wrapper script

[Rich Felker]

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@libc.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@libc.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

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

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?
Thanks,

Reinoud.

On Tue, Jun 18, 2019 at 11:43 AM Rich Felker <dalias@libc.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@libc.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@libc.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

Re: where to find musl-gcc wrapper script

[Rich Felker]

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?

Rich


> On Tue, Jun 18, 2019 at 11:43 AM Rich Felker <dalias@libc.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@libc.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@libc.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

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

On Tue, Jun 18, 2019 at 2:37 PM Rich Felker <dalias@libc.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@libc.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@libc.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@libc.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

Re: where to find musl-gcc wrapper script

[Rich Felker]

On Tue, Jun 18, 2019 at 02:49:17PM -0700, Reinoud Koornstra wrote:
> On Tue, Jun 18, 2019 at 2:37 PM Rich Felker <dalias@libc.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.

Where is -static? I don't think gdb offers a way to build
static-linked; you need to hack it in by putting -static and --static
(both to trick libtool) in the LDFLAGS.

On top of that, and I think this is your actual problem, I'm pretty
sure there's a bug in gdb's build process that breaks static linking
by adding --export-dynamic or --dynamic-list to the link command line,
which ld then interprets as meaning it should behave like it's dynamic
linking. Arguably this is actually a bug in gcc that it lets bad
options get through to the linker when this happens, but the easiest
way to fix it is patching it out of gdb's makefile after running
configure. (Alternatively you could patch out the stuff in configure
that adds it.)

Rich

Re: where to find musl-gcc wrapper script

[Reinoud Koornstra]

On Tue, Jun 18, 2019 at 2:58 PM Rich Felker <dalias@libc.org> wrote:
>
> On Tue, Jun 18, 2019 at 02:49:17PM -0700, Reinoud Koornstra wrote:
> > On Tue, Jun 18, 2019 at 2:37 PM Rich Felker <dalias@libc.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.
>
> Where is -static? I don't think gdb offers a way to build
> static-linked; you need to hack it in by putting -static and --static
> (both to trick libtool) in the LDFLAGS.
>
> On top of that, and I think this is your actual problem, I'm pretty
> sure there's a bug in gdb's build process that breaks static linking
> by adding --export-dynamic or --dynamic-list to the link command line,
> which ld then interprets as meaning it should behave like it's dynamic
> linking. Arguably this is actually a bug in gcc that it lets bad
> options get through to the linker when this happens, but the easiest
> way to fix it is patching it out of gdb's makefile after running
> configure. (Alternatively you could patch out the stuff in configure
> that adds it.)

Indeed, gdb doesn't support that natively, but I did follow your advice.
I make a log file of the build, after the build I took a look and in
the gdb directory it does:

arm-linux-musleabihf-g++ -g -O2 -static-libstdc++ -static-libgcc
-L/home/libnl/MUSL-ARM32/lib      -o gdb gdb.o aarch32-linux-nat.o
ada-exp.o ada-lang.o ada-tasks.o ada-typeprint.o ada-valprint.o
ada-varobj.o addrmap.o agent.o annotate.o arch-utils.o
arch/arm-get-next-pcs.o arch/arm-linux.o arch/arm.o arm-linux-nat.o
arm-linux-tdep.o arm-tdep.o auto-load.o auxv.o ax-gdb.o ax-general.o
bcache.o bfd-target.o block.o blockframe.o break-catch-sig.o
break-catch-syscall.o break-catch-throw.o breakpoint.o btrace.o
build-id.o buildsym-legacy.o buildsym.o c-exp.o c-lang.o c-typeprint.o
c-valprint.o c-varobj.o charset.o cli-out.o cli/cli-cmds.o
cli/cli-decode.o cli/cli-dump.o cli/cli-interp.o cli/cli-logging.o
cli/cli-script.o cli/cli-setshow.o cli/cli-style.o cli/cli-utils.o
coff-pe-read.o coffread.o common/agent.o common/btrace-common.o
common/buffer.o common/cleanups.o common/common-debug.o
common/common-exceptions.o common/common-regcache.o
common/common-utils.o common/environ.o common/errors.o common/fileio.o
common/filestuff.o common/format.o common/gdb_tilde_expand.o
common/gdb_vecs.o common/job-control.o common/netstuff.o
common/new-op.o common/pathstuff.o common/posix-strerror.o
common/print-utils.o common/ptid.o common/rsp-low.o
common/run-time-clock.o common/scoped_mmap.o
common/signals-state-save-restore.o common/signals.o common/tdesc.o
common/vec.o common/xml-utils.o compile/compile-c-support.o
compile/compile-c-symbols.o compile/compile-c-types.o
compile/compile-cplus-symbols.o compile/compile-cplus-types.o
compile/compile-loc2c.o compile/compile-object-load.o
compile/compile-object-run.o compile/compile.o complaints.o
completer.o continuations.o copying.o corefile.o corelow.o cp-abi.o
cp-name-parser.o cp-namespace.o cp-support.o cp-valprint.o ctf.o
d-exp.o d-lang.o d-namespace.o d-valprint.o dbxread.o dcache.o debug.o
demangle.o dictionary.o disasm-selftests.o disasm.o dtrace-probe.o
dummy-frame.o dwarf-index-cache.o dwarf-index-common.o
dwarf-index-write.o dwarf2-frame-tailcall.o dwarf2-frame.o
dwarf2expr.o dwarf2loc.o dwarf2read.o elfread.o eval.o event-loop.o
event-top.o exceptions.o exec.o expprint.o extension.o f-exp.o
f-lang.o f-typeprint.o f-valprint.o filename-seen-cache.o filesystem.o
findcmd.o findvar.o fork-child.o frame-base.o frame-unwind.o frame.o
gcore.o gdb-dlfcn.o gdb_bfd.o gdb_obstack.o gdb_regex.o gdb_usleep.o
gdbarch-selftests.o gdbarch.o gdbtypes.o glibc-tdep.o gnu-v2-abi.o
gnu-v3-abi.o go-exp.o go-lang.o go-typeprint.o go-valprint.o
guile/guile.o inf-child.o inf-loop.o inf-ptrace.o infcall.o infcmd.o
inferior.o inflow.o infrun.o inline-frame.o interps.o jit.o language.o
linespec.o linux-fork.o linux-nat.o linux-record.o linux-tdep.o
linux-thread-db.o location.o m2-exp.o m2-lang.o m2-typeprint.o
m2-valprint.o macrocmd.o macroexp.o macroscope.o macrotab.o main.o
maint.o mdebugread.o mem-break.o memattr.o memory-map.o memrange.o
mi/mi-cmd-break.o mi/mi-cmd-catch.o mi/mi-cmd-disas.o mi/mi-cmd-env.o
mi/mi-cmd-file.o mi/mi-cmd-info.o mi/mi-cmd-stack.o mi/mi-cmd-target.o
mi/mi-cmd-var.o mi/mi-cmds.o mi/mi-common.o mi/mi-console.o
mi/mi-getopt.o mi/mi-interp.o mi/mi-main.o mi/mi-out.o mi/mi-parse.o
mi/mi-symbol-cmds.o minidebug.o minsyms.o mipsread.o namespace.o
nat/fork-inferior.o nat/linux-namespaces.o nat/linux-osdata.o
nat/linux-personality.o nat/linux-procfs.o nat/linux-ptrace.o
nat/linux-waitpid.o objc-lang.o objfiles.o observable.o opencl-lang.o
osabi.o osdata.o p-exp.o p-lang.o p-typeprint.o p-valprint.o parse.o
posix-hdep.o printcmd.o probe.o proc-service.o
process-stratum-target.o producer.o progspace-and-thread.o progspace.o
prologue-value.o psymtab.o python/python.o record-btrace.o
record-full.o record.o regcache-dump.o regcache.o reggroups.o
registry.o remote-fileio.o remote-notif.o remote.o reverse.o
rust-exp.o rust-lang.o sentinel-frame.o ser-base.o ser-event.o
ser-pipe.o ser-tcp.o ser-uds.o ser-unix.o serial.o skip.o solib-svr4.o
solib-target.o solib.o source-cache.o source.o stabsread.o stack.o
stap-probe.o std-regs.o stub-termcap.o symfile-debug.o symfile-mem.o
symfile.o
symmisc.o symtab.o target-dcache.o target-descriptions.o
target-float.o target-memory.o target.o target/waitstatus.o
test-target.o thread-iter.o thread.o tid-parse.o top.o
tracefile-tfile.o tracefile.o tracepoint.o trad-frame.o tramp-frame.o
typeprint.o ui-file.o ui-out.o ui-style.o user-regs.o utils.o
valarith.o valops.o valprint.o value.o varobj.o version.o
xml-builtin.o xml-support.o xml-syscall.o xml-tdesc.o init.o
../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a
-L./../zlib -lz ./../intl/libintl.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a   -lm     ../libiberty/libiberty.a
build-gnulib/import/libgnu.a    -ldl
-Wl,--dynamic-list=./proc-service.list

So I changed this now to the follow, omitting the --dynamic-list

arm-linux-musleabihf-g++ -static -g -O2 -static-libstdc++
-static-libgcc -L/home/libnl/MUSL-ARM32/lib      -o gdb gdb.o
aarch32-linux-nat.o ada-exp.o ada-lang.o ada-tasks.o ada-typeprint.o
ada-valprint.o ada-varobj.o addrmap.o agent.o annotate.o arch-utils.o
arch/arm-get-next-pcs.o arch/arm-linux.o arch/arm.o arm-linux-nat.o
arm-linux-tdep.o arm-tdep.o auto-load.o auxv.o ax-gdb.o ax-general.o
bcache.o bfd-target.o block.o blockframe.o break-catch-sig.o
break-catch-syscall.o break-catch-throw.o breakpoint.o btrace.o
build-id.o buildsym-legacy.o buildsym.o c-exp.o c-lang.o c-typeprint.o
c-valprint.o c-varobj.o charset.o cli-out.o cli/cli-cmds.o
cli/cli-decode.o cli/cli-dump.o cli/cli-interp.o cli/cli-logging.o
cli/cli-script.o cli/cli-setshow.o cli/cli-style.o cli/cli-utils.o
coff-pe-read.o coffread.o common/agent.o common/btrace-common.o
common/buffer.o common/cleanups.o common/common-debug.o
common/common-exceptions.o common/common-regcache.o
common/common-utils.o common/environ.o common/errors.o common/fileio.o
common/filestuff.o common/format.o common/gdb_tilde_expand.o
common/gdb_vecs.o common/job-control.o common/netstuff.o
common/new-op.o common/pathstuff.o common/posix-strerror.o
common/print-utils.o common/ptid.o common/rsp-low.o
common/run-time-clock.o common/scoped_mmap.o
common/signals-state-save-restore.o common/signals.o common/tdesc.o
common/vec.o common/xml-utils.o compile/compile-c-support.o
compile/compile-c-symbols.o compile/compile-c-types.o
compile/compile-cplus-symbols.o compile/compile-cplus-types.o
compile/compile-loc2c.o compile/compile-object-load.o
compile/compile-object-run.o compile/compile.o complaints.o
completer.o continuations.o copying.o corefile.o corelow.o cp-abi.o
cp-name-parser.o cp-namespace.o cp-support.o cp-valprint.o ctf.o
d-exp.o d-lang.o d-namespace.o d-valprint.o dbxread.o dcache.o debug.o
demangle.o dictionary.o disasm-selftests.o disasm.o dtrace-probe.o
dummy-frame.o dwarf-index-cache.o dwarf-index-common.o
dwarf-index-write.o dwarf2-frame-tailcall.o dwarf2-frame.o
dwarf2expr.o dwarf2loc.o dwarf2read.o elfread.o eval.o event-loop.o
event-top.o exceptions.o exec.o expprint.o extension.o f-exp.o
f-lang.o f-typeprint.o f-valprint.o filename-seen-cache.o filesystem.o
findcmd.o findvar.o fork-child.o frame-base.o frame-unwind.o frame.o
gcore.o gdb-dlfcn.o gdb_bfd.o gdb_obstack.o gdb_regex.o gdb_usleep.o
gdbarch-selftests.o gdbarch.o gdbtypes.o glibc-tdep.o gnu-v2-abi.o
gnu-v3-abi.o go-exp.o go-lang.o go-typeprint.o go-valprint.o
guile/guile.o inf-child.o inf-loop.o inf-ptrace.o infcall.o infcmd.o
inferior.o inflow.o infrun.o inline-frame.o interps.o jit.o language.o
linespec.o linux-fork.o linux-nat.o linux-record.o linux-tdep.o
linux-thread-db.o location.o m2-exp.o m2-lang.o m2-typeprint.o
m2-valprint.o macrocmd.o macroexp.o macroscope.o macrotab.o main.o
maint.o mdebugread.o mem-break.o memattr.o memory-map.o memrange.o
mi/mi-cmd-break.o mi/mi-cmd-catch.o mi/mi-cmd-disas.o mi/mi-cmd-env.o
mi/mi-cmd-file.o mi/mi-cmd-info.o mi/mi-cmd-stack.o mi/mi-cmd-target.o
mi/mi-cmd-var.o mi/mi-cmds.o mi/mi-common.o mi/mi-console.o
mi/mi-getopt.o mi/mi-interp.o mi/mi-main.o mi/mi-out.o mi/mi-parse.o
mi/mi-symbol-cmds.o minidebug.o minsyms.o mipsread.o namespace.o
nat/fork-inferior.o nat/linux-namespaces.o nat/linux-osdata.o
nat/linux-personality.o nat/linux-procfs.o nat/linux-ptrace.o
nat/linux-waitpid.o objc-lang.o objfiles.o observable.o opencl-lang.o
osabi.o osdata.o p-exp.o p-lang.o p-typeprint.o p-valprint.o parse.o
posix-hdep.o printcmd.o probe.o proc-service.o
process-stratum-target.o producer.o progspace-and-thread.o progspace.o
prologue-value.o psymtab.o python/python.o record-btrace.o
record-full.o record.o regcache-dump.o regcache.o reggroups.o
registry.o remote-fileio.o remote-notif.o remote.o reverse.o
rust-exp.o rust-lang.o sentinel-frame.o ser-base.o ser-event.o
ser-pipe.o ser-tcp.o ser-uds.o ser-unix.o serial.o skip.o solib-svr4.o
solib-target.o solib.o source-cache.o source.o stabsread.o stack.o
stap-probe.o std-regs.o stub-termcap.o symfile-debug.o symfile-mem.o
symfile.o
symmisc.o symtab.o target-dcache.o target-descriptions.o
target-float.o target-memory.o target.o target/waitstatus.o
test-target.o thread-iter.o thread.o tid-parse.o top.o
tracefile-tfile.o tracefile.o tracepoint.o trad-frame.o tramp-frame.o
typeprint.o ui-file.o ui-out.o ui-style.o user-regs.o utils.o
valarith.o valops.o valprint.o value.o varobj.o version.o
xml-builtin.o xml-support.o xml-syscall.o xml-tdesc.o init.o
../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a
-L./../zlib -lz ./../intl/libintl.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a   -lm     ../libiberty/libiberty.a
build-gnulib/import/libgnu.a    -ldl

I did copy this one on an arm32 machine and I does run nicely, btw,
this arm machine runs on glibc so if it wasn't statically linked it
could never run:
/lib/libc.so.6
GNU C Library (GLIBC) stable release version 2.19, by Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.
[SNIP]

Now on this armv7 machine I run the compiled gdb:
GNU gdb (GDB) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-musleabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".

Tried loading in some core file (generated by sending a kill 11
signal) and it works fine.
Thanks,

Reinoud.