This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: several newbie questions (spec files, "pathing", static linking, etc)


On Tue, Oct 21, 2003 at 02:40:49PM -0500, Wolcott, Ken (MED, Compuware) wrote:
> 
>   However, my developers would like to have the the cross compiler tool chain 
> to be statically linked rather than dynamically linked.  So is this done via 
> configure --enable-static when compiling gcc and glibc or via configure 
> --disable-shared?  Or do I have to modify the associated Makefiles manually 
> of all components so that LD is given -static?

The --enable/--disable switches affect the kinds of runtime libraries built
during the bootstrap process, not the capabilities of the new compiler,
nor the linkage of the new compiler.

This is documented at gcc.gnu.org/install, along with the technique for
passing arbitrary flags to the bootstrap compiler (the one building your
new compiler); if you're using gcc as a bootstrap compiler, try adding
-static to the various CFLAGS.


>   Also, there is some mention of manually modifying the "spec" file(s).  What 
> are the gcc spec files?  What I can tell so far is that this mechanism is 
> used so that gcc subcomponents can be found by gcc.  One of my developers 
> calls this "pathing" and he is concerned that gcc picks up libraries that 
> have nothing to do with the target. Could somebody elaborate on the existence 
> of and the purpose of the spec files?

You have the right idea.  I've never heard it called "pathing" before.
To see the full command lines of the subcommands run by gcc, add -v to
the command line.  This will also tell you the location of the primary
specs file.

If you find that you need to make changes which cannot be done using other
command-line options, try making a small ancilliary specs file and using
--specs=filename, rather than editing the primary file.  Be careful in any
case, as the format is extremely fragile.  (It's meant to be read quickly
by a program, not edited easily by a human.[*])


Phil
[*]  Analogies with sendmail.cf can be made here.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]