Laurent,
A part-time boss/full-time friend once advised me to "get the
machine to tell you what it's doing" (I was doing just that at the time, but
I've never forgotten his advise<g>).
I compiled your vm and then decided to stick some tracing code
in strategic places to find what the vm thinks it is doing in trying to load
unixODBC. Get ready:
tryLoading(/sr/local/slib/squeak/3.11.13-/so.libodbc.so) =
(nil)
In short, it does not appear to recognize a difference between
plugins (the names of which it twists around to avoid collisions with external
libraries - that's fine) and external libraries that have been minding their own
business for many clock cycles. The latter deserve special
attention.
So I had an absolutely nutty idea: give dlopen() the name of
the library as written :) Clearly, that works only if one provides an
absolute path in #moduleName, but (forgive/correct possible *nix-noob syndrome
here) that is easy to test and even easier to do in the
code.
So, in sqUnixExternalPrims.c in the unix/vm directory, look
near the end of tryLoadModule(). My proposed workaround is to add some
code before the !handle test at the end. I will send a cut-down version of
it in a separate email. Unless someone has a better idea, I suggest we
make this change to you source to give people an opportunity to use external
libraries: (1) I fear at all(!!); (2) by absolute path if
desired.
BTW, the 3.11-3 vm indeed appears to have fixed my problem w/
double return values, at least the boiled-down test
works.
Bill
2010/4/8 Schwab,Wilhelm K
<bschwab@anest.ufl.edu>
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?
Well, I'm noob on VM stuff, I've just worked on how to generate VM source
for Linux, that's all :) So I cannot tell anything...I have to learn
before.
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.
Yes I can compile it, but the VM crashes loudly when trying to use it.
This thread has a lot of informations:
Laurent Laffont
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=ffiOn
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