[csw-maintainers] How does libstdc++.so.6 find libgcc_s.so.1

[Maciej (Matchek) Blizinski]

While reworking library checking (again!) in checkpkg, I encountered
an interesting case: gcc.

I've examined libstdc++.so.6:

maciej at build8s [build8s]:~/src/opencsw/gar/v2 > /usr/ccs/bin/dump -Lv
/opt/csw/gcc4/lib/libstdc++.so.6.0.10 | ghead -n 11

/opt/csw/gcc4/lib/libstdc++.so.6.0.10:

  **** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag         Value
[1]     NEEDED          libm.so.1
[2]     NEEDED          libgcc_s.so.1
[3]     INIT            0x5c0f0
[4]     FINI            0x5c10c
[5]     SONAME          libstdc++.so.6
(...)

It needs libgcc_s.so.1 and has no RPATH section.  libgcc_s.so.1 is in
the same directory, but since $ORIGIN is not present in RPATH, the
library should not be found.  Running ldd:

maciej at build8s [build8s]:~/src/opencsw/gar/v2 > ldd
/opt/csw/gcc4/lib/libstdc++.so.6.0.10
        libm.so.1 =>     /usr/lib/libm.so.1
        libgcc_s.so.1 =>         (file not found)
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1

...it indeed is not found.  But we know from elsewhere that programs
linked against libstdc++.so.6 do work.  How?  All programs linking
against libstdc++.so.6 also happen to be linked against libgcc_s.so.1
so the problem never surfaces?  Is it a bug or a feature?