public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Re: ld: Expand options for partial static linking
@ 2024-04-09 13:23 mshubbard
  2024-04-10 10:16 ` Nick Clifton
  0 siblings, 1 reply; 4+ messages in thread
From: mshubbard @ 2024-04-09 13:23 UTC (permalink / raw)
  To: 'binutils@sourceware.org'

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

Hi Nick,

I'm willing to write patches if the concept is acceptable.

This conversation originated from a pull request I put up for MOLD.
Though in that case I was trying to tread lightly, so the
implementation is the A version.

That discussion in MOLD led to the suggestion that I bring it here.
Without speaking for anybody, I think there was acknowledgement that
the idea has some merit, but since the change wasn't MOLD specific, it
should be discussed in the larger group.

Mike

	-----------------------------------------From: "Nick Clifton" 
To: "binutils@sourceware.org"
Cc: 
Sent: Tuesday April 9 2024 4:24:10AM
Subject: Re: ld: Expand options for partial static linking

 Hi Mike,

 > I would like to propose a new command line option for the linkers
to add support for partial static linking.

 Thanks for bringing up this topic.

 > I have two proposed solutions:
 >
 > A. The lowest impact version
 > Add a command line option along the lines of "--Bstatic-preferred"
that reverses the default searching behavior. It would search
libraries looking for ".a then .so"
 > instead of the default ".so then .a".
 >
 > It solves my problem, and in combination with --Bstatic and
--Bdynamic it covers 3 of the 4 possible search types that could be
conceived.

 Meh. If we are going to fix a problem, let's fix it
 correctly and once, rather than leaving issues for the
 future.

 > B. The logically consistent version:
 > Add four new options that clearly state the behavior. These would
cover all four combinations of the current dynamic and static search
behaviors. Two would be duplicates
 > of existing flags.
 >
 > * --Bstatic-only; same as --Bstatic; linker searches for .a only
 > * --Bdynamic-only; new behavior; linker searches for .so only
 > * --Bstatic-preferred; new behavior; linker searches for .a and
falls back to .so
 > * --Bdynamic-preferred; same as --Bdynamic; linker searches for .so
and falls back to .a; DEFAULT

 I prefer this solution.

 Are you offering to write a patch to implement this behaviour ?

 Have you contacted the LLVM linker people and/or the MOLD linker
 folks about this idea ? If so, do they have a preference ?

 Cheers
 Nick



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ld: Expand options for partial static linking
  2024-04-09 13:23 ld: Expand options for partial static linking mshubbard
@ 2024-04-10 10:16 ` Nick Clifton
  0 siblings, 0 replies; 4+ messages in thread
From: Nick Clifton @ 2024-04-10 10:16 UTC (permalink / raw)
  To: mshubbard, 'binutils@sourceware.org'

Hi Mike,

> I'm willing to write patches if the concept is acceptable.

Yes please. :-)

The concept is definitely acceptable, and if I don't have to
write the patch but only review it then that is good by me.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ld: Expand options for partial static linking
  2024-04-04 13:59 mshubbard
@ 2024-04-09  8:24 ` Nick Clifton
  0 siblings, 0 replies; 4+ messages in thread
From: Nick Clifton @ 2024-04-09  8:24 UTC (permalink / raw)
  To: mshubbard, 'binutils@sourceware.org'

Hi Mike,

> I would like to propose a new command line option for the linkers to add support for partial static linking.

Thanks for bringing up this topic.

> I have two proposed solutions:
> 
> A. The lowest impact version
> Add a command line option along the lines of "--Bstatic-preferred" that reverses the default searching behavior.  It would search libraries looking for ".a then .so" 
> instead of the default ".so then .a".
> 
> It solves my problem, and in combination with --Bstatic and --Bdynamic it covers 3 of the 4 possible search types that could be conceived.

Meh.  If we are going to fix a problem, let's fix it
correctly and once, rather than leaving issues for the
future.

> B. The logically consistent version:
> Add four new options that clearly state the behavior.  These would cover all four combinations of the current dynamic and static search behaviors.  Two would be duplicates 
> of existing flags.
> 
> * --Bstatic-only;  same as --Bstatic; linker searches for .a only
> * --Bdynamic-only; new behavior; linker searches for .so only
> * --Bstatic-preferred; new behavior; linker searches for .a and falls back to .so
> * --Bdynamic-preferred; same as --Bdynamic; linker searches for .so and falls back to .a; DEFAULT

I prefer this solution.

Are you offering to write a patch to implement this behaviour ?

Have you contacted the LLVM linker people and/or the MOLD linker
folks about this idea ?  If so, do they have a preference ?

Cheers
   Nick


^ permalink raw reply	[flat|nested] 4+ messages in thread

* ld: Expand options for partial static linking
@ 2024-04-04 13:59 mshubbard
  2024-04-09  8:24 ` Nick Clifton
  0 siblings, 1 reply; 4+ messages in thread
From: mshubbard @ 2024-04-04 13:59 UTC (permalink / raw)
  To: 'binutils@sourceware.org'

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

Hi All,

I would like to propose a new command line option for the linkers to
add support for partial static linking.

Currently the default behavior is for the linker to search for dynamic
libraries (.so) and if they are not found, search again for a static
library (.a). The alternative is to force the linker to search only
for the static libraries.

In some cases, it is preferred to statically link an executable as
much as possible, but since not every vendor library is available as
static, some dynamic linking is necessary. In my case this would
improve my deployment of AppImages, where the application is
statically compiled and optimized as much as possible, and the dynamic
libraries that remain are included in the squashfs.

The usual suggested workaround is to employ -l: with a fully qualified
path, or to switch the command line between --Bstatic and --Bdynamic.
This forces applications of this type to hard code elements of their
build system into the linking commands of their makefiles. When the
build system updates, the makefiles are manually edited to keep up.

Additionally, many of the linker options have the ability to disable
the default behavior with "--no-", but in this case "--Bstatic" is not
really the negation of "--Bdynamic", and there is currently no way to
control the details of these features.

I have two proposed solutions:

A. The lowest impact version
Add a command line option along the lines of "--Bstatic-preferred"
that reverses the default searching behavior. It would search
libraries looking for ".a then .so" instead of the default ".so then
.a".

It solves my problem, and in combination with --Bstatic and --Bdynamic
it covers 3 of the 4 possible search types that could be conceived.

B. The logically consistent version:
Add four new options that clearly state the behavior. These would
cover all four combinations of the current dynamic and static search
behaviors. Two would be duplicates of existing flags.

* --Bstatic-only; same as --Bstatic; linker searches for .a only
* --Bdynamic-only; new behavior; linker searches for .so only
* --Bstatic-preferred; new behavior; linker searches for .a and falls
back to .so
* --Bdynamic-preferred; same as --Bdynamic; linker searches for .so
and falls back to .a; DEFAULT

There are certainly advantages and disadvantages to both. I look
forward to hearing your thoughts on this.

Thanks,
Mike Hubbard



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-04-10 10:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-09 13:23 ld: Expand options for partial static linking mshubbard
2024-04-10 10:16 ` Nick Clifton
  -- strict thread matches above, loose matches on Subject: below --
2024-04-04 13:59 mshubbard
2024-04-09  8:24 ` Nick Clifton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).