legacysupport does not relink libSystem.B.dylib to libMacportsLegacySystem.B.dylib

[barracuda156]

It looks like legacysupport is supposed to relink libSystem to its own wrapper:

proc legacysupport::relink_libSystem { exe } {
    global os.major prefix
    if { ${os.major} <= [option legacysupport.newest_darwin_requires_legacy] } {
        set         sLib /usr/lib/libSystem.B.dylib
        set         lLib ${prefix}/lib/libMacportsLegacySystem.B.dylib
        ui_debug "legacysupport: Relinking ${exe} against ${lLib}"
        system "install_name_tool -change ${sLib} ${lLib} ${exe}"
    }
}

However in practice it does not do that.

For example, I build fastfetch, which sets legacysupport.newest_darwin_requires_legacy 15, on 10.6. And here is what it gets linked to:

36-87% otool -L /opt/local/bin/fastfetch-orig
/opt/local/bin/fastfetch-orig:
	/opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.3.99)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 14.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 511.1.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/PrivateFrameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
	/System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 246.0.0)
	/System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 988.3.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 36.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 711.1.0)

There is no libMacportsLegacySystem.B.dylib, but there is libSystem.B.dylib.

[barracuda156]

Also, shouldn't it be an optional thing, not just forced, even conditionally?

[jmroot (Joshua Root)]

Isn't it optional by allowing the proc to be called when needed? And doesn't R, which you maintain, do exactly this?

[fhgwright (Fred Wright)]

I haven't looked at the PortGroup, which is presumably the issue here, not the port (though unfortunately there's no Trac component for PortGroups), but indeed this behavior is supposed to be optional. Most ports simply add the include and library paths, and link against libMacportsLegacySupport.dylib as an additional library, not a replacement library.

Usually, the only time libMacportsLegacySystem.B.dylib is needed is when applying it to binary-only programs, such as the precompiled rustc.

[barracuda156]

Normally portgroups provide options for such cases, which does not seem to be the case here. I would rather see it as a non-default option, of course.

[kencu (Ken)]

There is nothing to fix here.

if you want to relink the binary against the modified libSystem, do something like this in the destroot phase:

legacysupport::relink_libSystem ${destroot}${prefix}/bin/${name}

[kencu (Ken)]

closing, as this works as expected