Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sat 25 Oct 2014, 10:59
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Compiling with musl (an alternate libc)
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 3 of 5 Posts_count   Goto page: Previous 1, 2, 3, 4, 5 Next
Author Message
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Mon 02 Jul 2012, 21:08    Post_subject:  

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?
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Fri 06 Jul 2012, 22:15    Post_subject:  

Ibidem wrote:
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
Back to top
View user's profile Send_private_message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Sat 07 Jul 2012, 02:50    Post_subject:  

Aboriginal: you'd have to hijack the toolchain. Possible, though difficult.

I wouldn't bother cross-compiling sabotage, I think. bootstrap-linux would be better for that.
More-or-less build chain I'd try (as make takes it):

Code:
step1: cross-binutils cross-gcc

#If you don't have perl, apply a couple patches so linux builds with  BB sed, dc.
linux-headers: step1

linux: step1

musl: step1

make: musl

busybox: musl linux-headers

native-binutils: musl linux-headers #not sure about the latter

native-gcc: native-binutils

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.
Back to top
View user's profile Send_private_message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Sat 07 Jul 2012, 22:54    Post_subject:  

jamesbond wrote:
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).
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Sun 08 Jul 2012, 09:49    Post_subject:  

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 Smile 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 Very Happy

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 Confused
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
Back to top
View user's profile Send_private_message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Thu 12 Jul 2012, 02:23    Post_subject:  

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.

It probably wouldn't interest you just yet, but there's also mips support in git (static linking only for now).
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Thu 12 Jul 2012, 08:24    Post_subject:  

Ibidem wrote:
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. Shocked 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 Confused (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).
Smile 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 Smile
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Sun 15 Jul 2012, 20:50    Post_subject:  

jamesbond wrote:
Ibidem wrote:
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. Shocked 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 Confused (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)?

Details that may help:
binutils version
gcc version
config.mak contents
processor you're using/qemu version & emulated processor

Also, have you booted a non-musl rootfs on the same hardware/qemu machine?
Back to top
View user's profile Send_private_message 
rofl0r

Joined: 16 Jul 2012
Posts: 2

PostPosted: Mon 16 Jul 2012, 06:28    Post_subject:  

busybox segfaults ? known.
rofl0r says, look at sabotage.

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

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

want an existing sabotage ARMV7l rootfs ? look at
https://github.com/rofl0r/sabotage/wiki/efika_mx
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Mon 16 Jul 2012, 07:42    Post_subject:  

Ibidem wrote:
That's not something I've heard of...

What ARM variant are you using?
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 Smile

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)?
Will do that, probably with the mailing list.

Details that may help:
binutils version - 2.22
gcc version - 4.6.3
config.mak contents - none, it's configured as by bootstrap
processor you're using/qemu version & emulated processor - qemu 1.1.0, emulating arm926

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

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

rofl0r wrote:
busybox segfaults ? known.
rofl0r says, look at sabotage.

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


Wow, rofl0r is here Very Happy Very Happy 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

Thanks, I will give it a try.

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

Thanks guys, cheers!

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
rofl0r

Joined: 16 Jul 2012
Posts: 2

PostPosted: Mon 16 Jul 2012, 15:36    Post_subject:  

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:
Quote:
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.
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Sun 22 Jul 2012, 05:53    Post_subject:  

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) Very Happy

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 Confused 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
Back to top
View user's profile Send_private_message 
technosaurus


Joined: 18 May 2008
Posts: 4353

PostPosted: Mon 23 Jul 2012, 12:43    Post_subject:  

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
Back to top
View user's profile Send_private_message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Mon 23 Jul 2012, 20:21    Post_subject:  

@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" Wink
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.
Back to top
View user's profile Send_private_message 
jamesbond

Joined: 26 Feb 2007
Posts: 2230
Location: The Blue Marble

PostPosted: Fri 27 Jul 2012, 10:55    Post_subject:  

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:
#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? Confused
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.

cheers!

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 3 of 5 Posts_count   Goto page: Previous 1, 2, 3, 4, 5 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Off-Topic Area » Programming
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1338s ][ Queries: 13 (0.0053s) ][ GZIP on ]