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
Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#31 Post by Ibidem »

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?

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

#32 Post by jamesbond »

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

#33 Post by Ibidem »

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: Select all

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.

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

#34 Post by Ibidem »

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

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

#35 Post by jamesbond »

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 :D

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

#36 Post by Ibidem »

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

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

#37 Post by jamesbond »

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

#38 Post by Ibidem »

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...
EDIT: I've narrowed down the segfaults to printf. :shock: 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)?

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?

rofl0r
Posts: 2
Joined: Mon 16 Jul 2012, 10:22

#39 Post by rofl0r »

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

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

#40 Post by jamesbond »

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 :)
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
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 :D :D 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.
want to bootstrap musl on arm?
use aboriginal linux and musl-gcc as described in https://github.com/rofl0r/sabotage/wiki ... inal-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.
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 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]

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

Post Reply