This is the mail archive of the
mailing list for the binutils project.
Re: mipsel-linux and --export-dynamic
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: Thomas Lopatic <thomas at lopatic dot de>
- Cc: binutils at sources dot redhat dot com
- Date: 04 Nov 2004 10:20:08 -0500
- Subject: Re: mipsel-linux and --export-dynamic
- References: <418A17A6.email@example.com>
Thomas Lopatic <firstname.lastname@example.org> writes:
> I've compiled binutils 2.15 on an Intel Linux platform with a target
> of mipsel-linux ("./configure --target=mipsel-linux"). I am using this
> build to link objects generated by a cross-plattform GCC. My problem
> is that all external symbols end up in the dynamic symbol table
> (verified with "objdump --dynamic-syms"), although I do not pass
> "--export-dynamic" to the linker.
Note that the MIPS compiler will pass --export-dynamic to the linker
if you use the -rdynamic option. Not that I have any reason to think
that you are using that. Are you sure that all external symbols get
exported? For example, the linker will normally export every called
function, which may indeed be most of the non-static functions.
> The problem with this is that I have an executable and shared objects
> loaded by this executable that have conflicting symbols, i.e. some
> symbols appear in the executable as well as in the shared objects. So,
> if an external variable "x" appears in the executable and in a shared
> object, both access the same memory location. I would, however, prefer
> everyone to have his own copy of "x". (Because otherwise the program
> crashes. :-D)
> Working around the problem by renaming the symbols in the shared
> objects or the executable to remove the overlaps or making the
> affected variables static would be possible in my case. However, I'd
> prefer the linker to behave as expected. Or is there something that I
> am missing?
Using the same symbol name in multiple objects in a link, and relying
on the linker to not export the symbol name by default, is very
fragile. You should instead use version scripts when you create the
shared library to make only the desired symbols publically visible.
Or you should use the compiler "visibility" attribute. See the