git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Static Linking git for HPE NonStop
@ 2020-06-26 20:33 Randall S. Becker
  2020-06-26 21:13 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Randall S. Becker @ 2020-06-26 20:33 UTC (permalink / raw)
  To: git

Hi Team,

I am faced with a bit of a conundrum. There are multiple implementations of
SSL on our platform that co-exist in some installations. While it is
possible to select which one is used, it becomes difficult with other
subsystems are at play, including Jenkins. Is there anyway to force a static
linkage instead of using DLLs so that we can isolate this for installations
who want to be insulated from the confusion?

We currently have everything encoded in config.mak.uname and do not use make
configure or configure explicitly. Just make.

Thanks,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.




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

* Re: Static Linking git for HPE NonStop
  2020-06-26 20:33 Static Linking git for HPE NonStop Randall S. Becker
@ 2020-06-26 21:13 ` Junio C Hamano
  2020-06-26 21:26   ` Randall S. Becker
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2020-06-26 21:13 UTC (permalink / raw)
  To: Randall S. Becker; +Cc: git

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> ... Is there anyway to force a static
> linkage instead of using DLLs so that we can isolate this for installations
> who want to be insulated from the confusion?
>
> We currently have everything encoded in config.mak.uname and do not use make
> configure or configure explicitly. Just make.

A quick scan of our Makefile seems to say that LDFLAGS is left open
for builder's use (i.e. we don't add hardcoded "always link
dynamically" etc. in there, so that somebody doing a build for a
particular use case can tell the linker "I want things linked
statically" by adding appropriate and linker specific flags to it,
and that propagates to ALL_LDFLAGS to be used at the last stage of
linking the git binary itself.


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

* RE: Static Linking git for HPE NonStop
  2020-06-26 21:13 ` Junio C Hamano
@ 2020-06-26 21:26   ` Randall S. Becker
  0 siblings, 0 replies; 3+ messages in thread
From: Randall S. Becker @ 2020-06-26 21:26 UTC (permalink / raw)
  To: 'Junio C Hamano'; +Cc: git

On June 26, 2020 5:14 PM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> > ... Is there anyway to force a static
> > linkage instead of using DLLs so that we can isolate this for
> > installations who want to be insulated from the confusion?
> >
> > We currently have everything encoded in config.mak.uname and do not
> > use make configure or configure explicitly. Just make.
> 
> A quick scan of our Makefile seems to say that LDFLAGS is left open for
> builder's use (i.e. we don't add hardcoded "always link dynamically" etc.
in
> there, so that somebody doing a build for a particular use case can tell
the
> linker "I want things linked statically" by adding appropriate and linker
> specific flags to it, and that propagates to ALL_LDFLAGS to be used at the
> last stage of linking the git binary itself.

Thanks. That would work just fine.

Regards,
Randall


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

end of thread, other threads:[~2020-06-26 21:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-26 20:33 Static Linking git for HPE NonStop Randall S. Becker
2020-06-26 21:13 ` Junio C Hamano
2020-06-26 21:26   ` Randall S. Becker

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).