Compiling with musl (an alternate libc)

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
rofl0r
Posts: 2
Joined: Mon 16 Jul 2012, 10:22

#41 Post by rofl0r »

jamesbond wrote: If the mailing list accepts attachment I'll probably package the modified bootstrap tarball hardcoded to build for arm-eabi (the generic "export A=arm" won't work directly).
please dont send a tarball, send a patch, or even better fork it on github and put your patches there (you can open a pull request, and pikhq will most likely accept it)
jamesbond wrote: Sabotage native build worked fine (I tested in x86_64 arch), but just that it won't cross compile (well not easily) and Ibidem told me you have no plans to make it so.
the problem is that sabotage consists of 100+ packages, and most of them can't be cross compiled without huge patch orgies. otoh bootstrap linux consists only of a kernel, busybox and a toolchain, all of them designed for cross compilation.
jamesbond wrote:
want an existing sabotage ARMV7l rootfs ? look at
https://github.com/rofl0r/sabotage/wiki/efika_mx
That's for efikamx though, I don't have the hardware.
the rootfs that's linked there is a generic ARMv7l softfp (vfp) rootfs (no kernel included). it should be possible to use it with qemu (you'll need to specify a kernel on the qemu command line, for example the one aboriginal uses, or one you built yourself with the config aboriginal uses)
jamesbond wrote: Your wiki page there links to crux-arm, and crux-arm rootfs supports qemu versatible-pb too. Will that work? I should give it a try.
yep crux should work as well, and it should be possible to bootstrap sabotage on it.

btw, if you or somebody else plays around with musl and have any issues, join #musl irc channel instead of wasting your time fixing issues that were fixed dozens of times before.
there is a number of well known issues which will lead to segfaults (for example distro toolchains that remove the sysv hash section from binaries will crash on the musl dynlinker). all of them will be detected by a musl veteran in no time.

that said, i hope to see you on IRC, so we can help getting something started quickly.
i really don't like hanging around in forums...

good luck.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#42 Post by jamesbond »

Sorry I've been busy with other things lately. I will send the patch, I'm not too good with git and thus github (all I know is "git clone" and "git pull" but I'm working on it) :D

I know this much so far: I confirmed the problem isn't with musl. The native gcc build in bootstrap pulled "doprnt" from libiberty - that's the one that crashed. It did that because libiberty configure failed to detect that cross-compiler musl has *printf family :? and thus it pulled libiberty's version of *printf that uses doprint.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#43 Post by technosaurus »

seems like I had to add -DGNU_SOURCE and/or -DBSD-SOURCE (or some such) for autotools and others to pick up some stuff in musl ...its still a musl bug because it should be getting defined somewhere in musl headers for those cases, It was easier for me to just add an extra define in my wrapper than track it down though (I would just grep in my /usr/musl/include for anything it couldn't find and add whatever was in the ifdef)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#44 Post by Ibidem »

@jamesbond:
1-see if you can get the git manpages; they are much more helpful than most...
2-the most important:
git branch [-d] [branchname]
shows branches by default, creates branch branchname when branchname is specified, deletes branch branchname when -d or -D is passed.
git checkout [branch | revision | tag]
Checks out a revision or tag, or the current revision in a branch.
git checkout -b <branchname> will create and checkout a new branch <branchname>
git diff [revision1 revision2]
Generates diffs between revision1 & revision2, or (with no parameters) between the last commit and the current status of the tree.
git add <path/to/file> | dir/
Adds a file or directory to the list of changed/new files to be commited in the next commit.
git commit [-a | path/to/something]
Commits all changes in the staging area (default), all changes to tracked files (-a), or all tracked files within a specified path.

@technosaurus:
"feature, not a bug" ;)
Musl defaults to strict ISO C99 in all ISO headers, and the strictest applicable standard in all other cases.
This is the sanest approach to portability: enable extensions when requested, not silently.
In fact, a package that relies on _GNU_SOURCE being on by default is almost certainly not portable, and should be considered buggy...
I've had good luck setting CPPFLAGS and CFLAGS to include the proper defines, find -name config.cache |xargs rm, then reconfigure & rebuild. Some people will export CC="$CC $CFLAGS", for a few packages that are more insane than usual.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#45 Post by jamesbond »

Thanks everyone.

I managed to pinpoint the problem and got it fixed, bootstrap now produces a working native toolchain.

The root of the problem is this: cross-compiler configured with static musl libc fails to compile anything that has a division in them (e.g. printf). This isn't a specific problem with bootstrap, I can easily reproduce the problem in musl-cross too: you can try it yourself: build arm cross-tool, setting forcing musl to use only static library (MUSL_CONFFLAGS=--disable-shared in config.sh). Once you've got the cross-tool, use it to compile:

Code: Select all

#include <stdio.h>
void main() { printf("hello %d\n",5); }
using

Code: Select all

arm-linux-musleabi-gcc -o hello hello.c
In my case I'll get a compile failure saying that "raise" and "abort" cannot be resolved etc ... but these symbols are already in libc.a, so why don't they get pulled in? :?
I can get it to compile (and run) if I pull libc.a explicitly:

Code: Select all

arm-linux-musleabi-gcc -o hello hello.c -lc
And that's how I managed to convince the binutils/gcc configure to work, I need to sprinkle host_configargs='LIBS=-lc' and --with-stage1-libs=-lc generously in the build-scripts.

Of course, this doesn't explain why snprintf from libiberty crash, but I wouldn't even want to touch it ...

With this, I can successfully cross x86_64 to arm with native toolchain in it. I would still consider this as a hack rather than as a proper solution.

Btw I see rofl0r has managed to get GTK going on musl, great job! Image

EDIT: patch sent to musl mailing list. If anyone else is interested I can also upload the patch here.

cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#46 Post by Ibidem »

Currently 0.9.3 has been released; there are several bugfixes for ARM as well as general bugfixes, a static MIPS32 (o32 abi) port, getaddrinfo, ioperm, and iopl have been added (so it's a lot closer to building X), along with a number of syscalls and a few things that improve glibc compatability.

libc.so is the musl loader (ld-musl-$ARCH.so.1). It can now (since 0.9.2, I think) directly execute binaries. If you go
ln -s $syslibdir/libc.so ldd
it acts as ldd (with one exception:
libc.so is not reported, AFAICT)

Rich is testing ASM replacements for some string functions (memcpy is the current project; the version he has is ~2x as fast as the C version).

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#47 Post by Ibidem »

FYI, 0.9.4 may be approaching.
MIPS and ARM bugfixes, several optimisations, blowfish crypt, and a few BSD extensions such as fgetln are among the changes.
Rich is asking whether any other features are desired for the release.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#48 Post by technosaurus »

If anyone is following the musl mail list, one of the requests for help was sha1,md5
See:
https://github.com/libtom/libtomcrypt/t ... src/hashes
If you'd like to help, or at least inform them ... It seems to be more robust than the proposed alternative and unencumbered with license restrictions
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#49 Post by Ibidem »

technosaurus wrote:If anyone is following the musl mail list, one of the requests for help was sha1,md5
See:
https://github.com/libtom/libtomcrypt/t ... src/hashes
If you'd like to help, or at least inform them ... It seems to be more robust than the proposed alternative and unencumbered with license restrictions
Thanks for the info!

By the way, there's a change that just landed that you may be interested in: musl just went from straight ISO C99 by default to _XOPEN_SOURCE=700 _BSD_SOURCE by default. This means that as long as you don't pass -std=c{89,99,11}, a large portion of the functionality will be available OOB.
Also, musl is getting pretty close to C11 support (not threads yet, and there are a few remaining issues, but a large part of it is implemented).
Gregor has ~half of pkgsrc (including Xfce, Xorg, and Mesa) building, so it's fairly compatible now. A large part of the remainder is just dependency waits.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#50 Post by Ibidem »

musl 0.9.6 has been released.

There have been a number of ~trivial bugfixes and optimizations; -O3 is no longer forced (it had been the default for shared libraries because it actually resulted in smaller binaries);
arm (and mips
technosaurus wrote:If anyone is following the musl mail list, one of the requests for help was sha1,md5
See:
https://github.com/libtom/libtomcrypt/t ... src/hashes
If you'd like to help, or at least inform them ... It seems to be more robust than the proposed alternative and unencumbered with license restrictions
md5 has been implemented, based on freebsd's implementation, which is based on libtomcrypt.
sha1 is not planned (as far as I can tell, no libc supports sha1 crypt).

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#51 Post by Karl Godt »

Thanks, want to inform that i was able to build the Puppy guess_fstype with these parameters in the Makefile :

Code: Select all

CC = /usr/local/musl/bin/musl-gcc
CFLAGS = -W -Wall -Os -I/usr/include
LDFLAGS = -static
EXE = guess_fstype

default: $(EXE) tidy

$(EXE):
	@echo "Single compile for guess_fstype ..."
	@$(CC) -o $@ guess_fstype.c main.c $(CFLAGS) $(LDFLAGS) -s
	@ls -sl $@

tidy:
	@rm -f *.o *~ *.bak

clean: tidy
	@rm -f $(EXE)
that works with kernel that have CONFIG_DEBUG_BLOCK_EXT_DEVT=y , which diet was not able using the -nostdinc flag
statically with a size of ls -s 24 while simple gcc LDFLAGS=-static builded too with a bin of ls -s 388 .

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#52 Post by Ibidem »

musl 0.9.8 is out, and currently under discussion is the roadmap for 0.9.9 / 1.0 (as well as promotional materials and testing). If you've got any issues, it would be nice to hear about them soon.

0.9.8 features support for amd64, x86, arm (big and little endian), mips32 (hardfloat, big/little endian), powerpc (static only), and microblaze.
There are several bugfixes (math, asm, corner cases, ...). 0.9.7 had more bugfixes, though. Also, C11 CMPLX macros are now supported, and a few new features have come in.

Rob Landley is starting to switch Aboriginal over to musl, and OpenWRT has just added musl support recently.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#53 Post by Ibidem »

jamesbond wrote:Impressive :D

This is my attempt at building dnsmasq as 32-bit executable under 64-bit environment.

....
4. Went smoothly until it tried to compile log.c, then failed - cannot find _PATH_LOG. This is defined in bits/syslog-path.h, but /opt/musl/include/bits doesn't have this. I just add _PATH_LOG to dnsmasq's config.h and compilation continued and finished.
5. But it failed at link step - saying that it skipped libc.a when searching -lc. This would not happened if I compiled for 64-bits, so I added LDFLAGS=-m32 to the make file, which now looks like this:

Code: Select all

make CC=musl-gcc  CFLAGS"=-Os -static -fno-stack-protector -D_GNU_SOURCE -m32 -I /mnt/sda2/tmp/linux-3.2.2/usr/include/" LDFLAGS=-m32
6. All went well - except that ld cannot find capset/capget.

Code: Select all

dnsmasq.c:(.text+0x1172): undefined reference to `capget'
dnsmasq.c:(.text+0x14d4): undefined reference to `capset'
dnsmasq.c:(.text+0x156a): undefined reference to `capset'
....
Questions:
1. I'm sure the above is not the only one, so the general question is: as I understand it musl strives to be POSIX-compliant (not Linux compliant), however it also strives to be a glibc replacement. musl already implements _GNU_SOURCE, what about compatibilities at this level? Unfortunately, compatibility support == bloat :?

2. Assuming:
- not trying to cross-compile (not as above)
- not trying to migrate the whole system
- building a static binary
How does libs compiled with musl co-operate with libs compiled with glibc? Let's say I already have a libxxxx compiled with glibc (let say openssl's libssl). Will this work with musl - i.e. if I use musl-gcc and include does -lssl (pointing to the appropriate -L) - will this work? Probably not, I suppose.
If not, then I need to compile openssl again and install it on, say, /opt/musl/openssl, and make sure that all my compiles use that version of libgtk+, no?
Well, I revisited this, and dnsmasq now compiles OOB (make PKG_CONFIG=true CC=musl-gcc) :)

and _if_ a library does not import glibc-only symbols, it should work with musl.
For those who are curious how compatible musl is, it's currently building:
-Wine
-Over 60% of pkgsrc
-SDL, Qt 4, Xfce and GIMP (with patches)
-FLTK and dillo (no/minimal patches)

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#54 Post by Ibidem »

musl 0.9.9 is out, with numerous bugfixes, and much-improved compatability.

Also, for reference--dnsmasq: ~180k static/stripped here.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#55 Post by goingnuts »

atm I have compiled the below packages static with success using musl 0.9.9
Attachments
snap0001.png
(39.37 KiB) Downloaded 474 times
Last edited by goingnuts on Tue 12 Mar 2013, 17:18, edited 7 times in total.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#56 Post by Ibidem »

goingnuts wrote:atm I have compiled the below packages with success using musl 0.9.9
e2fsprogs-1.40.2
elspci-1.0
fileutils-4.1
findutils-4.1.20
freetype-2.4.10
fuse-2.6.0
gdk-pixbuf-0.21.0
giflib-4.1.4
glib-1.2.10
gtk+-1.2.10
guess_fstype_withext4_test1
icewm-1.2.37
imlib-1.9.15
jpeg-6b
jwm-686
libpng-1.2.46
ntfs-3g-2009.3.8
tiff-3.7.0
tinyxlib-0.01
util-linux-2.13-pre7
zlib-1.2.5
Looks like a good start. FYI, though, the branch I pointed you at earlier in the other thread has some changes you may want for building tinyX. The main issue is getting vm86 integrated into the build system properly.
However, I can probably just use Technosaurus's approach and drop that dependency.

You may want to use libpng 1.2.50 for security reasons (there's a bad bug that's fixed in 1.2.49, and a trivial issue fixed in 1.2.50).

Busybox works, but don't enable regexes in busybox vi.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#57 Post by goingnuts »

I will update the list in my previous post as new things come up (if its ok for you...). I have worked further on tinyXlib, slowly working towards X11R-6.7.0 source files. I will upgrade to libpng 1.2.50 - thx.

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#58 Post by Ibidem »

goingnuts wrote:I will update the list in my previous post as new things come up (if its ok for you...). I have worked further on tinyXlib, slowly working towards X11R-6.7.0 source files. I will upgrade to libpng 1.2.50 - thx.
That's fine, nice to see progress.

Is this going to go in pupngo? It looks like it should be enough.

I'm contemplating mentioning puplets that use musl to some extent on the musl wiki's list of distros; currently, I think that means Fatdog64.

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#59 Post by goingnuts »

Ibidem wrote:Is this going to go in pupngo? It looks like it should be enough.
A musl-dog that would be :)

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#60 Post by goingnuts »

I am having problems getting util-linux to build (tried 2.13-pre7 & util-linux-2.22) both with their own problems. I have also tried to search for util-linux-musl-patches but not found something usable...Any hints?
I only need 4 of the aps from it (rev/mount/umount/losetup) but they are quite important as they go in initrd...

Post Reply