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: povray build error

On Dec 6, 2020, at 15:59, Murray Eisenberg wrote: > My mistake in calling the learning system WIMS a port — it is not. Rather, it > is a separate download, from: > > >

Re: how change menus in openscad from Russian to English?

On Dec 6, 2020, at 16:00, Murray Eisenberg wrote: > On 6 Dec2020, at 3:49 PM, Ryan Schmidt wrote: >> >> >> >> On Dec 6, 2020, at 12:23, Murray Eisenberg wrote: >> >>> I just installed the openscad port and find that nearly all its menu items >>> in the installed GUI OpenSCAD.app are in

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: how change menus in openscad from Russian to English?

On 6 Dec2020, at 3:49 PM, Ryan Schmidt wrote: > > > > On Dec 6, 2020, at 12:23, Murray Eisenberg wrote: > >> I just installed the openscad port and find that nearly all its menu items >> in the installed GUI OpenSCAD.app are in Russian, in which I’m rather rusty. >> >> How can that language

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: povray build error

My mistake in calling the learning system WIMS a port — it is not. Rather, it is a separate download, from: https://wims.matapp.unimib.it/wims/wims.cgi?session=86081EB7CC.1&+lang=en&+module=adm%2Flight&+phtml=download.phtml.en However, the installation instructions at

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: installing openscad

thanks… Owing to David Strubbe’s previous messages, I found the correct place on github and was able to install the older bison as well as, at last, openscad. > On 6 Dec2020, at 3:35 PM, Ryan Schmidt wrote: > > > > On Dec 5, 2020, at 19:51, Murray Eisenberg wrote: > >> Those instructions

Re: how change menus in openscad from Russian to English?

> Please file a ticket in our issue tracker assigned to the port's maintainer > asking them to update the port, or submit a pull request updating the port. FYI, There is an open PR to update OpenScad to the 2019 version already here but

Re: povray build error

On Dec 6, 2020, at 11:31, Murray Eisenberg wrote: > Any chance of povray being fixed to avoid the fatal build errors reported > already at https://trac.macports.org/ticket/60961? > > I note that no maintainer is listed (from sp info --maintainer povray or on > the ticket). Working on it.

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: how change menus in openscad from Russian to English?

On Dec 6, 2020, at 12:23, Murray Eisenberg wrote: > I just installed the openscad port and find that nearly all its menu items in > the installed GUI OpenSCAD.app are in Russian, in which I’m rather rusty. > > How can that language be changed? I tried its preferences but found no > language

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: installing openscad

On Dec 5, 2020, at 19:51, Murray Eisenberg wrote: > Those instructions say that if the older versions have been uninstalled — > which I did do — then to start by searching in the repositiry — which I did. > But I don’t see any History item for that port. The history of the bison portfile is

how change menus in openscad from Russian to English?

I just installed the openscad port and find that nearly all its menu items in the installed GUI OpenSCAD.app are in Russian, in which I’m rather rusty. How can that language be changed? I tried its preferences but found no language setting (or at least didn’t recognize a Russian word or phrase

povray build error

Any chance of povray being fixed to avoid the fatal build errors reported already at https://trac.macports.org/ticket/60961? I note that no maintainer is listed (from sp info --maintainer povray or on the ticket). I need it not only for itself, but in

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: Need help reverting to older library

of course the simplest method of reverting to an older binary is to just reactivate it if you still have it installed, but inactive, after an update. This will show you what versions are installed: port -v installed portname and this: port activate portname will give you a menu of previous

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