Re: Compiling a port statically

Hi Ryan, Ryan Schmidt wrote: - building "always safe" binaries which can be used at system level, e.g. login shells, tools, things put in launchd. That is things you want to always work, even if you are during a MacPorts upgrade. NetBSD offers two packages for the same thing, e.g. bash and

Re: Compiling a port statically

[ Slightly OT ] On Mon, 7 Dec 2020, Jeffrey Walton wrote: Static linking also allows you to move binaries around the filesystem with dicking around with otool and install_name_tool. Stack Overflow has several questions related to OS X programs that are linked to OpenSSL. The programs had a

Re: Compiling a port statically

If you want the library to move with the program, the program has to be linked using relative paths to the library/libraries. Then they can be moved together, as long as they retain the same relative path relationship. > On Dec 7, 2020, at 09:16, Jeffrey Walton wrote: > > On Mon, Dec 7, 2020

Re: Compiling a port statically

On Mon, Dec 7, 2020 at 2:39 AM Ryan Schmidt wrote: > > > > On Dec 7, 2020, at 01:01, Jeffrey Walton wrote: > > > Static linking also allows you to move binaries around the filesystem > > with dicking around with otool and install_name_tool. > > Since programs are linked to libraries by their

Re: Compiling a port statically

On Dec 7, 2020, at 01:01, Jeffrey Walton wrote: > Static linking also allows you to move binaries around the filesystem > with dicking around with otool and install_name_tool. Since programs are linked to libraries by their absolute path, you can move a program anywhere in the filesystem

Re: Compiling a port statically

On Sun, Dec 6, 2020 at 10:31 AM Riccardo Mottola via macports-users wrote: > > Hi, > > On 12/5/20 8:07 AM, Ryan Schmidt wrote: > > Obviously the block would need some tweaking for a given port, it gives the > idea. > > I can't think of a reason why we would want to offer such a thing. > > I can

Re: Compiling a port statically

Cool. Given /opt/ffmpeg/bin with MacPorts /opt/local/bin/ffmpeg copied into it, and a parallel /opt/ffmpeg/lib directory, with the /opt/ffmpeg/bin as the current working directory, the following worked: dylibbundler -x ffmpeg -b -d ../lib -p @executable_path/../lib ...and I just used the

Re: Compiling a port statically

Not to worry, I won't install that mpkg! It was just a test of creating one (not installing it), for which I didn't feel like creating a separate MacPorts install under an alternative prefix. "very likely will work on subsequent OS versions" with likelihood, since NOT guaranteed, likely

Re: Compiling a port statically

Hi, On Sun, Dec 06, 2020 at 05:32:12PM -0500, Richard L. Hamilton wrote: > So on macOS, if you're worried more about breakage in the absence of > shared libraries than in updated-ness/correctness, you can IN > PRINCIPLE statically link with non-OS libraries, and only dynamically > link with the

Re: Compiling a port statically

On Dec 6, 2020, at 18:40, Richard L. Hamilton wrote: > I was thinking about port mpkg or port mdmg as an alternative, but since it > looks like that may put its files in the same place as the MacPorts > installation on which it was created does, it's not practical for anything > except

Re: Compiling a port statically

Your use of the word "proposal" is generous. It isn't, of course; but merely a hypothetical way that (with significant MacPorts implementation changes!) it could be possible to have static variants that can be kept up to date without the libraries they depend on having to know about them.

Re: Compiling a port statically

On Dec 6, 2020, at 16:44, Richard L. Hamilton wrote: > Why should that change? You don't pre-build binaries for more than a few very > common variants, so you wouldn't do so for static variants using such a > capability. True, we only build the port's default variants (and universal, if

Re: Compiling a port statically

On Mon, 7 Dec 2020, Dave Horsfall wrote: Agreed; FreeBSD has an "/sbin" directory (and "/usr/local/sbin") containing stuff that absolutely must be available, even in the lack of absence of shared libraries. Oops - forgive the double negative at the end (not enough coffee). -- Dave

Re: Compiling a port statically

Why should that change? You don't pre-build binaries for more than a few very common variants, so you wouldn't do so for static variants using such a capability. It (hypothetically) would merely be there for those cases where (a) the needed library ports provided a static version, (b) someone

Re: Compiling a port statically

gentlemen, Of course, we’re not talking about linking the system libraries statically. First of all, you can’t link libSystem statically. Secondly if they are gone, we’d done. We’re talking about linking macports more ephemeral libraries statically, so the binary for bash or gmake or

Re: Compiling a port statically

My other promised devils-advocate post: while you can have user or 3rd-party static libraries on macOS, the core OS libraries are not static. Even on Snow Leopard, libSystem was only dynamic; and on Catalina, I don't see ANY .a files in /usr/lib. So on macOS, if you're worried more about

Re: Compiling a port statically

On 6 Dec 2020, at 10:31, Riccardo Mottola via macports-users wrote: Hi, On 12/5/20 8:07 AM, Ryan Schmidt wrote: Obviously the block would need some tweaking for a given port, it gives the idea. I can't think of a reason why we would want to offer such a thing. I can think of two

Re: Compiling a port statically

On Dec 6, 2020, at 15:27, Dave Horsfall wrote: > On Sun, 6 Dec 2020, Riccardo Mottola via macports-users wrote: > >> I can think of two scenarios [ for static binaries ]: >> - building "always safe" binaries which can be used at system level, e.g. >> login shells, tools, things put in

Re: Compiling a port statically

On Dec 6, 2020, at 15:52, Richard L. Hamilton wrote: > I'm going to play devil's advocate on this and another post (with competing > positions, so don't feel bad). > > MacPorts knows the library dependencies of a port. While it does not now > (AFAIK) record the specific versions of each

Re: Compiling a port statically

I'm going to play devil's advocate on this and another post (with competing positions, so don't feel bad). MacPorts knows the library dependencies of a port. While it does not now (AFAIK) record the specific versions of each used to build an installed port, in principle, it could; at which

Re: Compiling a port statically

On Sun, 6 Dec 2020, Riccardo Mottola via macports-users wrote: I can think of two scenarios [ for static binaries ]: - building "always safe" binaries which can be used at system level, e.g. login shells, tools, things put in launchd. That is things you want to always work, even if you are

Re: Compiling a port statically

> On Dec 6, 2020, at 12:42 PM, Ryan Schmidt wrote: > > we should not distribute portfiles that perform static program builds. > I have never attempted to do so. Just helping out a user who wanted to know if it was _possible_ to build a static ffmpeg, and it likely is, with MacPorts. K

Re: Compiling a port statically

On Dec 6, 2020, at 09:31, Riccardo Mottola wrote: > I can think of two scenarios: > > - building "always safe" binaries which can be used at system level, e.g. > login shells, tools, things put in launchd. That is things you want to always > work, even if you are during a MacPorts upgrade.

Re: Compiling a port statically

On Dec 5, 2020, at 01:23, Ken Cunningham wrote: > On 2020-12-04 11:07 p.m., Ryan Schmidt wrote: >> I can't think of a reason why we would want to offer such a thing. >> > You probably noticed some specifically asked how this would be done one > question before, which is why I volunteered

Re: Compiling a port statically

On Dec 6, 2020, at 11:13, Richard L. Hamilton wrote: > Of course, that also requires that every library port it depends on builds a > static version as well as a shared version. > > So I would imagine, even given the argument in favor of limited static > executables, that there would be at

Re: Compiling a port statically

older bash versions have a vulnerabilty so I replace it with a current static bash on every older system I use. K

Re: Compiling a port statically

Of course, that also requires that every library port it depends on builds a static version as well as a shared version. So I would imagine, even given the argument in favor of limited static executables, that there would be at most, very few indeed. As others said recently, probably best not

Re: Compiling a port statically

Hi, On 12/5/20 8:07 AM, Ryan Schmidt wrote: Obviously the block would need some tweaking for a given port, it gives the idea. I can't think of a reason why we would want to offer such a thing. I can think of two scenarios: - building "always safe" binaries which can be used at system

Re: Compiling a port statically

On 2020-12-04 11:07 p.m., Ryan Schmidt wrote: I can't think of a reason why we would want to offer such a thing. You probably noticed some specifically asked how this would be done one question before, which is why I volunteered this. MacPorts is quite flexible for "power users". For me

Re: Compiling a port statically

On Dec 5, 2020, at 00:09, Ken Cunningham wrote: > There was a nice tweak put forth by -- I think it was Bill Cole -- to link a > port statically. I used it for bash and gmake, but the idea might work for > other ports too. > > > See >

Compiling a port statically

There was a nice tweak put forth by -- I think it was Bill Cole -- to link a port statically. I used it for bash and gmake, but the idea might work for other ports too. See for an idea