public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Thomas Lopatic <thomas@lopatic.de>
To: binutils@sources.redhat.com
Subject: mipsel-linux and --export-dynamic
Date: Thu, 04 Nov 2004 11:51:00 -0000	[thread overview]
Message-ID: <418A17A6.9090803@lopatic.de> (raw)

Hi there,

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.

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?

If this is not a known issue, I'll be happy to try to reproduce this 
with the latest binutils CVS version.

Would it also make sense to try to reproduce this with the latest CVS 
version of GCC? I don't know much about ELF, but a symbol is a symbol is 
a symbol, isn't it? So the GCC version shouldn't have any impact on this 
problem, should it?

Thanks for your time
-Thomas


             reply	other threads:[~2004-11-04 11:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-04 11:51 Thomas Lopatic [this message]
2004-11-04 15:11 ` Daniel Jacobowitz
2004-11-04 15:20 ` Ian Lance Taylor
2004-11-04 16:00   ` Thomas Lopatic
2004-11-04 16:04     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=418A17A6.9090803@lopatic.de \
    --to=thomas@lopatic.de \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).