ld64-97: have it deal with -rpath on Tiger without erroring?

[kencu (Ken)]

It is increasingly difficult to weed out -rpath link commands on the various build systems we deal with on MacPorts. meson, waf, and libtool, all assume -rpath compatibility on macOS. Keeping up with this is tricky.

CMake is easy to control, thankfully. There are patches for meson to keep this at bay (already committed), and there is apparently a patch for libtool (although it doesn't work for me so far ​here).

It comes to mind that a more comprehensive way to manage this might be to patch ld64-97 to accept the -rpath linker command on Tiger without erroring (that's very easy, two lines to comment out in Options.cpp) and then use that instead to generate a fully qualified path link command (that's a bit harder).

[kencu (Ken)]

If we could get the @rpath logic in ld64-97 to just substitute ${prefix}/lib where it would just write @rpath I think for 99% of our practical needs on MacPorts, that would more than suffice.

We don't really need to go any further than that.

[kencu (Ken)]

This patch makes ld64-97 not generate an error when it sees an -rpath link command:

$ cat ld64-97-no-error-rpath-tiger.diff
--- src/ld/Options.cpp.orig2	2019-01-29 21:27:48.000000000 -0800
+++ src/ld/Options.cpp	2019-01-29 21:28:43.000000000 -0800
@@ -3503,8 +3503,8 @@
 
 	// can't use -rpath unless targeting 10.5 or later
 	if ( fRPaths.size() > 0 ) {
-		if ( !minOS(ObjectFile::ReaderOptions::k10_5, ObjectFile::ReaderOptions::k2_0) )
-			throw "-rpath can only be used when targeting Mac OS X 10.5 or later";
+//KEN		if ( !minOS(ObjectFile::ReaderOptions::k10_5, ObjectFile::ReaderOptions::k2_0) )
+//KEN			throw "-rpath can only be used when targeting Mac OS X 10.5 or later";
 		switch ( fOutputKind ) {
 			case Options::kDynamicExecutable:
 			case Options::kDynamicLibrary:

and this patch makes ld64-97 just do nothing instead of inserting an rpath command into the executable:

$ cat ld64-97-dont-output-rpath-atom.diff
diff --git src/ld/MachOWriterExecutable.hpp.orig src/ld/MachOWriterExecutable.hpp
index 630328a..ee21fe2 100644
--- src/ld/MachOWriterExecutable.hpp.orig
+++ src/ld/MachOWriterExecutable.hpp
@@ -3142,7 +3142,7 @@ Writer<A>::Writer(const char* path, Options& options, std::vector<ExecutableFile
 	
 	// add any rpath load commands
 	for(std::vector<const char*>::const_iterator it=fOptions.rpaths().begin(); it != fOptions.rpaths().end(); ++it) {
-		fWriterSynthesizedAtoms.push_back(new RPathLoadCommandsAtom<A>(*this, *it));
+//KEN		fWriterSynthesizedAtoms.push_back(new RPathLoadCommandsAtom<A>(*this, *it));
 	}
 	
 	// set up fSlideable

surprisingly, that is enough to get mpv to build and run on Tiger (without doing the proper job of figuring out how to make libtool not output the -rpath argument in the first place, which is turning out to be surprisingly hard).

And it actually runs not too badly; there are some mpv specific issues, but nothing to do with the rpath it seems...

There should be, I think, one more spot to patch; wherever it that @rpath is added as an install_name.... can't seem to find that just yet.

[kencu (Ken)]

simpler idea, maybe: just make a wrapper script for ld that pulls out the -rpath components, if they exist, and pass the rest on to Tiger's ld.

[kencu (Ken)]

I have decided not to fix this at this time. If I have time to come back to this, I may reopen (or just push the fix).