[Openmcl-devel] CCL64 fails to load cl-plplot

[Gary Byers]

If NAME is a string that names "libosicat.dylib" (however it's named when
OPEN-SHARED-LIBRARY reports an error), does:

(with-cstrs ((cname NAME))
   (#_dlopen cname (logior #$RTLD_GLOBAL #$RTLD_NOW)))

return a null pointer (failure) or a non-null pointer (success) ?

If dlopen succeeds where OPEN-SHARED-LIBRARY fails, that would suggest
that the fact that OPEN-SHARED-LIBRARY arranges to call #_dlopen on the
initial thread somehow affects this.  (I don't know how it would, but if
there's evidence that it does, that doesn't matter too much.)

If #_dlopen fails ... there can be lots of reasons for that, many of them
having to do with whether the names of the library and libraries it depends
on are absolute or relative and on things like the LD_LIBRARY_PATH and
DYLD_LIBRARY_PATH environment variables.

I don't want to say "and CCL doesn't directly affect any of this"; a
(possibly unrelated bug) could of course affect anything.  I do want
to say "CCL doesn't directly open shared libraries; it calls dlopen()
or similar Windows-specific functions", and aside from passing
arguments to those functions and interpreting their results, it isn't
too involved in the mechanics of shared-library opening.

On Fri, 10 Sep 2010, Raffael Cavallaro wrote:

>
> On Sep 10, 2010, at 8:46 PM, Gary Byers wrote:
>
>> I suspect that that'll tell you that that dylib is 32-bit only.
>
> I actually ran into a similar problem with osicat's libosicat.dylib the other day.
>
> file says it's a "Mach-O 64-bit bundle x86_64" but Clozure CL64 won't load it.
>
> warmest regards,
>
> Ralph
>
>
> Raffael Cavallaro
> raffaelcavallaro at me.com
>
>
>
>
>
>