![]() |
|
Message-ID: <20120707005739.GT544@brightrain.aerifal.cx> 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.