can't use the output of rubyc on an older version of MacOs, because of Dynamic Libraries

[michaelcinquin]

Hi

I use rubyc to pack a ruby script, that uses quite a few gems, some of which have c-code such as Nokogiri.

I use rubyc as so: rubyc myScript.rb -o myBinary

But the output of my rubyc is linked to some Dynamic Libraries : /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation /usr/lib/libSystem.B.dylib /usr/lib/libobjc.A.dylib /usr/lib/libutil.dylib

When I run the binary on an older system, the versions don't match, and the binary crashes:

./myBinary
dyld: lazy symbol binding failed: Symbol not found: _syslog$DARWIN_EXTSN
  Referenced from: myBinary (which was built for Mac OS X 10.13)
  Expected in: /usr/lib/libSystem.B.dylib
Abort trap: 6

If I study the binary output by rubyc with otool, the versions mismatch are apparent:

otool -L myBinary 
myBinary:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1445.12.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)

Is there a way to use a rubyc output binary on an older system?

(could we use --make-args or something to force the use of static libraries?)

thanks !

[michaelcinquin]

I should have mentioned more info. I try to use rubyc on a 10.14 Mojave system. I would like the binaries to be usable on a 10.12 Sierra sytem.

I have tried every flavour of Xcode. The oldest Xcode that runs on 10.14 is Xcode 9 ; it allows rubyc to compile, but the SDK that Xcode 9 carries is for 10.13 ; so I tried to replace the SDK (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/) with the one of Xcode 8, which is MacOSX10.12.sdk, then it compiles successfully but still the Dylib versions problem mentioned above remain.

[pmq20]

@michaelcinquin Hi Michael, thanks for reporting the issue. An essentially similar issue that was once mentioned by @bkmgit was recorded here: https://github.com/pmq20/ruby-packer/issues/109

I have been aware of the problem for some time. The solution is very apparent to me: we should build the binaries on a machine that is as old as possible (apart from making the runtime dynamic lib dependencies as few as possible), so that it can run on a wider range of platforms because of runtime-lib compatibilities. Currently the binaries in the README were built by Github Action runners, which are definitely too new, i.e. ubuntu-20.04, macos-10.15 and windows-2019.

I plan to switch to the oldest runners available on Github Action soon, i.e. ubuntu-16.04 and windows-2016. That should be able to solve the problems on Linux and Windows. However, Github Actions does not seem to provide old enough platforms for macOS. For that, I plan to use Travis CI beacuse they seem to provide runners for macOS 10.11 (osx_image: xcode7.3).

There will be some fine-tuning needed after switching those CI runner platforms. Due to weekday work, I have to work on it during my next weekend. Pull requests are also greatly welcome!

[michaelcinquin]

Thanks for the feedback ! Though I'm not sure it's a problem with the version of rubyc binary: I've been using the very same binary :

• to pack from MacOs 10.12 ; the packed binary works with all versions > 10.12
• to pack from MacOS 10.14 : the packed binary works only with versions > 10.14

I hope it's workable ;-)

On 2 Sep 2020, at 01:27, Minqi Pan [email protected] wrote:

@michaelcinquin https://github.com/michaelcinquin Hi Michael, thanks for reporting the issue. An essentially similar issue that was once mentioned by @bkmgit https://github.com/bkmgit was recorded here: #109 https://github.com/pmq20/ruby-packer/issues/109 I have been aware of the problem for some time. The solution is very apparent to me: we should build the binaries on a machine that is as old as possible (apart from making the runtime dynamic lib dependencies as few as possible), so that it can run on a wider range of platforms because of runtime-lib compatibilities. Currently the binaries in the README were built by Github Action runners, which are definitely too new, i.e. ubuntu-20.04, macos-10.15 and windows-2019.

I plan to switch to the oldest runners available on Github Action soon, i.e. ubuntu-16.04 and windows-2016. That should be able to solve the problems on Linux and Windows. However, Github Actions does not seem to provide old enough platforms for macOS. For that, I plan to use Travis CI beacuse they seem to provide runners for macOS 10.11 (osx_image: xcode7.3).

There will be some tuning after switching those CI runner platforms. Due to work I have to work on it during my next weekend.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pmq20/ruby-packer/issues/128#issuecomment-685185810, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZM7VMAVTNRCYCIGAJC7HTSDV7MPANCNFSM4QSDFWVQ.

[paneq]

@pmq20 Would you accept a PR changing to build on older Ubuntu? I commented on https://github.com/pmq20/ruby-packer/commit/08059fc198308531cbbac62594972e21dda11fe3 what could have failed there potentially.

[ahoward]

@pmq20 i have hit the same issue i think ( https://github.com/pmq20/ruby-packer/issues/143 ) and looked at the build strategy for traveling-ruby which, i'm sure, you are aware of.

it sure would be super duper awesome and amazing if you combined forced with @FooBarWidget to extract the holy build box strategy they've developed, since it would seem that tying to github actions is always going to float versions up and be difficult to perfectly control. but i may be wrong, just thinking out loud and confirming this is a real issue.

finally, ruby-packer is awesome and i really am looking forward to releasing some new code via the project. thanks!

[FooBarWidget]

I recently refreshed Holy Build Box and fixed a lot of issues. I think that's the easiest way to build portable binaries for Linux.

[FooBarWidget]

As for macOS, you actually don't need to build on an older macOS. You do however need two things:

1. An older macOS SDK.
2. Setting MACOSX_DEPLOYMENT_TARGET to some appropriate version.

[michaelcinquin]

As for macOS, you actually don't need to build on an older macOS. You do however need two things:

1. An older macOS SDK.
2. Setting MACOSX_DEPLOYMENT_TARGET to some appropriate version.

Thank you so much! This is exactly the answer I needed, it works perfect!

And this page is today the only one in the world containing the words "enclose.io" and "MACOSX_DEPLOYMENT_TARGET" ;-) https://www.google.com/search?client=safari&rls=en&q=%22enclose.io%22+%22MACOSX_DEPLOYMENT_TARGET%22&ie=UTF-8&oe=UTF-8