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 07:58, Jonathan Wakely <[email protected]> wrote:
> 
> On Sat, 21 Feb 2026, 20:16 Peter Dyballa via Gcc-help, <[email protected]> wrote:

> I was trying to build the legacy edition of pre-release binaries for TeX Live '26 on that 15 years old Mac with modern and recommended GCC 14 (although 15 and 15 would match) – and failed (at least in my opinion):
> 
>         LiveTeXHaX pete 140 /\  otool -L TeXLive-2026/inst/bin/x86_64-apple-darwin10.8.0/xdvipsk
>         TeXLive-2026/inst/bin/x86_64-apple-darwin10.8.0/xdvipsk:
>                 /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.34.0)
>                 /opt/local/lib/libgcc/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
>                 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
> 
> (otool is similar to Linux' ldd) The two shared libraries are not installed on each Mac, and so I wished they were linked in as static libraries that only exist as:
> 
>         -rw-r--r-- 1 root admin 22341536 20. Feb 13:40 /opt/local/lib/gcc14/libstdc++.a
> 
> Build of TL '26 is done via a shell script that configures and makes in dozens of directories. Its invocation was with:
> 
>         CC=gcc-mp-14 CFLAGS="-O0 -fdata-sections -ffunction-sections -static-libgcc -L/usr/lib -Wl,-dead_strip -Wl,-t -Wl,-v" CXX=g++-mp-14 CXXFLAGS="-v -O0 -stdlib=libstdc++ -static-libstdc++ -Wl,-rpath /usr/lib"
> 
> 
> This looks wrong, there should be a comma after -rpath not a space, so -Wl,-rpath,/use/lib

Right.

Also

 * I am wondering why you want to set an rpath for /usr/lib - what is the objective?

   (we obviously need to link the library versions that belong to the compiler, the [libstdc++] version that is installed on the system only supports c++98)

 * -fdata-sections -ffunction-sections are ignored on macOS
 
> Also I would expect that to be in LDFLAGS not CXXFLAGS
> 
> I would expect -static-libstdc++ to be sufficient to make it link to the libstdc++.a library though, instead of libstdc++.6.dylib

It certainly Works For Me™ that way:

$ uname -a
Darwin xxxxxx.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

$ /opt/iains/x86_64-apple-darwin10/gcc-14-2Dp3/bin/g++ /source/test/hello.cc -static-libstdc++ -static-libgcc -o hcc

$ otool -Lv hcc
hcc:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	time stamp 2 Thu Jan  1 01:00:02 1970

> The system provides:
> 
>         -r-xr-xr-x 1 root wheel 6890816  8. Jun 2011 ≈
>         lrwxr-xr-x 1 root wheel      17  9. Feb 12:05 /usr/lib/libSystem.dylib -> libSystem.B.dylib

^^ this looks right 

>         -rwxr-xr-x 1 root admin 2304336  3. Aug 2022  /usr/lib/libc++.1.dylib
>         lrwxr-xr-x 1 root admin      14  3. Aug 2022  /usr/lib/libc++.dylib -> libc++.1.dylib
>         -rwxr-xr-x 1 root admin  469888  3. Aug 2022  /usr/lib/libc++abi.dylib
>         lrwxr-xr-x 1 root wheel      15  9. Feb 12:05 /usr/lib/libc.dylib -> libSystem.dylib

^^^ this is not a standard installation of macOS 10.6 (Darwin10.8) those libraries have been installed by some other process - look at the dates on the files … 11 years after the last system release for 10.6.

====

On a “stock” MacOS X 10.6 with all the security updates provided by Apple …

$ ls -la /usr/lib/libc+*
ls: /usr/lib/libc+*: No such file or directory

this is the system C++ runtime:

$ ls -la /usr/lib/libstdc++*
-rw-r--r--  1 root  wheel  15401916 24 Oct  2010 /usr/lib/libstdc++-static.a
-rwxr-xr-x  1 root  wheel   2439888 18 May  2009 /usr/lib/libstdc++.6.0.9.dylib
lrwxr-xr-x  1 root  wheel        21 16 Apr  2016 /usr/lib/libstdc++.6.dylib -> libstdc++.6.0.9.dylib

Note 6.0.9 c.f. the GCC-14 version of 6.0.33 or so.

====

It is possible that the MacPorts folks have made changes to the way that the compiler command lines are processed to make them more compatible with their installation layout.  You would need to take that up with the MacPorts maintainers.  I certainly do not see any issues with gcc-14.2 on MacOSX 10.6.

> Can I reach my aim with GCC 14 or 15? Or is GCC 10 better suited (-std=c++17 needs to be supported)? (The MacPorts folks, that foster the MacPorts package manager with which I built GCC, use GCC 10 to bootstrap the software from almost nothing, just a small installer package.)

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.

Iain