[Experiment] Musl-libc on a standard LFS build?

ReaperX7 · 05-05-2015, 03:43 PM

Just had an inkling of an idea, but could musl-libc be effectively used to build a standard B/LFS system and would there be any real problems in doing so?

Have been thinking of what all could be done with alternative software since we last experimented with runit and busybox (mdev and init) and this popped into my head.

hendrickxm · 05-05-2015, 04:40 PM

Should be doable, check out dragora 3, sabotage and alpine linux' bootstrap buildinfo.

Keith Hedger · 05-05-2015, 04:57 PM

If youv'e got any details post them and I will give it a whirl, I have some spare partitions I use for mucking about with new builds, and as I have a complete lfs/blfs install sipted and package managed it's no problem to replace glibc with somthing else., just a matter of doing a search and replace for dependencies and making a build script for the new package.

ReaperX7 · 05-05-2015, 07:16 PM

A few things might need patches, but usually patches aren't that hard to track down. I think our biggest concern will be the C compiler and binutils.

We probably can reference embedded CLFS for how to build musl maybe, but it may need tweaks.

ReaperX7 · 05-06-2015, 01:05 AM

Okay, after a day of work, I got as far as getting musl-libc installed. I'm going to work on libstdc++v3 soon, but so far the results have been encouraging.

I did however find that a lot of GCC will not build against musl without patches so right now the CLFS GCC musl patch for 4.7.3 has proved useful, but it is not without a problem or two. Musl requires a lot of effort to get GCC to build. In truth, it's a royal pain in the ass. An initial try at libstdc++v3 failed miserably. It refused outright to build at all.

I did however build musl-1.0.8 with the following build flags:

Code:

./configure --prefix=/tools \
	    --host=$LFS_TGT

but I may scrub the build and retry with a reworked ~/.bashrc file that targets musl builds specifically as in CLFS-embedded. Overall during the test phase the sanity check only had a warning:

Code:

dummy.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
 main(){}
 ^

Code:

Elf file type is EXEC (Executable file)
Entry point 0x400310
There are 7 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x0000000000000188 0x0000000000000188  R E    8
  INTERP         0x00000000000001c8 0x00000000004001c8 0x00000000004001c8
                 0x0000000000000022 0x0000000000000022  R      1
      [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000534 0x0000000000000534  R E    200000
  LOAD           0x0000000000000538 0x0000000000600538 0x0000000000600538
                 0x0000000000000180 0x0000000000000190  RW     200000
  DYNAMIC        0x0000000000000560 0x0000000000600560 0x0000000000600560
                 0x0000000000000130 0x0000000000000130  RW     8
  GNU_EH_FRAME   0x00000000000004b0 0x00000000004004b0 0x00000000004004b0
                 0x000000000000001c 0x000000000000001c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .hash .dynsym .dynstr .rela.plt .init .plt .text .fini .eh_frame_hdr .eh_frame 
   03     .ctors .dtors .jcr .dynamic .got.plt .data .bss 
   04     .dynamic 
   05     .eh_frame_hdr 
   06

However, the sanity check did indeed pass.

To combat the GCC (libstdc++v3) issue, I may revert to GCC-4.7.3 for the build for sanity in code and patch unless anyone can provide a patch to get GCC working with musl to allow libstdc++v3 to build.

An alternative, though unwelcome, would be to try to build LFS with LLVM/Clang or another C compiler if one exists that is GNU/Linux and musl friendly, or should I just build the temp system with glibc?

hendrickxm · 05-06-2015, 10:41 AM

This should be useful. http://git.savannah.gnu.org/cgit/dra...t/tree/recipes

Not all gcc versions will build with musl.

Keith Hedger · 05-06-2015, 01:21 PM

Quote:

Originally Posted by hendrickxm

This should be useful. http://git.savannah.gnu.org/cgit/dra...t/tree/recipes

Not all gcc versions will build with musl.

I can see this being a problem further down the line, if gcc muscl needs an older version of gcc then there may (will) be a problem with new code needing newer versions of gcc. probably not practical.

ReaperX7 · 05-06-2015, 02:54 PM

Very true. Glibc must be used during the bootstrap at least, but GCC can be built with musl with the patches. I might revert to 4.7.3 for the test. It's stable GCC anyway, so unless anything doesn't play well, I can always try LLVM once I get that far in. Right now I'm only worried about getting a bootable system only.

I might grab Dragora's 4.9.2 GCC patch and try it though and the recipe. We'll see.

ReaperX7 · 05-07-2015, 04:46 AM

Okay, rebuilding 7.7 currently. Bootstrap will be built with glibc and the system will use musl-libc. Going to use the Dragora methods for installation. Hopefully no other patches will be needed.

hendrickxm · 05-07-2015, 07:38 AM

Quote:

Originally Posted by ReaperX7

Okay, rebuilding 7.7 currently. Bootstrap will be built with glibc and the system will use musl-libc. Going to use the Dragora methods for installation. Hopefully no other patches will be needed.

So you are building ch5 from the lfs book and then build a modified ch6 with musl using Dragora's recipes?

ReaperX7 · 05-07-2015, 05:52 PM

Yes. Currently the bootstrap seems to be able to build anything as needed due to the fact it builds GCC in a single shot rather than repeatedly. I think GCC's libstdc++v3 in standalone does require glibc due to the fact you're building it separate from GCC Pass 1 with a new libc compared to a different libc, and then rebuilding GCC yet again for Pass 2 against another libc rather than the native one. This might produce some incompatibilities and library conflicts because libstdc++v3 is built against GCC Pass 1 to the same standards and library code.

Now granted if GCC on the host was built against musl rather than glibc, the pass 1 GCC and libstdc++v3 would have the same libc and there would be no conflicts.

This may be theory, but it makes sense.

ReaperX7 · 05-10-2015, 06:36 PM

GCC failed again. Don't know why but other stuff is failing too. Think I'm going to abort for now.

veerain · 05-10-2015, 11:06 PM

Newer GCC 6.0 git has support added for musl-libc.

ReaperX7 · 05-11-2015, 01:26 AM

There's also the fact musl does include many of the glibc apps as well.