Re: A running list of questions from "porting" Slackware to musl

[Isaac Dunham <ibid.ag@gmail.com>]

On Tue, Sep 30, 2014 at 06:13:37PM +0530, Weldon Goree 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.)
<snip> 
> 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.

You need a "libssp_nonshared.a" containing a function named
__stack_chk_fail_local, which need only call __stack_chk_fail.
No idea why, but this cannot be in a shared libary.

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

Alpine Linux, alpinelinux.org
> 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.

You're welcome.
> Any thoughts would be appreciated,
> Weldon

Hope this helps,
Isaac Dunham
> 
> [1] http://muslack.org