[Openmcl-devel] Advice needed to debug shared library problem on Mac and Linux
gb at clozure.com
Tue Mar 29 06:16:15 CDT 2011
Is the library publically available ? Googling found an API reference document,
but I didn't see a link to the library/headers anywhere.
IIRC, "strip" with no options on OSX removes symbols that the dynamic
linker uses. It's The World's Most Advanced Operating System!
It sounds less likely that this is a name conflict, though in thinking about
that it seems clear that we want to be a little more careful about trying to
avoid such conflicts.
Whether the library's freely available or not, what does the C prototype for
the function that you're trying to call look like ? What does the lisp code
that you're using to make that call look like ? Are you just using the CCL
FFI, or a portability package like cffi or uffi ?
On Tue, 29 Mar 2011, Paul Meurer wrote:
> Hi Gary,
>> I'm confused. On the Mac, we don't try too hard to decode memory fault
>> info and so wouldn't say something like:
>> invalid address alignment
>> I think that we used to try to do that until a few versions ago.
> I updated to the newest kernel, and there this line is missing. But everything else is as before.
>>> On Linux, trying to load the library already results in a Kernel memory
>>> allocation failure, it tries to allocate a pointer of size 140332065189888
>>> bytes. I doubt that much memory is really needed.
>> Are you saying that doing:
>> ? (open-shared-library "/path/to/libcfsm.so")
>> causes CCL to think that a very large amount of memory needs to be allocated ?
> No, sorry, I had overlooked one piece of code; loading the library does work. It first crashes when I execute a function from the library, just as on the Mac. Thanks anyway for the explanation of how loading shared libraries works.
>> If I'm correct in interpreting what you said as "things fail in or soon after
>> the call to OPEN-SHARED-LIBRARY", then I'd generally want to try and find and
>> fix the cause of that before worry about anything else; if it's dying because
>> an init routine is calling into the CCL kernel due to a name conflict, it's
>> believable that that could cause a random-looking error on Linux and "just"
>> incorrect initialization of the library on Darwin.
> I had also suspected a name conflict, but couldn't find common symbols in the library and the lisp kernel. Is that the right way to find out?
>>> I can imagine that this is difficult to make sense of.?But maybe you have
>>> some ideas how on could try to debug the problem. It seems like a bug in
>> Yup. Either that, or something else ...
> Of course. It just struck me that the lib works fine in Allegro and SBCL. But a name conflict seems plausible.
> On the other hand, I now tested with a stripped kernel, but things don't change. (On the Mac, the stripped kernel does not load.) Shouldn't a name conflict go away here when there are no names left?
More information about the Openmcl-devel