[vlc-devel] [vlc-commits] fixups.h: added an explicit hack so binaries created on OS X Lion can be executed correctly on Snow Leopard

[Rafaël Carré]

Le 2012-01-27 09:53, Felix Paul Kühne a écrit :
> Hi there,
> 
> On 27.01.2012, at 14:46, Rafaël Carré wrote:
> 
>> - use 10.7 features
>> => you must check what Apple suggests and I believe it is:
>> * weak imports, and runtime checks that imported function do exist
>> * copy/paste 10.7 headers since we build against 10.5 headers
> 
> * weak imports are correct and this is what I do in the macosx-specific Objective-C code.
> * copy/paste 10.7 headers is no correct way of doing things. However, we are doing something similar in modules/gui/macosx/CompatibilityFixes.h.
> 
> The main problem I'm confronted with however, is that we need to link the macosx interface module against the 10.7 runtime to achieve proper results for the window resizing mask.
> This is a well-documented limitation of the 10.7 SDK.
> Even if you perform the same function calls, an app linked against the
10.6 SDK won't give the same results.

I find that hard to believe, where is it documented?

> However, using -minimal-macosx-version, a binary linked against the 10.7 SDK still runs on 10.6.
> _getline is defined in the 10.7 SDK, but isn't for 10.6.
> Enforcing the compilation of the libcompat replacement results in a
working binary, be it accidentally or on purpose.
> After further tests, I agree that my former approach of using
__APPLE__ checks is absolutely wrong, while enforcing AC_LIBOBJ is
sufficient.
> Previous tests have shown, that resulting binaries perform absolutely
correctly on both OS X releases.

Not sure what Apple says about miminal-macosx-version but the point is:
if you don't link only to 10.5 : it may work, unless it doesn't, then
you have to add an exception for getline, then another etc..

> If you dislike this approach so much that you don't want to tolerate it for the Mac port, I'll have to do the 64bit binaries for 10.7 only, 

You're the one responsible for the OSX binaries aren't you?

> which would be acceptable, but is still kind of a pity since 64bit
code on 10.6 has proven to run correctly and even slightly faster than
its 32bit counter-part.

Not sure why it's specific to 64 bits