C++ program with no dependencies except musl

C++ program with no dependencies except musl

[Paul Kaletta]

Hi,

I'm just getting started with musl, and have two questions.

On Arch Linux I installed the packages for musl (vesion 1.1.16-2), and
gcc (version 7.2.0-2).

I have this program:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    printf("Hello!\n");
    exit(0);
}

I have stored it in justmain.c, and justmain.cpp.

I can easily compile it with:

$ musl-gcc -o justmain_static_c justmain.c -static

However, when I do not want a dynamically linked library, I get an
error:

$ musl-gcc -o justmain_dynamic_c justmain.c
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/crtbegin.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

The error goes away when I append the -pie, or -no-pie linker option
to the build command line.  What is happening here, and why do both
options work?

For a little project of mine I would like to use C++ language
features, but leave out the default C++ standard library.  I was also
thinking about using musl together with tinystl
(https://github.com/mendsley/tinystl), which is header-only.

I found some good sources (http://www.avabodh.com/cxxin/nostdlib.html,
http://wiki.osdev.org/C%2B%2B,
http://wiki.osdev.org/Calling_Global_Constructors), but I'm still
figuring out how to apply the information to my use case.

I have a hard time with the basics already.  I can take the program
from above and compile it as C++.

$ musl-gcc -std=c++11 -g -nostdlib -fno-exceptions -fno-rtti justmain.cpp -o justmain_cpp --entry main -L /usr/lib/musl/lib/ -lc

The resulting binary works.  When I add -static, I can compile
succesfully, but the resulting binary gives me a segmentation fault.

$ musl-gcc -std=c++11 -g -nostdlib -fno-exceptions -fno-rtti justmain.cpp -o justmain_static_cpp --entry main -L /usr/lib/musl/lib/ -lc -static
$ ./justmain_static_cpp 
Segmentation fault (core dumped)

Let's step through the binary, instruction by instruction, so that we
see where the segfault occurs:

$ gdb ./justmain_static_cpp 
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 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 "x86_64-pc-linux-gnu".
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"...
Reading symbols from ./justmain_static_cpp...done.
(gdb) b main
Breakpoint 1 at 0x400148: file justmain.cpp, line 6.
(gdb) run
Starting program: /home/pkaletta/justmain_static_cpp 

Breakpoint 1, main () at justmain.cpp:6
6	    printf("Hello!\n");
(gdb) stepi
0x000000000040014f	6	    printf("Hello!\n");
(gdb) 
0x0000000000400182 in puts ()
(gdb) 
0x0000000000400189 in puts ()
(gdb) 
0x000000000040018b in puts ()
(gdb) 
0x000000000040018e in puts ()
(gdb) 
0x000000000040018f in puts ()
(gdb) 
0x0000000000400190 in puts ()
(gdb) 
0x0000000000400192 in puts ()
(gdb) 
0x0000000000400195 in puts ()
(gdb) 
0x000000000040019b in puts ()
(gdb) 
0x000000000040019d in puts ()
(gdb) 
0x00000000004001a9 in puts ()
(gdb) 
0x00000000004001ac in puts ()
(gdb) 
0x00000000004001af in puts ()
(gdb) 
0x0000000000400442 in fputs_unlocked ()
(gdb) 
0x0000000000400444 in fputs_unlocked ()
(gdb) 
0x0000000000400445 in fputs_unlocked ()
(gdb) 
0x0000000000400448 in fputs_unlocked ()
(gdb) 
0x0000000000400449 in fputs_unlocked ()
(gdb) 
0x000000000040044c in fputs_unlocked ()
(gdb) 
0x00000000004005b0 in strlen ()
(gdb) 
0x00000000004005b4 in strlen ()
(gdb) 
0x00000000004005b7 in strlen ()
(gdb) 
0x00000000004005b9 in strlen ()
(gdb) 
0x00000000004005bc in strlen ()
(gdb) 
0x00000000004005c5 in strlen ()
(gdb) 
0x00000000004005c9 in strlen ()
(gdb) 
0x00000000004005cd in strlen ()
(gdb) 
0x00000000004005c0 in strlen ()
(gdb) 
0x00000000004005c3 in strlen ()
(gdb) 
0x00000000004005c5 in strlen ()
(gdb) 
0x00000000004005c9 in strlen ()
(gdb) 
0x00000000004005cd in strlen ()
(gdb) 
0x00000000004005c0 in strlen ()
(gdb) 
0x00000000004005c3 in strlen ()
(gdb) 
0x00000000004005c5 in strlen ()
(gdb) 
0x00000000004005c9 in strlen ()
(gdb) 
0x00000000004005cd in strlen ()
(gdb) 
0x00000000004005c0 in strlen ()
(gdb) 
0x00000000004005c3 in strlen ()
(gdb) 
0x00000000004005c5 in strlen ()
(gdb) 
0x00000000004005c9 in strlen ()
(gdb) 
0x00000000004005cd in strlen ()
(gdb) 
0x00000000004005c0 in strlen ()
(gdb) 
0x00000000004005c3 in strlen ()
(gdb) 
0x00000000004005c5 in strlen ()
(gdb) 
0x00000000004005c9 in strlen ()
(gdb) 
0x00000000004005cd in strlen ()
(gdb) 
0x00000000004005c0 in strlen ()
(gdb) 
0x00000000004005c3 in strlen ()
(gdb) 
0x00000000004005c5 in strlen ()
(gdb) 
0x00000000004005c9 in strlen ()
(gdb) 
0x00000000004005cd in strlen ()
(gdb) 
0x00000000004005cf in strlen ()
(gdb) 
0x00000000004005d2 in strlen ()
(gdb) 
0x00000000004005dc in strlen ()
(gdb) 
0x00000000004005e6 in strlen ()
(gdb) 
0x00000000004005ea in strlen ()
(gdb) 
0x00000000004005ed in strlen ()
(gdb) 
0x00000000004005f0 in strlen ()
(gdb) 
0x00000000004005f3 in strlen ()
(gdb) 
0x0000000000400614 in strlen ()
(gdb) 
0x0000000000400617 in strlen ()
(gdb) 
0x0000000000400619 in strlen ()
(gdb) 
0x000000000040061c in strlen ()
(gdb) 
0x000000000040061f in strlen ()
(gdb) 
0x0000000000400451 in fputs_unlocked ()
(gdb) 
0x0000000000400454 in fputs_unlocked ()
(gdb) 
0x0000000000400457 in fputs_unlocked ()
(gdb) 
0x000000000040045a in fputs_unlocked ()
(gdb) 
0x000000000040045d in fputs_unlocked ()
(gdb) 
0x0000000000400462 in fputs_unlocked ()
(gdb) 
0x0000000000400522 in fwrite_unlocked ()
(gdb) 
0x0000000000400524 in fwrite_unlocked ()
(gdb) 
0x0000000000400526 in fwrite_unlocked ()
(gdb) 
0x000000000040052b in fwrite_unlocked ()
(gdb) 
0x000000000040052d in fwrite_unlocked ()
(gdb) 
0x000000000040052f in fwrite_unlocked ()
(gdb) 
0x0000000000400532 in fwrite_unlocked ()
(gdb) 
0x0000000000400533 in fwrite_unlocked ()
(gdb) 
0x0000000000400534 in fwrite_unlocked ()
(gdb) 
0x0000000000400537 in fwrite_unlocked ()
(gdb) 
0x000000000040053b in fwrite_unlocked ()
(gdb) 
0x000000000040053e in fwrite_unlocked ()
(gdb) 
0x0000000000400541 in fwrite_unlocked ()
(gdb) 
0x0000000000400545 in fwrite_unlocked ()
(gdb) 
0x0000000000400548 in fwrite_unlocked ()
(gdb) 
0x000000000040054b in fwrite_unlocked ()
(gdb) 
0x000000000040054f in fwrite_unlocked ()
(gdb) 
0x0000000000400555 in fwrite_unlocked ()
(gdb) 
0x0000000000400558 in fwrite_unlocked ()
(gdb) 
0x000000000040055a in fwrite_unlocked ()
(gdb) 
0x0000000000400567 in fwrite_unlocked ()
(gdb) 
0x000000000040056a in fwrite_unlocked ()
(gdb) 
0x000000000040056d in fwrite_unlocked ()
(gdb) 
0x0000000000400570 in fwrite_unlocked ()
(gdb) 
0x0000000000400477 in __fwritex ()
(gdb) 
0x0000000000400479 in __fwritex ()
(gdb) 
0x000000000040047b in __fwritex ()
(gdb) 
0x000000000040047e in __fwritex ()
(gdb) 
0x000000000040047f in __fwritex ()
(gdb) 
0x0000000000400480 in __fwritex ()
(gdb) 
0x0000000000400483 in __fwritex ()
(gdb) 
0x0000000000400486 in __fwritex ()
(gdb) 
0x000000000040048a in __fwritex ()
(gdb) 
0x000000000040048f in __fwritex ()
(gdb) 
0x00000000004004b4 in __fwritex ()
(gdb) 
0x00000000004004b7 in __fwritex ()
(gdb) 
0x00000000004003f6 in __towrite ()
(gdb) 
0x00000000004003fc in __towrite ()
(gdb) 
0x00000000004003ff in __towrite ()
(gdb) 
0x0000000000400401 in __towrite ()
(gdb) 
0x0000000000400407 in __towrite ()
(gdb) 
0x0000000000400409 in __towrite ()
(gdb) 
0x000000000040040b in __towrite ()
(gdb) 
0x0000000000400416 in __towrite ()
(gdb) 
0x000000000040041a in __towrite ()
(gdb) 
0x0000000000400422 in __towrite ()
(gdb) 
0x000000000040042a in __towrite ()
(gdb) 
0x000000000040042e in __towrite ()
(gdb) 
0x0000000000400432 in __towrite ()
(gdb) 
0x0000000000400436 in __towrite ()
(gdb) 
0x000000000040043a in __towrite ()
(gdb) 
0x000000000040043c in __towrite ()
(gdb) 
0x00000000004004bc in __fwritex ()
(gdb) 
0x00000000004004be in __fwritex ()
(gdb) 
0x0000000000400491 in __fwritex ()
(gdb) 
0x0000000000400495 in __fwritex ()
(gdb) 
0x0000000000400499 in __fwritex ()
(gdb) 
0x000000000040049c in __fwritex ()
(gdb) 
0x00000000004004c4 in __fwritex ()
(gdb) 
0x00000000004004cb in __fwritex ()
(gdb) 
0x00000000004004ce in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004d5 in __fwritex ()
(gdb) 
0x00000000004004db in __fwritex ()
(gdb) 
0x00000000004004df in __fwritex ()
(gdb) 
0x00000000004004e1 in __fwritex ()
(gdb) 
0x00000000004004e4 in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004d5 in __fwritex ()
(gdb) 
0x00000000004004db in __fwritex ()
(gdb) 
0x00000000004004df in __fwritex ()
(gdb) 
0x00000000004004e1 in __fwritex ()
(gdb) 
0x00000000004004e4 in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004d5 in __fwritex ()
(gdb) 
0x00000000004004db in __fwritex ()
(gdb) 
0x00000000004004df in __fwritex ()
(gdb) 
0x00000000004004e1 in __fwritex ()
(gdb) 
0x00000000004004e4 in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004d5 in __fwritex ()
(gdb) 
0x00000000004004db in __fwritex ()
(gdb) 
0x00000000004004df in __fwritex ()
(gdb) 
0x00000000004004e1 in __fwritex ()
(gdb) 
0x00000000004004e4 in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004d5 in __fwritex ()
(gdb) 
0x00000000004004db in __fwritex ()
(gdb) 
0x00000000004004df in __fwritex ()
(gdb) 
0x00000000004004e1 in __fwritex ()
(gdb) 
0x00000000004004e4 in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004d5 in __fwritex ()
(gdb) 
0x00000000004004db in __fwritex ()
(gdb) 
0x00000000004004df in __fwritex ()
(gdb) 
0x00000000004004e1 in __fwritex ()
(gdb) 
0x00000000004004e4 in __fwritex ()
(gdb) 
0x00000000004004d0 in __fwritex ()
(gdb) 
0x00000000004004d3 in __fwritex ()
(gdb) 
0x00000000004004e8 in __fwritex ()
(gdb) 
0x00000000004004ec in __fwritex ()
(gdb) 
0x00000000004004ef in __fwritex ()
(gdb) 
0x00000000004004f2 in __fwritex ()
(gdb) 
0x0000000000400623 in memcpy ()
(gdb) 
0x0000000000400626 in memcpy ()
(gdb) 
0x000000000040062a in memcpy ()
(gdb) 
0x0000000000400640 in memcpy ()
(gdb) 
0x0000000000400643 in memcpy ()
(gdb) 
0x0000000000400647 in memcpy ()
(gdb) 
0x000000000040064a in memcpy ()
(gdb) 
0x000000000040064d in memcpy ()
(gdb) 
0x000000000040064f in memcpy ()
(gdb) 
0x0000000000400650 in memcpy ()
(gdb) 
0x0000000000400652 in memcpy ()
(gdb) 
0x000000000040064f in memcpy ()
(gdb) 
0x0000000000400650 in memcpy ()
(gdb) 
0x0000000000400652 in memcpy ()
(gdb) 
0x000000000040064f in memcpy ()
(gdb) 
0x0000000000400650 in memcpy ()
(gdb) 
0x0000000000400652 in memcpy ()
(gdb) 
0x000000000040064f in memcpy ()
(gdb) 
0x0000000000400650 in memcpy ()
(gdb) 
0x0000000000400652 in memcpy ()
(gdb) 
0x000000000040064f in memcpy ()
(gdb) 
0x0000000000400650 in memcpy ()
(gdb) 
0x0000000000400652 in memcpy ()
(gdb) 
0x000000000040064f in memcpy ()
(gdb) 
0x0000000000400650 in memcpy ()
(gdb) 
0x0000000000400652 in memcpy ()
(gdb) 
0x0000000000400654 in memcpy ()
(gdb) 
0x00000000004004f7 in __fwritex ()
(gdb) 
0x00000000004004fb in __fwritex ()
(gdb) 
0x00000000004004ff in __fwritex ()
(gdb) 
0x000000000040051a in __fwritex ()
(gdb) 
0x000000000040051b in __fwritex ()
(gdb) 
0x000000000040051c in __fwritex ()
(gdb) 
0x000000000040051d in __fwritex ()
(gdb) 
0x000000000040051f in __fwritex ()
(gdb) 
0x0000000000400521 in __fwritex ()
(gdb) 
0x0000000000400575 in fwrite_unlocked ()
(gdb) 
0x0000000000400578 in fwrite_unlocked ()
(gdb) 
0x000000000040058c in fwrite_unlocked ()
(gdb) 
0x000000000040058f in fwrite_unlocked ()
(gdb) 
0x0000000000400599 in fwrite_unlocked ()
(gdb) 
0x000000000040059d in fwrite_unlocked ()
(gdb) 
0x00000000004005a0 in fwrite_unlocked ()
(gdb) 
0x00000000004005a1 in fwrite_unlocked ()
(gdb) 
0x00000000004005a2 in fwrite_unlocked ()
(gdb) 
0x00000000004005a4 in fwrite_unlocked ()
(gdb) 
0x00000000004005a6 in fwrite_unlocked ()
(gdb) 
0x00000000004005a8 in fwrite_unlocked ()
(gdb) 
0x00000000004005aa in fwrite_unlocked ()
(gdb) 
0x0000000000400467 in fputs_unlocked ()
(gdb) 
0x000000000040046a in fputs_unlocked ()
(gdb) 
0x000000000040046d in fputs_unlocked ()
(gdb) 
0x0000000000400470 in fputs_unlocked ()
(gdb) 
0x0000000000400471 in fputs_unlocked ()
(gdb) 
0x0000000000400473 in fputs_unlocked ()
(gdb) 
0x0000000000400474 in fputs_unlocked ()
(gdb) 
0x0000000000400476 in fputs_unlocked ()
(gdb) 
0x00000000004001b4 in puts ()
(gdb) 
0x00000000004001b6 in puts ()
(gdb) 
0x00000000004001bb in puts ()
(gdb) 
0x00000000004001bd in puts ()
(gdb) 
0x00000000004001c4 in puts ()
(gdb) 
0x00000000004001df in puts ()
(gdb) 
0x00000000004001e4 in puts ()
(gdb) 
0x00000000004001e7 in puts ()
(gdb) 
0x00000000004002b9 in __overflow ()
(gdb) 
0x00000000004002ba in __overflow ()
(gdb) 
0x00000000004002bd in __overflow ()
(gdb) 
0x00000000004002c1 in __overflow ()
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x00000000004002c1 in __overflow ()
(gdb)

I'm not sure what exactly is happening, but I suspect that some global
init function for musl was not called, which results in the observed
behavior.

My goal is a minimal example of a C++ program that depends on musl and
nothing else.  It would be nice if it could be linked both statically
and dynamically.  I realize that some C++ language features will need
some infrastructure that is normally provided by the C++ runtime
library.  But as a first step: what is required to get the above
program to compile (with a C++ compiler) to a statically linked binary
that actually works?

Can I use the musl-gcc wrapper with -std=c++11 for my purpose, or do I
need a more sophisticated approach?

Best regards,
Paul

Re: C++ program with no dependencies except musl

[Szabolcs Nagy]

* Paul Kaletta <pk@paulkaletta.org> [2017-10-02 12:05:33 +0200]:
> I'm just getting started with musl, and have two questions.
> 
> On Arch Linux I installed the packages for musl (vesion 1.1.16-2), and
> gcc (version 7.2.0-2).
> 
> I have this program:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(void)
> {
>     printf("Hello!\n");
>     exit(0);
> }
> 
> I have stored it in justmain.c, and justmain.cpp.
> 
> I can easily compile it with:
> 
> $ musl-gcc -o justmain_static_c justmain.c -static
> 

musl-gcc is a hack to wrap the system gcc to make it use musl
instead of the system c library and drop the system -I and -L paths.

so your gcc is most likely configured against glibc not against
musl which can cause various issues:
- system libatomics.so may fail to load (it uses a gnu
extension that is only supported by the glibc dynamic loader.
matters if atomics are not inlined e.g. 16byte atomics is used)
- there may be symbol versioning issues (musl loader does not
support glibc compatible symbol versions, it affects libgcc_s.so
which is needed for c++ code for the unwinder)
- broken gthread which incorrectly detects single-threadedness
in case of static linking with libstdc++.
- different __*INT*_TYPE macro definitions than in libc headers
(most code should work fine, but some things might fail:
e.g. gfortran ffi calls into c functions using uint_fast16_t)
- many other details i dont remember now..

the recommended use of musl on a non-musl system is via a cross
toolchain that is built against musl (e.g.
https://github.com/richfelker/musl-cross-make
can build you one)

> However, when I do not want a dynamically linked library, I get an
> error:
> 
> $ musl-gcc -o justmain_dynamic_c justmain.c
> /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/crtbegin.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> 
> The error goes away when I append the -pie, or -no-pie linker option
> to the build command line.  What is happening here, and why do both
> options work?
> 

the host gcc most likely defaults to pie, the musl-gcc wrapper
assumes traditional non-default-pie gcc (since that was the only
way to build gcc when musl-gcc was written).

i don't know if the musl-gcc specs file can be updated to support
both cases (the specs file does not know the default, only what
the user specified explicitly).

> For a little project of mine I would like to use C++ language
> features, but leave out the default C++ standard library.  I was also
> thinking about using musl together with tinystl
> (https://github.com/mendsley/tinystl), which is header-only.
> 
> I found some good sources (http://www.avabodh.com/cxxin/nostdlib.html,
> http://wiki.osdev.org/C%2B%2B,
> http://wiki.osdev.org/Calling_Global_Constructors), but I'm still
> figuring out how to apply the information to my use case.
> 
> I have a hard time with the basics already.  I can take the program
> from above and compile it as C++.
> 
> $ musl-gcc -std=c++11 -g -nostdlib -fno-exceptions -fno-rtti justmain.cpp -o justmain_cpp --entry main -L /usr/lib/musl/lib/ -lc
> 
> The resulting binary works.  When I add -static, I can compile
> succesfully, but the resulting binary gives me a segmentation fault.
> 
> $ musl-gcc -std=c++11 -g -nostdlib -fno-exceptions -fno-rtti justmain.cpp -o justmain_static_cpp --entry main -L /usr/lib/musl/lib/ -lc -static
> $ ./justmain_static_cpp 
> Segmentation fault (core dumped)
> 

if you use -nostdlib you have to be careful how you link,
since you jump directly to main without initializing the
libc things will break (crt*.o files are there for a reason..)

> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004002c1 in __overflow ()
> (gdb)
> 
> I'm not sure what exactly is happening, but I suspect that some global
> init function for musl was not called, which results in the observed
> behavior.
> 

you need to add the appropriate crt files (and specify
pie/no-pie)

> My goal is a minimal example of a C++ program that depends on musl and
> nothing else.  It would be nice if it could be linked both statically
> and dynamically.  I realize that some C++ language features will need
> some infrastructure that is normally provided by the C++ runtime
> library.  But as a first step: what is required to get the above
> program to compile (with a C++ compiler) to a statically linked binary
> that actually works?
> 
> Can I use the musl-gcc wrapper with -std=c++11 for my purpose, or do I
> need a more sophisticated approach?
> 

use a cross toolchain, with that, arbitrary c++11 code should
compile with both static and dynamic linking.

> Best regards,
> Paul

musl-cross-make doesn't install gcc binaries

[Didier Kryn]

     Hello musl fans.

     Since this is my first message to this list, let me introduce 
myself. I'm a retired physicist and Linux hobyist. In 2014, I started to 
build a gcc-musl toolchain to run on Debian Wheezy. It took me about two 
years of try-and-fail learning because I had the ambition that my gcc 
understands C, C++ *and* Ada. I started from a combination of tools from 
Sabotage-Linux and Debian and finaly was able to build a gcc-4.7 
toolchain statically linked against musl-1.1.5. I have now created a 
full-featured development platform based on that toolchain, in a chroot. 
This platform can re-build itself from sources and most applications are 
static binaries.

      I have recently discovered the existence of musl-cross-make and 
thought it would be a great way to upgrade my toolchain (forgetting 
temporarily Ada). I downloaded it in my musl chroot. It built without 
error, which is a pretty new experience for me - congratulations! But, 
after make install, only binutils' binaries are installed:

/# ls /usr/pkg/x86_64-linux-musl
bin  include  lib
/# ls /usr/pkg/x86_64-linux-musl/bin
ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  readelf  strip

     The gcc binaries seem to be in 
musl-cross-make/build/local/x86_64-linux-musl/obj_toolchain/gcc (cc1,  
cc1plus,  gcc-ar,  gcc-cross etc). Are these the final gcc binaries or 
intermediate tools?

     Thanks.
                                 Didier

Re: musl-cross-make doesn't install gcc binaries

[Rich Felker]

On Mon, Oct 02, 2017 at 04:57:16PM +0200, Didier Kryn wrote:
>     Hello musl fans.
> 
>     Since this is my first message to this list, let me introduce
> myself. I'm a retired physicist and Linux hobyist. In 2014, I
> started to build a gcc-musl toolchain to run on Debian Wheezy. It
> took me about two years of try-and-fail learning because I had the
> ambition that my gcc understands C, C++ *and* Ada. I started from a
> combination of tools from Sabotage-Linux and Debian and finaly was
> able to build a gcc-4.7 toolchain statically linked against
> musl-1.1.5. I have now created a full-featured development platform
> based on that toolchain, in a chroot. This platform can re-build
> itself from sources and most applications are static binaries.
> 
>      I have recently discovered the existence of musl-cross-make and
> thought it would be a great way to upgrade my toolchain (forgetting
> temporarily Ada). I downloaded it in my musl chroot. It built
> without error, which is a pretty new experience for me -
> congratulations! But, after make install, only binutils' binaries
> are installed:
> 
> /# ls /usr/pkg/x86_64-linux-musl
> bin  include  lib
> /# ls /usr/pkg/x86_64-linux-musl/bin
> ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  readelf  strip
> 
>     The gcc binaries seem to be in
> musl-cross-make/build/local/x86_64-linux-musl/obj_toolchain/gcc
> (cc1,  cc1plus,  gcc-ar,  gcc-cross etc). Are these the final gcc
> binaries or intermediate tools?

What "make install" command line did you use, and what options (if
any) in config.mak? You need to specify the output directory where the
toolchain will be installed; it would not appear under /usr/pkg unless
you configured it as such.

Rich

Re: musl-cross-make doesn't install gcc binaries

[Didier Kryn]

Le 02/10/2017 à 17:57, Rich Felker a écrit :
>>       I have recently discovered the existence of musl-cross-make and
>> thought it would be a great way to upgrade my toolchain (forgetting
>> temporarily Ada). I downloaded it in my musl chroot. It built
>> without error, which is a pretty new experience for me -
>> congratulations! But, after make install, only binutils' binaries
>> are installed:
>>
>> /# ls /usr/pkg/x86_64-linux-musl
>> bin  include  lib
>> /# ls /usr/pkg/x86_64-linux-musl/bin
>> ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  readelf  strip
>>
>>      The gcc binaries seem to be in
>> musl-cross-make/build/local/x86_64-linux-musl/obj_toolchain/gcc
>> (cc1,  cc1plus,  gcc-ar,  gcc-cross etc). Are these the final gcc
>> binaries or intermediate tools?
> What "make install" command line did you use, and what options (if
> any) in config.mak? You need to specify the output directory where the
> toolchain will be installed; it would not appear under /usr/pkg unless
> you configured it as such.
>
     I just ran 'make'; and, when it was finished, 'make install'

     Everything is configured in config.mak. Here it is (I've removed 
the comments):

# config.mak
TARGET = x86_64-linux-musl
OUTPUT = /usr/pkg
DL_CMD = wget -c -O

COMMON_CONFIG += CC="gcc -static --static" CXX="g++ -static --static"
COMMON_CONFIG += CFLAGS="-O2" CXXFLAGS="-O2"
COMMON_CONFIG += --disable-nls
GCC_CONFIG += --enable-languages=c,c++
GCC_CONFIG += --disable-multilib

     'make install' creates /usr/pkg/x86_64-linux-musl, and the subdirs 
bin, include and lib. The issue is that, in bin, only binutils' 
executables are installed.

     Thanks.
                             Didier

Re: musl-cross-make doesn't install gcc binaries

[Didier Kryn]

Le 03/10/2017 à 10:11, Didier Kryn a écrit :
> Le 02/10/2017 à 17:57, Rich Felker a écrit :
>>>       I have recently discovered the existence of musl-cross-make and
>>> thought it would be a great way to upgrade my toolchain (forgetting
>>> temporarily Ada). I downloaded it in my musl chroot. It built
>>> without error, which is a pretty new experience for me -
>>> congratulations! But, after make install, only binutils' binaries
>>> are installed:
>>>
>>> /# ls /usr/pkg/x86_64-linux-musl
>>> bin  include  lib
>>> /# ls /usr/pkg/x86_64-linux-musl/bin
>>> ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  readelf strip
>>>
>>>      The gcc binaries seem to be in
>>> musl-cross-make/build/local/x86_64-linux-musl/obj_toolchain/gcc
>>> (cc1,  cc1plus,  gcc-ar,  gcc-cross etc). Are these the final gcc
>>> binaries or intermediate tools?
>> What "make install" command line did you use, and what options (if
>> any) in config.mak? You need to specify the output directory where the
>> toolchain will be installed; it would not appear under /usr/pkg unless
>> you configured it as such.
>>
>     I just ran 'make'; and, when it was finished, 'make install'
>
>     Everything is configured in config.mak. Here it is (I've removed 
> the comments):
>
> # config.mak
> TARGET = x86_64-linux-musl
> OUTPUT = /usr/pkg
> DL_CMD = wget -c -O
>
> COMMON_CONFIG += CC="gcc -static --static" CXX="g++ -static --static"
> COMMON_CONFIG += CFLAGS="-O2" CXXFLAGS="-O2"
> COMMON_CONFIG += --disable-nls
> GCC_CONFIG += --enable-languages=c,c++
> GCC_CONFIG += --disable-multilib
>
>     'make install' creates /usr/pkg/x86_64-linux-musl, and the subdirs 
> bin, include and lib. The issue is that, in bin, only binutils' 
> executables are installed.
>
>     Thanks.
>                             Didier
>
     I forgot to mention that everything looks fine in subdirs include 
and lib. Only the gcc executables are missing.

Re: musl-cross-make doesn't install gcc binaries

[Szabolcs Nagy]

* Didier Kryn <kryn@in2p3.fr> [2017-10-03 10:18:58 +0200]:

> Le 03/10/2017 à 10:11, Didier Kryn a écrit :
> > Le 02/10/2017 à 17:57, Rich Felker a écrit :
> > > >       I have recently discovered the existence of musl-cross-make and
> > > > thought it would be a great way to upgrade my toolchain (forgetting
> > > > temporarily Ada). I downloaded it in my musl chroot. It built
> > > > without error, which is a pretty new experience for me -
> > > > congratulations! But, after make install, only binutils' binaries
> > > > are installed:
> > > > 
> > > > /# ls /usr/pkg/x86_64-linux-musl
> > > > bin  include  lib
> > > > /# ls /usr/pkg/x86_64-linux-musl/bin
> > > > ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  readelf strip
> > > > 
> > > >      The gcc binaries seem to be in
> > > > musl-cross-make/build/local/x86_64-linux-musl/obj_toolchain/gcc
> > > > (cc1,  cc1plus,  gcc-ar,  gcc-cross etc). Are these the final gcc
> > > > binaries or intermediate tools?
> > > What "make install" command line did you use, and what options (if
> > > any) in config.mak? You need to specify the output directory where the
> > > toolchain will be installed; it would not appear under /usr/pkg unless
> > > you configured it as such.
> > > 
> >     I just ran 'make'; and, when it was finished, 'make install'
> > 
> >     Everything is configured in config.mak. Here it is (I've removed the
> > comments):
> > 
> > # config.mak
> > TARGET = x86_64-linux-musl
> > OUTPUT = /usr/pkg
> > DL_CMD = wget -c -O
> > 
> > COMMON_CONFIG += CC="gcc -static --static" CXX="g++ -static --static"
> > COMMON_CONFIG += CFLAGS="-O2" CXXFLAGS="-O2"
> > COMMON_CONFIG += --disable-nls
> > GCC_CONFIG += --enable-languages=c,c++
> > GCC_CONFIG += --disable-multilib
> > 
> >     'make install' creates /usr/pkg/x86_64-linux-musl, and the subdirs
> > bin, include and lib. The issue is that, in bin, only binutils'
> > executables are installed.
> > 
> >     Thanks.
> >                             Didier
> > 
>     I forgot to mention that everything looks fine in subdirs include and
> lib. Only the gcc executables are missing.
> 

it's a cross compiler, so you won't have gcc, but x86_64-linux-musl-gcc

Re: musl-cross-make doesn't install gcc binaries

[Didier Kryn]

Le 03/10/2017 à 11:37, Szabolcs Nagy a écrit :
> * Didier Kryn <kryn@in2p3.fr> [2017-10-03 10:18:58 +0200]:
>
>> Le 03/10/2017 à 10:11, Didier Kryn a écrit :
>>> Le 02/10/2017 à 17:57, Rich Felker a écrit :
>>>>>        I have recently discovered the existence of musl-cross-make and
>>>>> thought it would be a great way to upgrade my toolchain (forgetting
>>>>> temporarily Ada). I downloaded it in my musl chroot. It built
>>>>> without error, which is a pretty new experience for me -
>>>>> congratulations! But, after make install, only binutils' binaries
>>>>> are installed:
>>>>>
>>>>> /# ls /usr/pkg/x86_64-linux-musl
>>>>> bin  include  lib
>>>>> /# ls /usr/pkg/x86_64-linux-musl/bin
>>>>> ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  readelf strip
>>>>>
>>>>>       The gcc binaries seem to be in
>>>>> musl-cross-make/build/local/x86_64-linux-musl/obj_toolchain/gcc
>>>>> (cc1,  cc1plus,  gcc-ar,  gcc-cross etc). Are these the final gcc
>>>>> binaries or intermediate tools?
>>>> What "make install" command line did you use, and what options (if
>>>> any) in config.mak? You need to specify the output directory where the
>>>> toolchain will be installed; it would not appear under /usr/pkg unless
>>>> you configured it as such.
>>>>
>>>      I just ran 'make'; and, when it was finished, 'make install'
>>>
>>>      Everything is configured in config.mak. Here it is (I've removed the
>>> comments):
>>>
>>> # config.mak
>>> TARGET = x86_64-linux-musl
>>> OUTPUT = /usr/pkg
>>> DL_CMD = wget -c -O
>>>
>>> COMMON_CONFIG += CC="gcc -static --static" CXX="g++ -static --static"
>>> COMMON_CONFIG += CFLAGS="-O2" CXXFLAGS="-O2"
>>> COMMON_CONFIG += --disable-nls
>>> GCC_CONFIG += --enable-languages=c,c++
>>> GCC_CONFIG += --disable-multilib
>>>
>>>      'make install' creates /usr/pkg/x86_64-linux-musl, and the subdirs
>>> bin, include and lib. The issue is that, in bin, only binutils'
>>> executables are installed.
>>>
>>>      Thanks.
>>>                              Didier
>>>
>>      I forgot to mention that everything looks fine in subdirs include and
>> lib. Only the gcc executables are missing.
>>
> it's a cross compiler, so you won't have gcc, but x86_64-linux-musl-gcc
     But it isn't installed and, BTW, the installed binutils executables 
aren't prefixed with x86_64-linux-musl-

     When I remove the line 'OUTPUT = /usr/pkg'  in config.mak, to leave 
it use the default, then the installation occurs in subdir 'output' of 
the source tree, and it seems much more familiar to me, with more 
subdirs, such as libexec, share and x86_64-linux-musl, which are not 
present otherwise. And all the executables are correctly prefixed.

     Therefore the problem is restricted to the processing of the custom 
install dir. Given the cross-compiler is sysrooted, this isn't a big 
deal, but better to know.

     Didier

Re: musl-cross-make doesn't install gcc binaries

[Szabolcs Nagy]

* Didier Kryn <kryn@in2p3.fr> [2017-10-03 12:38:49 +0200]:
> Le 03/10/2017 à 11:37, Szabolcs Nagy a écrit :
> > it's a cross compiler, so you won't have gcc, but x86_64-linux-musl-gcc
>     But it isn't installed and, BTW, the installed binutils executables
> aren't prefixed with x86_64-linux-musl-
> 
>     When I remove the line 'OUTPUT = /usr/pkg'  in config.mak, to leave it
> use the default, then the installation occurs in subdir 'output' of the
> source tree, and it seems much more familiar to me, with more subdirs, such
> as libexec, share and x86_64-linux-musl, which are not present otherwise.
> And all the executables are correctly prefixed.
> 
>     Therefore the problem is restricted to the processing of the custom
> install dir. Given the cross-compiler is sysrooted, this isn't a big deal,
> but better to know.
> 

i use custom OUTPUT dir and never had a problem

(although i pass it as a make argument like

make install TARGET=x86_64-linux-musl OUTPUT=/path

and then i have
/usr/bin/install -c xgcc /path/bin/x86_64-linux-musl-gcc
in my build log)

Re: musl-cross-make doesn't install gcc binaries

[Didier Kryn]

Le 03/10/2017 à 12:59, Szabolcs Nagy a écrit :
> * Didier Kryn <kryn@in2p3.fr> [2017-10-03 12:38:49 +0200]:
>> Le 03/10/2017 à 11:37, Szabolcs Nagy a écrit :
>>> it's a cross compiler, so you won't have gcc, but x86_64-linux-musl-gcc
>>      But it isn't installed and, BTW, the installed binutils executables
>> aren't prefixed with x86_64-linux-musl-
>>
>>      When I remove the line 'OUTPUT = /usr/pkg'  in config.mak, to leave it
>> use the default, then the installation occurs in subdir 'output' of the
>> source tree, and it seems much more familiar to me, with more subdirs, such
>> as libexec, share and x86_64-linux-musl, which are not present otherwise.
>> And all the executables are correctly prefixed.
>>
>>      Therefore the problem is restricted to the processing of the custom
>> install dir. Given the cross-compiler is sysrooted, this isn't a big deal,
>> but better to know.
>>
> i use custom OUTPUT dir and never had a problem
>
> (although i pass it as a make argument like
>
> make install TARGET=x86_64-linux-musl OUTPUT=/path
>
> and then i have
> /usr/bin/install -c xgcc /path/bin/x86_64-linux-musl-gcc
> in my build log)

     OK, got it. I understood the install path as an install *prefix*. I 
should have specified

     'OUTPUT=/usr/pkg/x86_64-linux-musl'

         instead of

     'OUTPUT=/usr/pkg'

     And I didn't notice it created bin, include, lib, libexec and share 
and, since it also created x86_64-linux-musl, which has the name I 
expected and also contains bin, include and lib,  I concentrated on this 
one which wasn't as expected.

     Maybe worth mentionning the path is the base of the sysroot, not a 
prefix. There must be other idiots like me.

      Thanks for your patience.

Didier

     Now it works. Thanks for your patience

Re: musl-cross-make doesn't install gcc binaries

[Szabolcs Nagy]

* Didier Kryn <kryn@in2p3.fr> [2017-10-03 14:55:08 +0200]:
> Le 03/10/2017 à 12:59, Szabolcs Nagy a écrit :
> > i use custom OUTPUT dir and never had a problem
> > 
> > (although i pass it as a make argument like
> > 
> > make install TARGET=x86_64-linux-musl OUTPUT=/path
> > 
> > and then i have
> > /usr/bin/install -c xgcc /path/bin/x86_64-linux-musl-gcc
> > in my build log)
> 
>     OK, got it. I understood the install path as an install *prefix*. I
> should have specified
> 
>     'OUTPUT=/usr/pkg/x86_64-linux-musl'
> 
>         instead of
> 
>     'OUTPUT=/usr/pkg'
> 

no, it should be just /usr/pkg

>     And I didn't notice it created bin, include, lib, libexec and share and,
> since it also created x86_64-linux-musl, which has the name I expected and
> also contains bin, include and lib,  I concentrated on this one which wasn't
> as expected.
> 

the x86_64-linux-musl directory is the sysroot for the target,
it does not contain host binaries (executables for the cross
toolchain)

>     Maybe worth mentionning the path is the base of the sysroot, not a
> prefix. There must be other idiots like me.
> 

no, it's not

>      Thanks for your patience.
> 
> Didier
> 
>     Now it works. Thanks for your patience
> 

you are probably still doing something wrong.

Re: musl-cross-make doesn't install gcc binaries

[Didier Kryn]

Le 04/10/2017 à 12:35, Szabolcs Nagy a écrit :
> * Didier Kryn <kryn@in2p3.fr> [2017-10-03 14:55:08 +0200]:
>> Le 03/10/2017 à 12:59, Szabolcs Nagy a écrit :
>>> i use custom OUTPUT dir and never had a problem
>>>
>>> (although i pass it as a make argument like
>>>
>>> make install TARGET=x86_64-linux-musl OUTPUT=/path
>>>
>>> and then i have
>>> /usr/bin/install -c xgcc /path/bin/x86_64-linux-musl-gcc
>>> in my build log)
>>      OK, got it. I understood the install path as an install *prefix*. I
>> should have specified
>>
>>      'OUTPUT=/usr/pkg/x86_64-linux-musl'
>>
>>          instead of
>>
>>      'OUTPUT=/usr/pkg'
>>
> no, it should be just /usr/pkg
>
>>      And I didn't notice it created bin, include, lib, libexec and share and,
>> since it also created x86_64-linux-musl, which has the name I expected and
>> also contains bin, include and lib,  I concentrated on this one which wasn't
>> as expected.
>>
> the x86_64-linux-musl directory is the sysroot for the target,
> it does not contain host binaries (executables for the cross
> toolchain)
>
>>      Maybe worth mentionning the path is the base of the sysroot, not a
>> prefix. There must be other idiots like me.
>>
> no, it's not
>
>>       Thanks for your patience.
>>
>> Didier
>>
>>      Now it works. Thanks for your patience
>>
> you are probably still doing something wrong.

     I have built the cross compiler with

     TARGET = x86_64-linux-musl
     OUTPUT= /usr/pkg/x86_64-linux-musl

     After installation I have the following subdirs at the top of the tree:

     /usr/pkg/x86_64-linux-musl/bin
     /usr/pkg/x86_64-linux-musl/include
     /usr/pkg/x86_64-linux-musl/lib
     /usr/pkg/x86_64-linux-musl/libexec
     /usr/pkg/x86_64-linux-musl/share
     /usr/pkg/x86_64-linux-musl/x86_64-linux-musl

     The first of these subdirs contains all the necessary executables 
properly prefixed. And the last contains subdirs with the non-prefixed 
executables, the libraries, including libc and the *crt*.o object files.

     I have symlinked the prefixed binaries in /usr/bin and I am now 
re-building all packages with my new gcc-6.3/musl-1.1.16 toolchain :-)

             Didier