Re: GCC Tool breaks linker for explicitly named libraries

Hi Mats (and Bill),

Sorry for the delay in replying.

>> I'm presuming you meant you want -l:foo rather than -l:libfoo.a, since the former is the approved syntax.

No, if you use the -l: form you have to provide the full file name so -l:foo would look for a library file called, literally, "foo" (whereas, without the colon, if would look for "libfoo.so" and, if that is not found, "libfoo.a") so, if you want to link explicitly against libfoo.a (even if libfoo.so exists), you have to provide -l:libfoo.a - which is what the developer wants.

I've worked around it by patching the env so that _stripixes appends a colon to any library that starts with one, calls the underlying SCons _stripixes and then removes the trailing colons afterwards, so this isn't blocking me but I don't know whether we would want this support coded directly into SCons or not...

Thanks,

S.

-----Original Message-----
From: Scons-users <[email protected]> On Behalf Of Mats Wichmann
Sent: 17 December 2021 19:44
To: [email protected]
Subject: Re: [Scons-users] GCC Tool breaks linker for explicitly named libraries

EXTERNAL EMAIL: Do not click links or open attachments unless you know and trust the sender.


On 12/17/21 09:03, Steve Hill (Wireless) via Scons-users wrote:
> Hi,
>
> We’ve had someone add a library as “:libfoo.a” to force the (GCC) 
> linker to link against exactly “libfoo.a” and ignore “libfoo.so”.
> Unfortunately, when they add this, _stripixes removes the “.a” and 
> passes “-l:libfoo” to the linker. Since a library with the exact name 
> “libfoo” doesn’t exist, the link fails. If they add the library as 
> “:libfoo.a.a”, _stipixes removes one (and only one) “.a”, leaving 
> “-l:libfoo.a” and the link completes successfully.
>
> Is this a bug or is there a workaround for this use-case?

SCons doesn't know about the GNU linker's : syntax for libraries, so the behavior would be unpredictable. Not surprised stripixes makes a mess of it.

I'm presuming you meant you want -l:foo rather than -l:libfoo.a, since the former is the approved syntax.

You'd have to put the library in by name, like /path/to/libfoo.a to force this the static-lib-only behavior, and since you have to put it in LINKFLAGS, not in LIBS, you lose control of the library ordering if it happens to matter. Not ideal - there are more than a few GCC-specials that aren't directly understood by SCons.  This is somewhat unfortunate, and probably the maintainer wouldn't be completely adverse to patches.
The problem with adding too much syntax specific to one compiler suite is it makes it much easier to fall into traps where things are inadvertently non-portable.

There are some other "don't know about that" things from gcc listed in https://urldefense.com/v3/__https://github.com/SCons/scons/issues/3064__;!!Niha4SQ!vFL_xQ6ZNswCF57tksnzaKFTb7d5gQF-yxTbP-XmGN75SEDFwzzLa6ecZaAgl5y_1ByROaCv$ .  I added a comment there almost three years ago now when I was less directly involved with SCons development and ran into some behavior on the project I was working on at the time.
_______________________________________________
Scons-users mailing list
[email protected]
https://urldefense.com/v3/__https://pairlist4.pair.net/mailman/listinfo/scons-users__;!!Niha4SQ!vFL_xQ6ZNswCF57tksnzaKFTb7d5gQF-yxTbP-XmGN75SEDFwzzLa6ecZaAgl5y_1IS0-Ybv$
_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users