Missing symbols for supporting glibc-built libstdc++.so.6

Missing symbols for supporting glibc-built libstdc++.so.6

[Rich Felker]

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

Re: Missing symbols for supporting glibc-built libstdc++.so.6

[orc]

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?

Re: Missing symbols for supporting glibc-built libstdc++.so.6

[Rich Felker]

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

Re: Missing symbols for supporting glibc-built libstdc++.so.6

[orc]

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

Re: Missing symbols for supporting glibc-built libstdc++.so.6

[Rich Felker]

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