Re: Hello

[idunham@lavabit.com]

>> > gtk2 will not work that way, I checked. One library in chain
>> > requires libstdc++, libstdc++ defines 'unique' symbols (see manual
>> > page of binutils nm) which musl linker cannot handle. Additionally,
>> > there is much more missing symbols including missing functions. But
>> > plain X11 apps worked (I checked xfontsel and xlogo).
>>
>> Have you looked into building the apps/libs natively against musl
>> except for the nvidia binary blob, to see if the blob works under that
>> usage? I think that's a usage case that's a lot more applicable to
>> real-world usage of musl, and in fact it's probably the first real
>> reason anybody would be interested in having musl work with code that
>> was built against glibc...
The first step would probably be dropping a musl-compatible (generic, not
gnu-linux) libstdc++ into the test environment.
> I mostly do building in KVM now to test how applications are portable
> and collect the patches that will be needed when transiting to
> musl-enabled system. I was busy with patching old gcc and binutils these
> days, since I found that musl systems by default are built with
> executable stack (GNU_STACK thing) enabled (binutils issue). I will try
> that on host of course, but I generally dislike cross-compiling even to
> same arch because of autotools and pkg-config (will be required by
> gtk2 stuff
I presume you know to use PKG_CONFIG_LIBDIR ? With that set,
cross-compiling seemed fairly easy to me.
Also, I often set up a chroot with musl and build under that.  If you'd
rather not build the whole chroot yourself, you can prepare a chroot and
follow the installation notes for converting a glibc-based system, using
the chroot environment instead of a full install (this works well with
Debian).
If you do this, make sure not to do a plain cp of the system libraries;
this would mess up the sonames, since lib*.so must be symlinks to
lib*.so.<version>.  It also really messes with ldconfig.