public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Philip Blundell <philb@gnu.org>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Mark Mitchell <mark@codesourcery.com>,
	binutils@sources.redhat.com, gcc@gcc.gnu.org
Subject: Re: Wrong dynamic-linker used on Solaris 7/x86
Date: Sun, 20 May 2001 11:10:00 -0000	[thread overview]
Message-ID: <E151Xeo-0007oa-00@kings-cross.london.uk.eu.org> (raw)
In-Reply-To: <ory9rrykkx.fsf@guarana.lsd.ic.unicamp.br>

>Dunno.  I had thought at first of creating a new BFD vector, such as
>elf32-i386-sol2.c, but now I realize this wouldn't necessary, as long
>as there is some way to tell, in elf_i386_size_dynamic_sections(),
>whether ELFOSABI_SOLARIS is set somewhere, assuming this would be the
>way to detect we're linking for Solaris.  If that's the case, where
>would this `somewhere' be?

I have a feeling that you will find that ELFOSABI_SOLARIS isn't actually used,
and Solaris just declares itself as "System V" (ie ELFOSABI_NONE).  If it were, 
I guess elf_elfheader(output_bfd)->e_ident would be the place to go looking for 
it.

You might do better to create a new linker emulation, have it override the 
contents of the .interp section, and make that the default for Solaris.  That 
way the hackery is localised inside ld, rather than involving BFD itself.

(Personally I don't think I'd bother: there are several other targets where GNU 
ld will get the interpreter location wrong if it's left to its own devices, 
and GCC has to include an appropriate -dynamic-linker option in the specs 
file.)

p.


  parent reply	other threads:[~2001-05-20 11:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-20  7:44 Alexandre Oliva
2001-05-20  8:14 ` Philip Blundell
2001-05-20  8:32   ` Alexandre Oliva
2001-05-20  8:41     ` Philip Blundell
2001-05-20  9:06       ` Alexandre Oliva
2001-05-20 10:25   ` Mark Mitchell
2001-05-20 10:52     ` Alexandre Oliva
2001-05-20 10:57       ` Mark Mitchell
2001-05-20 11:03         ` Alexandre Oliva
2001-05-20 11:08           ` Mark Mitchell
2001-05-20 11:28             ` Alexandre Oliva
2001-05-20 12:01             ` Ulrich Drepper
2001-05-20 11:10       ` Philip Blundell [this message]
2001-05-20 12:52         ` Alexandre Oliva
2001-05-20 14:35           ` Philip Blundell
2001-05-20 14:49             ` Alexandre Oliva
2001-05-22  4:58             ` Alexandre Oliva
2001-05-22  5:20               ` Philip Blundell
2001-05-22  7:00                 ` Nick Clifton
2001-05-22  7:15                   ` Alexandre Oliva
2001-05-22  7:19                     ` Philip Blundell
2001-05-20 16:44           ` H . J . Lu
2001-05-20 21:22             ` Mark Mitchell
2001-05-21  9:04               ` H . J . Lu
2001-05-20 23:50             ` Philip Blundell
2001-05-21  8:54               ` H . J . Lu
2001-05-22  3:23                 ` Alexandre Oliva
2001-05-22 10:08                 ` Matt Schalit

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=E151Xeo-0007oa-00@kings-cross.london.uk.eu.org \
    --to=philb@gnu.org \
    --cc=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.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).