Alien & Squeak FFI issues on Snow Leopard.

> Someone finally managed to fire up a Sophie app http://www.opensophie.org/
>  on Snow Leopard and immediately found an issue that also affects
> Squeak users who do fascinating things with FFI
> The innocent FFI call was
>
> apifstat: afileNo statBuffer: buffer
>        <cdecl: long 'fstat' (long MacStat* ) module: 'libc.dylib'>
>        ^self externalCallFailed
>
> Now it seems BEFORE Snow Leopard *somehow* the Squeak external
> primitive call api which is part of the VM to assist in loading
> plugins or finding function entry points in executable binaries or
> libraries would
> return the entry point for fstat by *somehow* finding libc.dylib which
> is via  /usr/lib/libc.dylib -> libSystem.dylib ->  libSystem.B.dylib
>
> Interestingly this is found implicitly since the mac carbon vm lookup
> logic never looks in /usr/lib/
>
> Now in Snow Leopard it seems they do less implicit searching, perhaps
> a security concern?  Then it fails.
>
> In the past the Unix VM would search a hundred(sic) more places, but I
> understand less today, but it might still work? Maybe /usr/lib is in
> the hit list?
>
> This issue also applies to Alien because it calls back to the VM for
> it to find the module and function entry point.
>
> Since I have received a request to ensure that doing an explicit full
> path should be allowed in the squeak carbon macintosh vm.
> Then a change would be:
>
> apifstat: afileNo statBuffer: buffer
>        <cdecl: long 'fstat' (long MacStat* ) module: '/usr/lib/libc.dylib'>
>        ^self externalCallFailed
>
> I'll look at doing this shortly.
>
> However the workaround is to go to Sophie.app/Contents/Resources
> and do a ln -s /usr/lib/libc.dylib libc.dylib
> to create a symbolic link in the Resources directory for libc.dylib
> since we do explicitly look for libc.dylib in the Resources directory.
>
> Obviously if you have a FFI call like above where you are calling a
> system library Oracle? for example.
> You might find it no longer works with Snow Leopard on the Macintosh,
> so you should check.
>
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Craig Latta found a simple work-around which is to set the VM's  
> Info.plist variable "SqueakPluginsBuiltInOrLocalOnly" to false, so  
> that libraries are found on Snow Leopard.  Up until now things have  
> been being found through vagaries if the Mac OS X dlopen call which  
> would, I think, search the paths in an executable used to find  
> dlls.  i.e. prior to Snow Leopard if you tried to run something in  
> libSystem.B.dylib and you traced the logic in  
> sqMacUnixExternalPrims.c you'd find that dlopen was "finding"  
> libSystem.B.dylib in VM.app/Contents/Resources, even though it is  
> not there.
>
> Personally I think that sqMacUnixExternalPrims.c is ripe for a  
> rewrite.  It is torturously complex.  But Craig's workaround works  
> for us and takes the pressure off.
>
> P.S.  I'm not on the Pharo list.  Can someone forward this for me?