Compiling a port statically

[Richard L. Hamilton]

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 dropping with greater distance between OS versions. :-) Esp. if any OS features that there's been any hint of future deprecation for are involved. _Usually_, responsible vendors (Apple being IMO "mostly" in that category) try to keep compatibility EXCEPT for features they give warning that they'll drop. (IMO, Solaris does better than most OSs in that regard, but that's another story). OTOH, some open source projects assume that since you can recompile whenever you want anyway, they don't need to exercise specific care to remain within binary compatibility constraints.

Looking on the ffmpeg.org <http://ffmpeg.org/> compilation guide, I see
	• If using GCC/Clang, consider adding -march=native to --extra-cflags to make slightly better use of your hardware. Alternatively, for a more general solution, examine the --arch and --cpu options. Gains are variable, and usually quite small. However, this is usually even more safe than the above, and is thus listed here.

and in the ffmpeg Portfile, I do NOT see the --cpu or -march=native, so I'm  possibly-to-probably wrong about ffmpeg building in a way that might not be portable across slightly different CPUs of the same architecture and OS version. And nothing jumped out at me from objdump output, although I'm not sure that it would. That's about as deep as I want to dig into that, since I'm not intending to copy binaries around anyway. :-)


> On Dec 6, 2020, at 19:46, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> 
> 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 transferring e.g. a small set of ports (and with the m... variants, those that they depend on) to another machine (same OS, or should later OS probably work too, DEPENDING on quirks of components?) to another system on which there won't be a complete MacPorts installation. Am I right about that?  (see below for an OMG all the dependencies! listing of the xar mpkg file)
> 
> port pkg/dmg/mpkg/mdmg are a way to create macOS installer packages. Yes, they install to the same place that the ports would install, so please do not use port pkg/dmg/mpkg/mdmg if your prefix is /opt/local if you intend to distribute it to others; instead, build MacPorts in another prefix corresponding to your project name, such as /opt/myproject.
> 
> Ports built on one OS version very likely will work on subsequent OS versions but possibly without optional features that only became available on that new OS version.
> 
> 
>> And to Make It Worse, I suspect ffmpeg may build with optimizations that may be dependent on specific hardware (CPU instruction set extensions, etc), so even aside from the possible license issues, it may not be particularly portable anyway.
> 
> If so, we should fix that.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20201206/68ce98a1/attachment.htm>