1-Apparently cross-compiling is not supported--rofl0r says he doesn't want to support it, it's practically impossible/full of pitfalls, and "if you want to cross-compile, use Aboriginal".
2-A lot of the time, #musl on freenode is the quickest way to get ahold of someone who's using sabotage. You might also try the sabotage mailinglist.
3-Tried doing it in an x86 chroot with setarch to fake i386?

1-Apparently cross-compiling is not supported--rofl0r says he doesn't want to support it, it's practically impossible/full of pitfalls, and "if you want to cross-compile, use Aboriginal".

But Aboriginal doesn't support creating apps using musl as libc - or does it? Agreed, it is tough if you're doing from scratch. I persisted for a while - trying to build gcc 3.4.6 cross compiler (that was used in stage0 sabotage before rofl0r upgraded it to gcc4 a while back). Got there, sort of - made a cross-gcc that produces 32-bit assembly by default (I have forgotten that this is all that gcc outputs - an assembly language file). Because I haven't made cross-binutils yet, I coaxed my existing 64-bit binutils to work with that (--32 and -m elf-i386) and link with 32-bit musl. It works.

EDIT: I shouldn't have wasted my time, this and this build musl cross-compiler and the scripts are simple enough to understand.

Quote:

2-A lot of the time, #musl on freenode is the quickest way to get ahold of someone who's using sabotage. You might also try the sabotage mailinglist.

Thank you, yes I should do that.

Quote:

3-Tried doing it in an x86 chroot with setarch to fake i386?

No, not even aware that "setarch" command exists, I should read more about it. Anyway I don't have any 32-bit development libraries (but could be installed I suppose). This won't work for Intel --> ARM cross, though.

Sorry this is becoming out of topic, we should be discussing musl instead of cross-compiling here. Just tell me so if you don't wish me to continue here._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

This should give you what you need by way of binaries; I don't know about a cross-built bootable rootfs...

Talking about cross-compiling is fine, as far as I'm concerned...as long as it isn't totally irrelevant, like uclibc-, glibc-, or diet- specific issues.

@lmemsm:
There are plenty of (in)compatability issues, but they seem to be disappearing fairly fast. Someone just managed to patch musl to the point where they had glxgears running on the proprietary nvidia driver.
Generally,
-try no CFLAGS (ANSI)
-try -D_XOPEN_SOURCE (POSIX/ UNIX2008)
-try -D_BSD_SOURCE (BSD-like API)
The "big hammer" is -D_GNU_SOURCE.

SDL can be built, from what I saw of the sabotage package list.
FLTK hasn't been tried _yet_, AFAICT. It theoretically should work, if C++ has been enabled and the X libs built (all possible, I just got to the point where I could build openmotif).

What sort of packages would you want? I can think of a couple spreadsheets, a wordprocessor or two, half a dozen web browsers (dillo, w3m, retawq, lynx, links, elinks...), a framebuffer image viewer (also supports PS/PDF), and some other things besides.

I persisted for a while - trying to build gcc 3.4.6 cross compiler (that was used in stage0 sabotage before rofl0r upgraded it to gcc4 a while back). Got there, sort of - made a cross-gcc that produces 32-bit assembly by default (I have forgotten that this is all that gcc outputs - an assembly language file). Because I haven't made cross-binutils yet, I coaxed my existing 64-bit binutils to work with that (--32 and -m elf-i386) and link with 32-bit musl. It works.

EDIT: I shouldn't have wasted my time...this build musl cross-compiler and the scripts are simple enough to understand.

That's a git mirror of http://bitbucket.org/GregorR/musl-cross; just today, Gregor added cross-compiler downloads for armeb, arm(el), x86-64 (amd64), and i686 (this toolchain may or may not work with i486).

Thanks. Didn't know the main repository is in bitbucket.org. The one in github seems to more than a day late.

I've got i386 (actually its i686) rootfs up and running using bootstrap. Thank you for the recipe, bootstrap seems to follow that closely. Seems that making gcc4 cross-compile is a lot less hassle than gcc3 (though you need to have mpfr, gmp, mpc available ...) - but may be it's just me I'll try to coax bootstrap to build arm rootfs too - looks like that all I need to do is change the --target to the appropriate ones; but we'll see how it goes

EDIT: Got arm rootfs to boot, using bootstrap linux. I used bootstrap from git (the same as the one I used for i686 cross above).
A few notes:
- (bootstrap) not enough just to specify the arch as "arm", I need to sed "linux-musl" to "linux-musleabi" (the provided patch for gcc is only for arm-eabi).
- (bootstrap) Linux kernel build didn't work, I need to use my own Kconfig instead of the generic linux.config provided. I'm using versatile emulation.
- (musl) musl 0.9.2 doesn't work (busybox segfaults), I need to get from latest git.

bootstrap linux rootfs consist of these:
- busybox (seems to work)
- make (seems to work)
- native binutils - still segfaults
- native gcc - many still segfaults.
In the i686 version all the above works flawlessly
Since everything is statically compiled, I would say the failure happens during during musl cross compilation for the cross compiler._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Question: what version of musl does it have?
If it's 0.9.2 or another tarball version, you may want to grab the latest: there are a few fixes for arm in git.

Bootstrap was set to build 0.9.0 but I modified so that it uses 0.9.2 (which it did), and failed (busybox segfaults). I modified it again to get the package from the latest git at that time - which was commit bd1cf09c375e56c7fba6b7a1036b33b9591b5dba (support -mfpmath=387) (== easy, just put the tarball in the src folder and name it musl-0.9.2) . With this busybox works but binutils/gcc fails (make seems to work, though). I'd like to dig further but I will admit that my experience in debugging cross-arch cross-compiled applications is very limited. I could probably scatter a few "printf" statements but in a program the size of gcc this is not going to cut it.

I haven't tried again from the latest git but it seems that all the latest commits are MIPS related. I'm curious though, am I the only one encountering this issue? The mailing list seems quiet ...

EDIT: I tried from the musl latest git again today, no improvement yet.

EDIT: I've narrowed down the segfaults to printf. If printf is called with any parameter (anything - ints, strings, whatever), it segfaults. I tested by putting printf("hello") as the first line of main() in strings.c (binutils) - works, but if I put printf("hello %d",1) then it segfaulted.

The funny thing is, if I create hello-world.c with nothing but just printf in it, it works. I'm suspicious that the binutils/gcc replaces this (and probably others too) function with its own broken versions.

EDIT: I tried to to do remote-gdb to qemu but it doesn't work, I probably need to build cross-gdb first.

EDIT: I disassembled the executables and compare which "printf" function actually got called by my hello-world.c and strings.c. They are identical (and looks like direct translation of musl's printf.c).

Quote:

It probably wouldn't interest you just yet, but there's also mips support in git (static linking only for now).

Well so far the interesting chips are all ARM - BeagleBone is ARM, A10 is ARM, ODROID-X is ARM, even OLPC X0-1.75 is ARM, so I'll skip the mips part for now. Thank you for letting me know though _________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Question: what version of musl does it have?
If it's 0.9.2 or another tarball version, you may want to grab the latest: there are a few fixes for arm in git.

Bootstrap was set to build 0.9.0 but I modified so that it uses 0.9.2 (which it did), and failed (busybox segfaults). I modified it again to get the package from the latest git at that time - which was commit bd1cf09c375e56c7fba6b7a1036b33b9591b5dba (support -mfpmath=387) (== easy, just put the tarball in the src folder and name it musl-0.9.2) . With this busybox works but binutils/gcc fails (make seems to work, though). I'd like to dig further but I will admit that my experience in debugging cross-arch cross-compiled applications is very limited. I could probably scatter a few "printf" statements but in a program the size of gcc this is not going to cut it.

I haven't tried again from the latest git but it seems that all the latest commits are MIPS related. I'm curious though, am I the only one encountering this issue? The mailing list seems quiet ...

AFAICT, yes...

Quote:

EDIT: I've narrowed down the segfaults to printf. If printf is called with any parameter (anything - ints, strings, whatever), it segfaults. I tested by putting printf("hello") as the first line of main() in strings.c (binutils) - works, but if I put printf("hello %d",1) then it segfaulted.

The funny thing is, if I create hello-world.c with nothing but just printf in it, it works. I'm suspicious that the binutils/gcc replaces this (and probably others too) function with its own broken versions.

EDIT: I tried to to do remote-gdb to qemu but it doesn't work, I probably need to build cross-gdb first.

EDIT: I disassembled the executables and compare which "printf" function actually got called by my hello-world.c and strings.c. They are identical (and looks like direct translation of musl's printf.c).

That's not something I've heard of...

What ARM variant are you using?

Would you mind sending details to the musl mailing list (see http://openwall.com/lists/, under "Openwall-hosted community mailing lists"), or perhaps asking about it at #musl on freenode (given the issue, I'd expect the former to be more useful)?

I'm using qemu, with versatile-pb emulation. I'm thinking to get an ARM board to play with, but taking baby steps - qemu first

Quote:

Would you mind sending details to the musl mailing list (see http://openwall.com/lists/, under "Openwall-hosted community mailing lists"), or perhaps asking about it at #musl on freenode (given the issue, I'd expect the former to be more useful)?

Also, have you booted a non-musl rootfs on the same hardware/qemu machine?

Yes, buildroot's rootfs boots fine, and the native gcc also works fine (it has other problems but that's another story). Bootstrap-built rootfs also boots fine after using the latest git from last Thursday, just that native binutils and native gcc crashed as above.

musl segfaults ?
rofl0r says, use musl-git (or the patches sabotage applies on top of musl-0.9.2)

Wow, rofl0r is here 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.
Anyway, the latest musl git seems to have incorporated most of your patches and busybox already cross-built with bootstrap's minor patches so that's not problem anymore.

Quote:

want to bootstrap musl on arm?
use aboriginal linux and musl-gcc as described in https://github.com/rofl0r/sabotage/wiki/bootstrapping-from-aboriginal-linux
or ... any working glibc ARM distribution that has a working compiler, binutils 2.22 (earlier binutils misalign code, http://sourceware.org/bugzilla/show_bug.cgi?id=12931 ) and simply build sabotage as on any other platform

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.

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

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)

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, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

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)_________________Web Programming - Pet Packaging 100 & 101

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

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:

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

using

Code:

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:

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!

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

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum