Compiling a port statically

[Richard L. Hamilton]

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 resulting /opt/ffmpeg/bin/ffmpeg to convert an mp4 successfully to webm format. And then played it with mpv, since I was in a command-line mood anyway. :-)

To further show that really did the job altering the copied binary and libraries that it copied, otool -L /opt/ffmpeg/bin/ffmpeg | grep /opt/local   produced zero output as expected, whereas with /opt/local/bin/ffmpeg, it produced lots of output.

So, that copy of ffmpeg and the copies of what it needs, should I gather now be independent of the MacPorts installation. Indeed, they ought to be relocatable to some other directory, as long as the parallel relationship of the bin and lib directories is maintained.

I tried that to show that while perhaps primarily meant for app bundles, it's certainly not limited to that use, given the appropriate command line options (and as you say, executables and/or dylibs built to accommodate such alteration).

If I get ambitious, I'll copy that /opt/ffmpeg tree over from the Catalina I built it on to my Big Sur VM, and see if it works there. :-)

> On Dec 6, 2020, at 19:47, Clemens Lang <cal at macports.org> wrote:
> 
> 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 minimum needed OS libraries. That at least gives you an
>> executable that has no runtime dependencies outside of the OS (and of
>> course any hard-coded paths or configuration files the executable
>> might expect).
> 
> If you're worried about this scenario, it is much easier to create a
> copy of whatever binary you're trying to compile statically and bundle
> it with its dependent libraries. That does not require changing any of
> the ports (except for building with -Wl,-headerpad_max_install_names,
> which MacPorts already does for you to support relocation and bundling
> of such libraries).
> 
> There's even a port in macports called dylibbundler that automates
> adjusting the dylib load commands to do this.
> 
> This entire thread is discussing the feasibility of a single solution to
> a problem, without taking a step back and checking whether there are
> other and potentially simpler solutions for the problem.
> 
> Yes, statically linking non-system libraries can be done on macOS, but
> it is hardly ever done (just look at every .app bundle out there), not
> simple, not well-supported by MacPorts, and there are better
> alternatives.
> 
> -- 
> Clemens
>