[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA7aPHheOUZ=pnHMhd2tqznWaYGLFKyHfUZ_40YAoMxPA647Tw@mail.gmail.com>
Date: Tue, 30 Sep 2014 10:59:19 -0400
From: stephen Turner <stephen.n.turner@...il.com>
To: musl@...ts.openwall.com
Subject: Re: A running list of questions from "porting" Slackware to musl
Weldon, i actually started building my own lfs with musl and i am currently
contemplating my own distribution centered around my experiences in the IT
field. Do you have a good source for building out a complete system capable
of compiling? Im currently working on a minimal build environment using
Busybox, Bash, Linux-Headers, Musl, Make, Binutils, Glibc (with dependent
math libs) And i am capable of building a working system however when you
test it the compiled files (a.out) are not working even after verifying
they are executable (chmod +x)
any thoughts?
On Tue, Sep 30, 2014 at 8:43 AM, Weldon Goree <weldon@...gurwallah.org>
wrote:
> Hi all,
>
> I added the quotation marks of shame because it's not a "port" in a real
> sense. But still: I've had this side project[1] for a while of porting
> Slackware to use Musl and it's Nearly There (tm), but I was hoping for some
> advice on some persistent irritations I have. (Sorry for the length.)
>
> 1. error.h. I've worked around most uses of this (where I didn't decide to
> simply delete the "else" branch) with a stub liberror (another list user
> suggested an actually functional musl-friendly liberror which I should
> probably integrate at some point). Still, I'd always like to hear other
> ideas. Kbd in particular remains problematic, though it at least compiles
> (which means it ships!).
>
> 2. NLS. Yeah, NLS. I realize this is still currently a moving target (and
> a very impressive one so far) on musl, so I've been adding --disable-nls or
> --with-gettext=no or whatever to the build scripts as a matter of course,
> but I'd like to hear what progress other musl users have made on this
> front. Can someone who "gets" this explain to a simpleton why gettext
> linked against musl doesn't present a libintl.so that behaves like client
> applications expect? (In particular the symbol 'libintl_gettext' seems to
> not exist. Bonus points: why does libintl.h belong to the C library rather
> than gettext?)
>
> 2a. ${LIBDIR}/charset.alias. GNU software seems to love to make this file,
> and it only seems to be made when gettext is unhappy (though gettext devs
> seem to blame this on iconv, which I don't even use). It's similar to
> /usr/share/info/dir, in that subsequent packages are supposed to append to
> it, but appending is the bane of package management. I've altered my
> makepkg script to just delete it when it's found, but I'm curious if
> anybody knows a way to tell GNU tools they really don't have to make it.
> (This isn't really about musl, but other musl users have probably run into
> this.)
>
> 3. Is there a set of configure options for musl that would let me have
> libc.so in libdir, ld-musl-${ARCH}.so.1 in syslibdir, and *crt* in
> $(something else)? I would ideally like libc.so in /lib, the loader in
> /lib, and the crt files in /usr/lib, but a general solution would be
> appreciated. (Particularly one that "talks to" musl-gcc.specs, though I
> don't use that for this project). (This is literally just about my laziness
> in packaging gcc, so I won't be hurt if nobody suggests anything...)
>
> 4. Is Pth a lost cause?
>
> 5. Not meaning to start another round of spam against the gnulib team: I
> seem to have had good luck with findutils by simply ripping out their
> gnulib dir and updating it from the beta find. Does anybody have any
> caveats from having done this? (Bonus points: what in particular about
> fseeko makes it so difficult?) The only other option seems to be sabotage's
> "we will shoot gnulib files in the face" method, which I admit is
> emotionally satisfying. (../../../gnulibfix lib/ > cflags FTW)
>
> 6. Stack protection. This one really puzzles me. Stack protection is as
> alien to glibc as it is to musl, but I keep running into this. 90% of the
> problems can be avoided with adding -fno-stack-protector appropriately, but
> libtool is very "helpful" on matters like this and seems to find a way to
> put it back. I've actually not found an unworkable problem yet (though
> several very annoying ones); I guess I'm just curious what the real state
> of ssp on musl is (I'm not a fan of the concept, personally, but I know a
> lot of people are), and whether there's a general solution to just telling
> software to trust the ****ing stack.
>
> 7. Dynamic linking. In assembling muslack I've been leaning a lot on the
> shoulders of the giants who came before me. But in all that I keep running
> into static linking. Snowflake does some dynamic linking, and Sabotage
> submits to it when necessary (perl, etc.) but I don't know of a musl-based
> distro that dynamically links like "normal" people do. Does anybody know of
> one I can shamelessly steal from?
>
> 8. Finally: thanks to everybody on this project and on this list; I've
> really enjoyed the year since I read about musl on a random reddit comment.
>
> Any thoughts would be appreciated,
> Weldon
>
> [1] http://muslack.org
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
