public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] [Patch] trivial fix in linker script
Date: Wed, 29 Jan 2003 18:30:52 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590709805771@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590709805734@msgid-missing>

hi David,

I think you are mentioning about ret_from_clone patch here. 

I am using GNU linker. 

Inline with your observation, Intel compiler emits the type of extern variables. And now based on the order in which object files are linked, linker is failing in some cases. 

If the object file with extern declaration comes after the object file with correct declaration, linker is working fine. But if the object file with extern declaration comes first, then linker is reporting "type of symbol changed" in the second object file with correct declaration.

gcc doesn't fix the type for extern variables, leaves it to the linker. So linking works irrespective of the order.

Is this a GNU linker issue?

thanks,
suresh

> -----Original Message-----
> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
> Sent: Tuesday, January 28, 2003 11:15 AM
> To: Siddha, Suresh B
> Cc: linux-ia64@linuxia64.org
> Subject: RE: [Linux-ia64] [Patch] trivial fix in linker script
> 
> 
> >>>>> On Fri, 24 Jan 2003 12:05:35 -0800, "Siddha, Suresh B" 
> <suresh.b.siddha@intel.com> said:
> 
>   Suresh> hi David, I agree. Attached a bigger patch now :)
> 
> Well, it's not pretty so I deferred working on it to the last, and
> then I got distracted and forgot to do something about it.
> 
> Where exactly does the problem come from?  Is it that the Intel linker
> will complain when it finds the same symbol with different types?
> This kind of overzealous checking is quite a pain and is, IMHO, pretty
> much a bug (there are other annoying "features" like that in the Intel
> toolchain, for example that the assembler insists on all external
> symbols being declared; what a pain...).  If we need to have a
> workaround, we can add one but we should clearly document why the ugly
> hacks are needed.
> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 


  parent reply	other threads:[~2003-01-29 18:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-21  3:16 [Linux-ia64] [Patch] trivial fix in linker script Siddha, Suresh B
2003-01-24 18:30 ` David Mosberger
2003-01-24 20:05 ` Siddha, Suresh B
2003-01-28 19:14 ` David Mosberger
2003-01-28 19:29 ` Sam Ravnborg
2003-01-29 18:30 ` Siddha, Suresh B [this message]
2003-01-29 19:15 ` David Mosberger

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=marc-linux-ia64-105590709805771@msgid-missing \
    --to=suresh.b.siddha@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    /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