* Missing symbols for supporting glibc-built libstdc++.so.6
@ 2013-07-24 7:55 Rich Felker
2013-07-24 14:20 ` orc
0 siblings, 1 reply; 5+ messages in thread
From: Rich Felker @ 2013-07-24 7:55 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Missing symbols for supporting glibc-built libstdc++.so.6
2013-07-24 7:55 Missing symbols for supporting glibc-built libstdc++.so.6 Rich Felker
@ 2013-07-24 14:20 ` orc
2013-07-24 14:47 ` Rich Felker
0 siblings, 1 reply; 5+ messages in thread
From: orc @ 2013-07-24 14:20 UTC (permalink / raw)
To: musl
On Wed, 24 Jul 2013 03:55:34 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> 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
About a year ago while experimenting with musl desktop, various
binary blobs I unfortunately tied to (you should remember
short discuss about nvidia blob compatibility) I tried to use my host
libstdc++.so with musl linker and that failed because of gnu "unique
symbol" extension. Did you encountered same problem here? If so, is
it solved now?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Missing symbols for supporting glibc-built libstdc++.so.6
2013-07-24 14:20 ` orc
@ 2013-07-24 14:47 ` Rich Felker
2013-07-24 15:36 ` orc
0 siblings, 1 reply; 5+ messages in thread
From: Rich Felker @ 2013-07-24 14:47 UTC (permalink / raw)
To: musl
On Wed, Jul 24, 2013 at 10:20:03PM +0800, orc wrote:
> About a year ago while experimenting with musl desktop, various
> binary blobs I unfortunately tied to (you should remember
> short discuss about nvidia blob compatibility) I tried to use my host
> libstdc++.so with musl linker and that failed because of gnu "unique
> symbol" extension. Did you encountered same problem here? If so, is
> it solved now?
I have only tested with simple C++ .so files using the musl-built
libstdc++.so, and so far, they've worked fine. These tests are by no
means extensive, just "hello world". I have not tried using the
glibc-built libstdc++.so.6 again; the "missing symbols" check was
based purely on the output of:
nm -u -D libstdc++.so.6 | grep -v -e _[UJ] -e ' w '
Do you know the subject line of the thread where your issue was
discussed before? I'd be happy to go look and see if I think the issue
is fixed now.
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Missing symbols for supporting glibc-built libstdc++.so.6
2013-07-24 14:47 ` Rich Felker
@ 2013-07-24 15:36 ` orc
2013-07-24 16:01 ` Rich Felker
0 siblings, 1 reply; 5+ messages in thread
From: orc @ 2013-07-24 15:36 UTC (permalink / raw)
To: musl
On Wed, 24 Jul 2013 10:47:27 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> On Wed, Jul 24, 2013 at 10:20:03PM +0800, orc wrote:
> > About a year ago while experimenting with musl desktop, various
> > binary blobs I unfortunately tied to (you should remember
> > short discuss about nvidia blob compatibility) I tried to use my
> > host libstdc++.so with musl linker and that failed because of gnu
> > "unique symbol" extension. Did you encountered same problem here?
> > If so, is it solved now?
>
> I have only tested with simple C++ .so files using the musl-built
> libstdc++.so, and so far, they've worked fine. These tests are by no
> means extensive, just "hello world". I have not tried using the
> glibc-built libstdc++.so.6 again; the "missing symbols" check was
> based purely on the output of:
>
> nm -u -D libstdc++.so.6 | grep -v -e _[UJ] -e ' w '
>
> Do you know the subject line of the thread where your issue was
> discussed before? I'd be happy to go look and see if I think the issue
> is fixed now.
I did not send a report about this especially, just my experiments
showed that. Just because nvidia blob did not require libstdc++.so at
all. But others did.
You can start reading somewhere in long 'Hello' thread about 6 Jul 2012.
Tested now:
- Hello world prog:
#include <iostream>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
% g++ test.cc -o test-cpp
% musl-out/lib/libc.so ./test-cpp
[lots of "Error relocating..." errors]
% musl-out/lib/libc.so ./test-cpp 2>&1 | fgrep _ZGVNSt7collateIwE2idE #
picking one
% nm /usr/lib/libstdc++.so.6 | fgrep _ZGVNSt7collateIwE2idE
00000000002e40d8 u _ZGVNSt7collateIwE2idE
(man nm says that 'u' is "unique global" and gnu extension)
On musl system there is 'V' instead of 'u'.
Is my example falls under "glibc-built libstdc++.so.6"?
>
> Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Missing symbols for supporting glibc-built libstdc++.so.6
2013-07-24 15:36 ` orc
@ 2013-07-24 16:01 ` Rich Felker
0 siblings, 0 replies; 5+ messages in thread
From: Rich Felker @ 2013-07-24 16:01 UTC (permalink / raw)
To: musl
On Wed, Jul 24, 2013 at 11:36:11PM +0800, orc wrote:
> I did not send a report about this especially, just my experiments
> showed that. Just because nvidia blob did not require libstdc++.so at
> all. But others did.
> You can start reading somewhere in long 'Hello' thread about 6 Jul 2012.
>
> Tested now:
> - Hello world prog:
> #include <iostream>
>
> int main()
> {
> std::cout << "Hello, world!" << std::endl;
> return 0;
> }
>
> % g++ test.cc -o test-cpp
> % musl-out/lib/libc.so ./test-cpp
> [lots of "Error relocating..." errors]
> % musl-out/lib/libc.so ./test-cpp 2>&1 | fgrep _ZGVNSt7collateIwE2idE #
> picking one
> % nm /usr/lib/libstdc++.so.6 | fgrep _ZGVNSt7collateIwE2idE
> 00000000002e40d8 u _ZGVNSt7collateIwE2idE
> (man nm says that 'u' is "unique global" and gnu extension)
>
> On musl system there is 'V' instead of 'u'.
> Is my example falls under "glibc-built libstdc++.so.6"?
Yes. Thanks for the report. It's fixed in git. Here is the original
thread on "unique global" support in binutils:
http://www.sourceware.org/ml/binutils/2009-06/msg00016.html
With the latest git, the only symbol errors in glibc-built libstdc++
are the ones I described at the beginning of this thread:
Error relocating .../libstdc++.so.6: __towlower_l: symbol not found
Error relocating .../libstdc++.so.6: __nl_langinfo_l: symbol not found
Error relocating .../libstdc++.so.6: __strxfrm_l: symbol not found
Error relocating .../libstdc++.so.6: __towupper_l: symbol not found
Error relocating .../libstdc++.so.6: __uselocale: symbol not found
Error relocating .../libstdc++.so.6: __wcsxfrm_l: symbol not found
Error relocating .../libstdc++.so.6: __strcoll_l: symbol not found
Error relocating .../libstdc++.so.6: __wcscoll_l: symbol not found
Error relocating .../libstdc++.so.6: __duplocale: symbol not found
Error relocating .../libstdc++.so.6: __wcsftime_l: symbol not found
Error relocating .../libstdc++.so.6: __newlocale: symbol not found
Error relocating .../libstdc++.so.6: __strftime_l: symbol not found
Error relocating .../libstdc++.so.6: __freelocale: symbol not found
Error relocating .../libstdc++.so.6: __strtod_l: symbol not found
Error relocating .../libstdc++.so.6: __strtof_l: symbol not found
Error relocating .../libstdc++.so.6: __iswctype_l: symbol not found
Error relocating .../libstdc++.so.6: strtold_l: symbol not found
Error relocating .../libstdc++.so.6: __wctype_l: symbol not found
(Pathnames elided to make this legible in email.)
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-07-24 16:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-24 7:55 Missing symbols for supporting glibc-built libstdc++.so.6 Rich Felker
2013-07-24 14:20 ` orc
2013-07-24 14:47 ` Rich Felker
2013-07-24 15:36 ` orc
2013-07-24 16:01 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).