MIPS32 Dynamic Linker Characteristics ...no

[Mr. Miyagi]

I can't get dynamic shared object loading for C++ sources. Apparently, the 
linker is not even capable of creating shared libraries for C++ while it's 
reported being capable of producing shared libraries for C.

I'm using uclibc-0.9.28.2 through OpenWRT's toolchain. I compile the 
toolchain myself and use the resulting SDK to compile my own sources for the 
intended MIPS32 architecture. The toolchain is running on x86 architecture 
and cross compiles to MIPS32.

The build of the toolchain produced libstdc++ (6.0.3) which is reported to 
be an ELF 32bit LSB shared object, MIPS, version 1 (SYSV).

'configure' (on my own sources) reports (below) shared libraries are 
possible when using ...gcc as the linker, but not when using ...g++ as the 
linker, although the same linker is apparently used in both instances.

I don't know what's preventing the use of shared libraries for C++. I 
checked the uClibc sources involved in building the toolchain. One of the 
possible (far-fetched?) causes is that the tree of ldso includes mips but 
not mipsel causing some kind of problems as the toolchain is little endian, 
although I'd expect 'mips' to be followed in this case? And this can't be 
right as this would hinder C shared libraries as well. I'm also wondering to 
what extent the kernel (linux 2.4.34) options are related to this. The 
kernel build uses the following (possibly related) options:

CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_ELF_AOUT is not set
# CONFIG_MIPS32_COMPAT is not set
# CONFIG_MIPS32_O32 is not set
# CONFIG_MIPS32_N32 is not set
# CONFIG_BINFMT_ELF32 is not set
# CONFIG_BINFMT_MISC is not set

I don't immediately know if the lack of MIPS32 options is causing this 
problem. But the CONFIG_BINFMT_ELF_AOUT annotation states that:

'The kernel may support ELF executables which use an a.out format 
interpreter (dynamic linker) and/or a.out shared libraries, in addition to 
the usual ELF-ELF setups. You shouldn't need this.'.

I'm wondering if I do need this, i.e. is there an a.out format interpreter 
involved with uclibc's dynamic linker? But if this is the cause, I'd expect 
the C shared libraries to be hindered in this way as well.

So (from configure output below) I (we) can produce position independant 
code, shared libraries for C, but not shared libraries for C++ code although 
the toolchain produces libstdc++ as a shared library (inferring in this case 
that libstdc++ is written in C?).

A pointer (shove) in the right direction is most appreciated.

Thanks,

Miyagi