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?

On Wed, Sep 30, 2009 at 12:52 AM, Andrey Larionov <anlarionov at gmail.com>wrote:

> I think it's related
> http://forums.newspeaklanguage.org/index.php?topic=88.0
>
> On Wed, Sep 30, 2009 at 06:13, John M McIntosh
> <johnmci at smalltalkconsulting.com> wrote:
> > 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 <johnmci at smalltalkconsulting.com>   Twitter:
> > squeaker68882
> > Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> > =
> > =
> > =
> > ========================================================================
> >
> >
> >
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090930/3dd0aba0/attachment.htm