This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: linker file/section matching rules when using libraries
Hi Ian,
Thanks - I found that documentation too (in the "brick" on my bookshelf )
:-)
> In other words, if you want to search for the library, either put it
> on the command line, or use an INPUT statement.
I already have the library on the command line and it does get linked in
with a default rule...
The library file is build/lib/libipWeb.a
On the commandline I specify: -Lbuild/lib -lipWeb
This works correctly and gets linked in with my normal rule of:
* (.text .text.*)
The follow rule also works:
build/lib/libipWeb.a (.text .text.*)
However if I remove the path it failes dispite having the search path and
the library included on the command line.
Unfortunatly the build path changes for different projects... the path is
available to the makefile to pass to the linker but not available to the
c-preprocessor that generates the linker script.
I suspect that it isn't matching the full lib name from the rule
(libipWeb.a) against the command line reference (-lipWeb).
If this is expected to work then I will debug through it. Just making sure
that I might be missing something obvious.
Thanks
Nick
----- Original Message -----
From: "Ian Lance Taylor" <ian@wasabisystems.com>
To: "Nick Kelsey" <fsf@silicondust.com>
Cc: <binutils@sources.redhat.com>
Sent: Wednesday, February 04, 2004 8:29 PM
Subject: Re: linker file/section matching rules when using libraries
> *This message was transferred with a trial version of CommuniGate(tm) Pro*
> "Nick Kelsey" <fsf@silicondust.com> writes:
>
> > > If you name an archive, the mapping will be applied to every object in
> > > the archive. At least, that is how it is supposed to work.
> >
> > I ran some more tests...
> >
> > I have just discovered that it works if I give the path (absolute or
> > relative) but it can't find it using the -L search paths.
> >
> > The libraries all link ok normally with the search path.
> >
> > Is this a bug?
>
> No. When you name a file in a wildcard statement the linker doesn't
> make any special effort to find it.
>
> I quote the documentation:
>
> When you use a file name which does not contain any wild card
> characters, the linker will first see if you also specified the file
> name on the linker command line or in an @code{INPUT} command. If you
> did not, the linker will attempt to open the file as an input file, as
> though it appeared on the command line. Note that this differs from
an
> @code{INPUT} command, because the linker will not search for the file
in
> the archive search path.
>
> In other words, if you want to search for the library, either put it
> on the command line, or use an INPUT statement.
>
> Ian
>
>