> Hi,
>
> I would like to specify command line options for gcc or ld in a file.
> All I have found so far by looking at the documentation is that I can
> write a linker script using the ld command language.
Why don't you just use a Makefile?
Matt
> Thanks, but the back quotes trick is not available in all shells, as you
> pointed out and thus I can't use that either. For now I guess I'll revert to
> creating a list of my -u options and then stick them directly onto the gcc
> command line. I'll try positing another message to the binutils list to see
> if I get an answer why EXTERN is not working as I expected it to.
Actually, backquotes are available in at least bash, tcsh, csh, and
ksh. I'd expect they are available everywhere.
--
- Geoffrey Keating <geo...@geoffk.org>
gcc `cat options.txt` ...
I can't the arguments being used are dynamic and are not known ahead of
time. In addition using a makefile would be completely different from what
is done on other platforms and would required a lot of extra code to
handle this special case. It would be much better if gcc would accept a
command file.
Robert
>
>
> Matt
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
LINUX
I would like to specify command line options for gcc or ld in a file.
All I have found so far by looking at the documentation is that I can
write a linker script using the ld command language. However, this is
not working for me as described below.
Background:
I am trying to generate a shared library by linking an object file (.o)
an archive (.a) and some other shared library (.so) on a linux system.
When linking the object code (.o) file I want to force some symbols to
be undefined, such that they are linked from the archive, where they are
defined. If I use the -u option on the g++ command line this is working.
However, since I have a number of symbols and don't want to list them
all on the command line I want to use a text file to provide these
arguments. I have tried a linker script, specified with -Wl,scriptname
on the g++ command line, but is not working for me at all. The script
basically has a bunch of EXTERN definitions in it, and according to the
documentation this is the same as -u on the command line. Here is a
snippet.
EXTERN(ucorr_);
EXTERN(uel_);
EXTERN(uexpan_);
EXTERN(uexternaldb_);
EXTERN(ufield_);
EXTERN(ufluid_);
There are no complaints during linking, but when I try to load the
library created with this linker script I get the following error.
error while loading shared libraries: undefined symbol: uexternaldb_
Now if I use the same link command with the exception of replacing the
link script name with a -u uexternaldb_ everything works as expected.
What am I messing up here?
The info pages state the following:
`EXTERN(SYMBOL SYMBOL ...)'
Force SYMBOL to be entered in the output file as an undefined
symbol. Doing this may, for example, trigger linking of additional
modules from standard libraries. You may list several SYMBOLs for
each `EXTERN', and you may use `EXTERN' multiple times. This
command has the same effect as the `-u' command-line option.
Any help is much appreciated. This is on a SuSE 7.1 and RedHat 6.2
system.
SuSE:
ld -v
GNU ld version 2.10.91 (with BFD 2.10.0.33)
RedHat:
ld -v
GNU ld version 2.9.5 (with BFD 2.9.5.0.22)
Thanks,
Robert
> Matt Hiller wrote:
> > Why don't you just use a Makefile?
>
> I can't the arguments being used are dynamic and are not known
> ahead of time. In addition using a makefile would be completely
> different from what is done on other platforms and would required a
> lot of extra code to handle this special case. It would be much
> better if gcc would accept a command file.
So compute your flags and put them in a file (one per line, all in
one line, or combinations thereof -- it doesn't matter) and then run
gcc thusly
gcc ARGS `cat YOUR-FILE-NAME` MORE-ARGS
The shell is your friend. Read about command expansion.
> On Fri, 27 Apr 2001, Robert Schweikert wrote:
>
> > handle this special case. It would be much better if gcc would accept a
> > command file.
> >
> > Robert
>
> I take it something like
>
> % g++ `file` foo.C bar.C -o foobar
>
> where file contains, e.g.,
>
> -u ucorr_ -u uel_
>
> wouldn't be a satisfactory solution either? (Or whatever the equivalent in
> your shell is if you're not running a shell that handles this as tcsh or
> bash will.)
Matt,
Thanks, but the back quotes trick is not available in all shells, as you
pointed out and thus I can't use that either. For now I guess I'll revert to
creating a list of my -u options and then stick them directly onto the gcc
command line. I'll try positing another message to the binutils list to see
if I get an answer why EXTERN is not working as I expected it to.
How does gcc get the options to the linker? is there some secret handshake
that I might be able to use?
Thanks,
Robert
>
>
> The behavior that you're getting out of ld is peculiar, though, as
> -u on the command line and EXTERN in the linker script are supposed to be
> equivalent. Try running gcc or g++ with -v to be certain that the -u
> arguments are being passed on to the linker; assuming they are (and they
> should be), you may want to follow up with questions about it to
> binu...@sources.redhat.com.
>
> Matt