[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Jul 2012 20:57:39 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Hello
On Fri, Jul 06, 2012 at 04:14:17PM -0700, idunham@...abit.com wrote:
> >> 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.
Actually, generic vs gnu-linux locale crap is not the issue here. The
*ABI* support stuff in musl should make the gnu-linux code work on
musl if it was already compiled using glibc headers. It's the headers
that are incompatible with the gnu-linux os tree because we don't do
the ugly table-based stuff (which is much more bloated and probably
slower).
The issue that DOES matter with libstdc++ is name mangling. musl's
ABI-compat is limited to C. The type sizes and non-opaque type
representations match what's used on glibc/LSB, but the struct tags
and specific types for abstract opaque types like FILE and pthread_t
differ, meaning the name mangling will differ... Thus while you can in
theory use glibc-linked C++ programs with musl's LSB ABI support, you
can't mix-and-match glibc-linked C++ program/library code and
musl-linked C++ program/library code in a single program. The name
mangling will fail to match and the dynamic linker will fail to
resolve the C++ stuff.
Rich
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.
