Laurent,��I was reading a little about Eliot's proposed FPU init changes to FFI and then took another look at your evolving Pharo vm source and I was struck by either: (1) a brilliant (well, fairly clever) workaround to my external library hassles; (2) a completely and totally stupid idea.��You have based the vm on the 3.11-3 sources, so it hopefully fixes the double return defect that has been driving me nuts.�� My remaining problem is to get the vm to load external libraries.�� Would a simple plugin to expose dlopen() (and perhaps dlsym() while we're at it) solve the problem?�� I should then be able to bypass the FFI code that calls dlopen() (I suspect that it's pretty badly��broken) by setting the handle of any ailing library by using absolute paths if necessary.�� From there, I *think* everything will just work.��What do you think?
��Somewhat related, have you looked at compiling the Alien plugin?�� The more I look at posts on Alien, the more I wonder whether it will help, as there are suggestions that it is weak on external calls.�� Still, it would be nice to get it going and look over the tests the boldness that comes from watching them pass having actually done something.
��Bill��
From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Linux vm: assertions and strategy
I'm totally noob on FFI. Maybe the vm-dev mailing list is more appropriate ?�� It seems there's actually some problems with it http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=104410&query=ffi
On my machine, 20/21 FFI unit tests fails...
I haven't been able to build last revision of squeak-vm trunk.
Laurent Laffont
On Thu, Apr 8, 2010 at 1:53 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Laurent, all,
If I may jump to conclusions a little, the 3.11-3 vm's changes break the loading of libraries, certainly to the point of being arkane. ��Beyond that, LinuxODBC is transparent to it, so I am left wondering how it is suppose to work at all??
The RC3 one-click image and vm produce very nice fonts on my Ubuntu laptop, but it retains the FFI/double defect, and from the naming of the plugins, must be based on a pre 3.11-3 vm.
Is the plan to use 3.11-3 for the one-click? ��If so, we need to do something about external libraries; at a minimum, LinuxODBC should work, whether by fully understanding how to use environment variables, or (as I suspect) getting the dlopen() call to work again.
Another option is to identify the FPU related fixes and apply them to the current one-click vm.
Any preferences? ��Any success with 3.11-3 and LinuxODBC? ��I'd be happy to be wrong about this.
Bill
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project