* where to find musl-gcc wrapper script @ 2019-06-17 22:49 Reinoud Koornstra 2019-06-17 23:30 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-17 22:49 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-17 22:49 where to find musl-gcc wrapper script Reinoud Koornstra @ 2019-06-17 23:30 ` Rich Felker 2019-06-18 0:54 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2019-06-17 23:30 UTC (permalink / raw) To: Reinoud Koornstra; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-17 23:30 ` Rich Felker @ 2019-06-18 0:54 ` Reinoud Koornstra 2019-06-18 2:30 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 0:54 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 0:54 ` Reinoud Koornstra @ 2019-06-18 2:30 ` Reinoud Koornstra 2019-06-18 2:47 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 2:30 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 2:30 ` Reinoud Koornstra @ 2019-06-18 2:47 ` Rich Felker 2019-06-18 3:28 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2019-06-18 2:47 UTC (permalink / raw) To: Reinoud Koornstra; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 2:47 ` Rich Felker @ 2019-06-18 3:28 ` Reinoud Koornstra 2019-06-18 17:49 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 3:28 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 3:28 ` Reinoud Koornstra @ 2019-06-18 17:49 ` Rich Felker 2019-06-18 18:27 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2019-06-18 17:49 UTC (permalink / raw) To: Reinoud Koornstra; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 17:49 ` Rich Felker @ 2019-06-18 18:27 ` Reinoud Koornstra 2019-06-18 18:43 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 18:27 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 18:27 ` Reinoud Koornstra @ 2019-06-18 18:43 ` Rich Felker 2019-06-18 21:19 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2019-06-18 18:43 UTC (permalink / raw) To: Reinoud Koornstra; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 18:43 ` Rich Felker @ 2019-06-18 21:19 ` Reinoud Koornstra 2019-06-18 21:37 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 21:19 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 21:19 ` Reinoud Koornstra @ 2019-06-18 21:37 ` Rich Felker 2019-06-18 21:49 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2019-06-18 21:37 UTC (permalink / raw) To: Reinoud Koornstra; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 21:37 ` Rich Felker @ 2019-06-18 21:49 ` Reinoud Koornstra 2019-06-18 21:58 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 21:49 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 21:49 ` Reinoud Koornstra @ 2019-06-18 21:58 ` Rich Felker 2019-06-18 22:54 ` Reinoud Koornstra 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2019-06-18 21:58 UTC (permalink / raw) To: Reinoud Koornstra; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: where to find musl-gcc wrapper script 2019-06-18 21:58 ` Rich Felker @ 2019-06-18 22:54 ` Reinoud Koornstra 0 siblings, 0 replies; 14+ messages in thread From: Reinoud Koornstra @ 2019-06-18 22:54 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-06-18 22:54 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-17 22:49 where to find musl-gcc wrapper script Reinoud Koornstra 2019-06-17 23:30 ` Rich Felker 2019-06-18 0:54 ` Reinoud Koornstra 2019-06-18 2:30 ` Reinoud Koornstra 2019-06-18 2:47 ` Rich Felker 2019-06-18 3:28 ` Reinoud Koornstra 2019-06-18 17:49 ` Rich Felker 2019-06-18 18:27 ` Reinoud Koornstra 2019-06-18 18:43 ` Rich Felker 2019-06-18 21:19 ` Reinoud Koornstra 2019-06-18 21:37 ` Rich Felker 2019-06-18 21:49 ` Reinoud Koornstra 2019-06-18 21:58 ` Rich Felker 2019-06-18 22:54 ` Reinoud Koornstra
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).