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

> 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.

> 
>   (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

There's a big problem: TeX Live consists of dozens of software packages. A Build script configures them and afterwards builds them. Some packages are written in C, others in C++. So I had to take care that each language is handled correctly.

> 
> 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

I have an older kernel:

	Darwin LiveTeXHaX 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64

>> 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.

I observed that too! I imagined that the installation of Xcode could have made these changes (but 2022?). Another and more successful builder of TL '26 is Mojca Miklavec Groenhuis (according to a TL '26 README file she is using Clang 5.0). She suspected that MacPorts installed these files. In order to use that package manager I have to install a small package first. With pkgutil I can list its contents – but no sign of "libc".

Now that I have time to install Snow Leopard more sanely, not being in a hurry, I can have an eye on these. With Apple's Time Machine I can save what I already had built with MacPorts (and deleted from what Migration Assistant had brought in from PPC Leopard)…

> ====
> 
> On a “stock” MacOS X 10.6 with all the security updates provided by Apple …
> 
> 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

	-rw-r--r-- 1 root wheel 15262940 10. Mai 2010  /usr/lib/libstdc++-static.a
	-rwxr-xr-x 1 root wheel  2439888 18. Mai 2009  /usr/lib/libstdc++.6.0.9.dylib
	lrwxr-xr-x 1 root wheel       21  9. Feb 12:05 /usr/lib/libstdc++.6.dylib -> libstdc++.6.0.9.dylib


> ====
> 
> 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.

Actually /usr/lib/libc++* plays no role any more, since I had to find during my tries to build that I should prefer libstdc++ to build the (or at least some) C++ programmes with: "-stdlib=libstdc++ -static-libstdc++". (The error messages with libstdc++ are clearer, focused on what really is not OK, not mentioning things that start with '"std::'.)

> 
> 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…


Thank you both!

--
Greetings

  Pete

Who the fsck is "General Failure" and why is he reading my disk?