Patch - Re: linker file/section matching rules when using libraries

Jafa jafa@silicondust.com
Thu Feb 5 22:53:00 GMT 2004


Hi Ian,

Ok, I traced out the behavior...

The problem is that when the library files specified on the command line are
qualified the internally tracked filename is updated to include the full
path and the rules only match against these fully qualified path+filenames.

This isn't a bug, just if it could match libraries from the command line it
would be really useful.

In my case, my problem is that the path is different for every project and I
don't have access to the path except in the makefile (which passes it to the
linker as the library include search path).

Currently the trunk code only matches the filename. The attached patch
allows it to match on either filename or the local symbol name.

I think is should always be safe as the local symbol name is the user
specified name and must be unique anyway (both .o and .a files). The
filename is the full path and filename as resolved from the user specified
name.

With library files the filename is the full path and filename of the actual
library file and the local symbol name is the -l<name> short form as
specified by the user.

This patch allows me to pass "-Lbuild/lib -lipWeb" to the linker and then
use the rule: "-lipWeb (.text)" in my linker script.

Is this a reasonable solution?

BTW - You should have a copyright assignment on file (Ubicom).

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 9:33 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:
>
> > 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).
>
> Ah, I see.
>
> I'm not sure whether that should work or not.
>
> I suspect that this would work:
>
> -lipWeb (.text .text.*)
>
> Ian
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: changelog.txt
URL: <https://sourceware.org/pipermail/binutils/attachments/20040205/085fa792/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldlang.diff
Type: application/octet-stream
Size: 1098 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040205/085fa792/attachment.obj>


More information about the Binutils mailing list