Re: Compiling static executables on old Mac OS X 10.6.8, Snow Leopard, with GCC 10 or newer

Hi Peter,

> On 22 Feb 2026, at 10:32, Peter Dyballa <[email protected]> wrote:
> 
> 
>> Am 22.02.2026 um 10:05 schrieb Iain Sandoe <[email protected]>:
>> 
>> * I am wondering why you want to set an rpath for /usr/lib - what is the objective?
> 
> Prepare the executables to find shared libraries in /usr/lib on the other old Macs. In TeX Live (TL) are applications that use some more libraries, those that come with Mac OS X. Xindy is such an example, needing also libs readline, ncurses, iconv, intl… Those who set up the TL building system decided to use the OS to some extent.

It is not necessary to add an rpath to access system libraries.  In the SDKs (or on the system) these have the full path as part of their names : e.g. (taking a random example)

$ otool -Lv /usr/lib/libxml2.dylib
/usr/lib/libxml2.dylib:
	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)

When these are linked into another DSO (either executable or dylib) the full name is present and therefore they can be located by dyld (the dynamic loader).

embedded rpaths are needed when libraries are specified with
@rpath/libsomething.dylib 

since, now, there is no hint for dyld about where to find libsomething.dylib

for example, in my default build of GCC I keep all the runtimes as `@rpath` and the driver automatically adds -rpaths pointing to the compiler install (which allows us to have one build of the compiler that can be installed into different positions).

$otool -Lv libgcc_s.1.1.dylib
libgcc_s.1.1.dylib:
	@rpath/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)

and showing the example “hcc” (hello world) program from my first reply:

$ otool -lv hcc |grep -A3 LC_RPA
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 13
          cmd LC_RPATH
      cmdsize 96
         path /opt/iains/x86_64-apple-darwin10/gcc-14-2Dp3/lib/gcc/x86_64-apple-darwin10/14.2.0 (offset 12)
Load command 14
          cmd LC_RPATH
      cmdsize 64
         path /opt/iains/x86_64-apple-darwin10/gcc-14-2Dp3/lib (offset 12)

so you can see that the compiler added rpaths suitable to find the shared libraries that the compiler provides.

I agree that this is a slightly complicated situation on macOS (and FWIW Windows) - since the runtimes for GCC are not part of the OS distribution and there is no really easy way for an end user to get them - hence the use of distributions like MacPorts or HomeBrew and/or distributing packages with the necessary runtime built in.

======

It looks like MacPorts has overridden the default to use @rpath (or built the compiler with the facility switched off) - this might well be more compatible with the distribution aims - and you might find that just building your project without any added “-rpath”s just DTRT.

>> Unless the package that you are building requires some facility that GCC does not currently support (e.g. Apple Blocks or some of the newer Objective-C features) then I would expect it to be entirely possible.  Of course, TeXLive is one of the larger packages - I have not personally tried to build that in the last 10 years or so.
> 
> I think TL '26 is not that tricky. It also needs to build on Linux, MS Windows, Solaris, BSD dialects, Android…

Good luck, I have built it in the past on Darwin9 and 10 (MacOSX 10.5 and 10.6) but not any recent version.

Iain