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