[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130724075533.GA14709@brightrain.aerifal.cx>
Date: Wed, 24 Jul 2013 03:55:34 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Missing symbols for supporting glibc-built libstdc++.so.6
As of now, C++ programs/libraries linked against glibc should work
with musl as long as a musl-built version of libstdc++.so is available
in place of the glibc-built one. The only remaining type that does not
match glibc, in the full C++ name-mangling sense of matching, is
fd_mask. (This type is not really intended to be public, and glibc
will probably change it to match musl's definition after 2.18 is
released.)
However, the glibc-built libstdc++.so.6 still has a few unsatisfied
symbol references:
* __-prefixed versions of the *_l locale functions.
* Some nonstandard *_l locale functions.
* All the "xstat" functions (glibc's pre-symbol-versioning hack for
ABI stability of stat()).
* The gettext interfaces.
Of these, all but gettext are fairly trivial to add. I'm still
undecided on whether libc should have an implementation of gettext,
but I am confident the size could be made trivial.
The advantage of getting the glibc-built libstdc++ working with musl
is that the musl-gcc wrapper could be used to build C++ programs too,
not just C. This is particularly important now that new GCC versions
are using C++ code; without the ability to use the existing libstdc++,
an earlier GCC version must first be built to bootstrap a musl-based
compiler.
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.
