Hi Ryan, thank you very much for your detailed analysis! I only need the deployment target because I want to build a bundle that can be installed without macports. And as you say there are probably not many who try to do this.
I just figured out that ncurses indeed does not build for deployment target 10.5 because macports or whoever sets the CXXFLAGS to :debug:configure CXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64 -arch i386‘ which results in :info:configure checking if /usr/bin/clang++ works... no :info:configure configure: WARNING: Ignore /usr/bin/clang++, since it cannot compile hello-world. :info:configure configure: WARNING: You don't have any C++ compiler, too bad because the 10.5 and libc++ does not fit as you say. When I install the port with port -v install ncurses configure.cxx_stdlib="libstdc++“ then I can install ncurses (MacOS 10.13 with XCode 10.1). When I try to compile icu with this setting to go further down then I hit the c++11 problem that you mention below (not compatible with libstdc++). This is all without the sdk problem you mention. However Tero tried the bundle targeted for 10.8 on 10.9 and 10.11 and that worked. That was a x86_64 only (not universal). Thanks! Friedrich > Am 03.09.2020 um 17:58 schrieb Ryan Schmidt <[email protected]>: > > > > On Sep 2, 2020, at 10:48, Friedrich Beckmann wrote: > >> i use macports to build a MacOS application bundle for the pspp statistics >> software. I build on my Macbook with MacOS 10.13 and XCode 10.1. The idea is >> that the bundle can run also on previous MacOS versions. I do this by >> setting the macosx_deployment_target to 10.8 in macports.conf. As this >> usually gives problems with some ports, e.g. now rust: >> >> https://github.com/macports/macports-ports/pull/8259 >> >> I switched to the plan to only compile the library dependencies of pspp with >> a different deployment target. So I install everything with no deployment >> target, then I force uninstall some ports, enable deployment target and >> install those ports again. So I try to avoid to compile build time >> dependencies like gimp and rust with a different deployment target. This >> seems to work. >> >> Now I wanted to go further down and set the deployment target to 10.5. It >> seems that the XCode 10.1 compiler then does not compile C++ anymore, e.g. >> when compiling ncurses. Does anybody know some description or a strategy how >> to compile for previous MacOS versions with macports? >> >> Can I for example compile with a GNU gcc compiler and the deployment target >> is still honoured? > > > You're right that MacPorts supports setting macosx_deployment_target in > macports.conf, but we don't advertise that in the documentation, very few > people try to use that, and there are probably many ports that don't honor > that setting. (Many ports' build system set the deployment target themselves. > When we notice this we try to fix it, but there are many such instances that > we probably haven't noticed yet.) > > Even assuming all of the ports you care about do support propagating the > deployment target properly, if the software in question includes C++ software > then you have the problem of the C++ standard library. Apple started > providing a new C++ standard library -- LLVM's libc++ -- in OS X 10.7 and > made it the default in OS X 10.9. Prior to that, the C++ library was GCC > 4.2.1's libstdc++, and it didn't support C++11. Many ports now require C++11 > or newer, so to make it easier to build those on older systems, MacPorts > switched to using libc++ on 10.6-10.8 last year. 10.6 didn't ship with > libc++, so we provide a copy in the libcxx port. > > If you want to distribute an installer containing MacPorts-compiled software > targeting 10.7 or later, no problem. Any C++-using software will use the > system's libc++. > > If you're targeting 10.6 or earlier, slight problem: you have to bundle > libc++ and install it into /usr/lib. If there's already one there with the > same major version (maybe installed by the user's MacPorts installation) it > might be best not to replace it if the one that's already there has a newer > minor version. You could possibly determine library versions by looking at > line 2 of the output of "otool -L /usr/lib/libc++.dylib": The number in the > filename is the major library version (e.g. libc++.1.dylib is major version > 1) and the "current version" is the minor library version. > > If you're targeting 10.5 or earlier, and you're only targeting Intel, that > may work. I believe we have some success getting libc++ installed on 10.5 > Intel. 10.5 PowerPC is probably not possible; I don't think we have libc++ > installable for PowerPC yet, and clang doesn't generate PowerPC code. > > Trying to use older gcc, like gcc 4.2.1 available on 10.5 or in the > apple-gcc42 port, to compile for 10.5 is probably not going to work. Since it > uses libstdc++, it's not C++11 compatible, which would be a problem in case > any of the dependencies of the software you want to package use C++11 or > newer. Using a newer gcc from MacPorts that has a libstdc++ that understands > C++11 could conceivably work, but ports are not generally written to > accommodate the user picking a random compiler and may make incorrect > decisions if you do this. I believe newer gcc can be told to use libc++ > instead of libstdc++ but MacPorts has not been designed with any support for > this. > > There is also the problem of the SDK. If you build using a newer SDK, > software (especially software not written specifically for macOS) that is not > aware of how Apple's SDKs work may inadvertently find and use symbols in the > SDK that are not available on older systems, so the executable won't actually > work on older systems. Ideally the software would be fixed to become aware of > SDKs, by weak-linking to symbols available in the SDK but not on the target > system and checking for their existence at runtime. If that's not possible, > you can build using an older SDK, but that may not work on newer systems; you > may have to build on an older system to do that. > > > > I've given a little thought recently to how best to package software so it's > available to the widest userbase possible (though my thoughts here do not > include consideration of the C++ problem). What I came up with is that I > would provide two packages: one for 32-bit 10.6 and older (built for ppc and > i386 probably on a machine running 10.6 or older, with as old a deployment > target as you need or can build for, e.g. 10.5, or 10.4, or 10.4 on i386 and > 10.3 on ppc), and another for 64-bit 10.6 and newer (built for x86_64 and > arm64 on a machine running 10.15 or newer, with as old a deployment target as > you need or can build for, e.g. 10.6 on x86_64 and 11.0 on arm64). > > You might think you could build a smart installer pkg that contains both of > the aforementioned components and picks the right one when the installer is > run. The problem is that pkg formats changed, with the flat pkg format that > we now prefer having been introduced in 10.5, but missing some key features > until 10.6, such that MacPorts for example distributes its own installers as > a flat pkg from 10.6 onward but uses a non-flat pkg on a dmg for 10.5 and > 10.4. > > If you only care about 64-bit or building 32-bit doesn't work, you could do a > single package that works down to 10.5. Can't go down to 10.4 because > although 10.4 ran on 64-bit processors, some of the OS wasn't 64-bit yet, so > trying to run a universal i386/x86_64 executable on 10.4 will pick the x86_64 > slice and it will fail to launch. > >
