[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 16:07:40 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Hello
On Fri, 6 Jul 2012 16:14:17 -0700 (PDT)
idunham@...abit.com wrote:
> >> > 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.
Bootstrapping libstdc++ I think even more nightmarish than dealing with
pkg-config or autohell, since this library is part of gcc. So I went in
another way: I've taken my package cache and relinked gtk2 and pango,
now they do not depend on libstdc++ (since they do not import things
from that library. Why they were linked to it - is another open
question.)
After some dancing around undefined symbols I've got not-so-big list:
__res_init(), __res_iclose(), inet_nsap_ntoa(), __res_maybe_init(),
initstate_r(), random_r() and stuff related to pthread scheduling:
pthread_setschedparam(), pthread_getschedparam().
Since that gtk2 and it's stuff do not require libstdc++ to work I'll
try to build them against musl.
> > 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.
Did know about PKG_CONFIG_PATH, so looks like replacing default
directory will solve that problems when looked into, not found stuff
and tried to link with host libs.
> 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.
Converting existing system maybe possible, but I will prefer to rebuild
all the stuff from scratch with musl and (possibly in future) with
different compiler(s) (I really tired from gcc/binutils, but there
seems no any alternatives written in C and able to build major
software like gtk2 and Linux kernel). Converting will be possible when
musl will be binary compatible with glibc, but this is not primary
goal. As a bonus, maybe. One issue here was that binary nvidia blob
that can be needed even after rebuild on desktop, so missing interfaces
were not big deal with it. Other things can be patched/recompiled.
>
>
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.
