public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* -Wl,<options> mechanism
@ 2003-11-05 15:52 Tal Agmon
  2003-11-06  1:52 ` Jim Wilson
  0 siblings, 1 reply; 2+ messages in thread
From: Tal Agmon @ 2003-11-05 15:52 UTC (permalink / raw)
  To: gcc, gcc-help

Hi,

I'm using GCC version 3.3.2, the target is i686-pc-linux-gnu.
It seems that the -Wl,<options> command option is not working correctly :
My wish is to pass the linker an option which precedes (and by that
overrides) other options.
But when processing the '%X' spec option in LINK_COMMAND_SPEC,
there is no output of accumulated linker options, although specified in the
driver's command line.
I think that they are processed as explicit_link_files via the '%o' spec
option.

I noticed in gcc.c that %x{OPTION} records OPTION for %X to output, and not
-Wl,<option> as should be -
This is different than how accumulated assembler/preprocessor options are
handled.

Maybe i'm missing something here.
Can you explain the problem ?

Thanks,
      Tal.




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: -Wl,<options> mechanism
  2003-11-05 15:52 -Wl,<options> mechanism Tal Agmon
@ 2003-11-06  1:52 ` Jim Wilson
  0 siblings, 0 replies; 2+ messages in thread
From: Jim Wilson @ 2003-11-06  1:52 UTC (permalink / raw)
  To: Tal Agmon; +Cc: gcc, gcc-help

Tal Agmon wrote:
> I'm using GCC version 3.3.2, the target is i686-pc-linux-gnu.
> It seems that the -Wl,<options> command option is not working correctly :

It is hard to understand what you are complaining about.  Your message 
is not very clear.  Please give an example.

Gcc does attempt to preserve the order of options as much as possible, 
but since there are multiple ways of specifying options on command lines 
and via specs, we can't always ensure this.

Note that some linker options are library specific and may come in 
pairs.  So if someone specifies
	-Wl,-Bsymbolic foo.so -Wl,-Bdynamic bar.so
then we must preserve the order of these four options to get the right 
affect.  There is a complication here though because foo.so is not an 
option, it is a file name.  So in order to get this right, we treat 
linker options similarly to how we treat filenames, to ensure that their 
relative order does not change.

This is an issue that does not apply to preprocessor or assembler 
options, because we do not support the ability to turn on different 
options for different preprocessor/assembler input files.  Because of 
this, we can not necessarily make linker options work the same way as 
preprocessor/assembler options.

Perhaps this could be improved by treating linker input files as if they 
were options instead of the other way around, but it isn't clear if this 
helps you.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-11-06  1:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-05 15:52 -Wl,<options> mechanism Tal Agmon
2003-11-06  1:52 ` Jim Wilson

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).