[Openmcl-devel] Advice needed to debug shared library problem on Mac and Linux

Gary Byers gb at clozure.com
Wed Mar 30 12:52:25 UTC 2011



On Wed, 30 Mar 2011, Paul Meurer wrote:

> Hi Gary,
> 
> thanks a lot. Your suggestion worked. Do you have an idea why stripping the
> symbols wasn't enough?

No.  I imagine that there's some set of options to strip that would
have made it work, but didn't try too hard to find them.

On Linux, the change to the Makefile(s) seems to be enough: it's OK
to have symbols exported from the kernel, but we want a library that
references some symbol to look everywhere else (but the kernel) first.

Having exported symbols in the kernel is useful for debugging; it
allows the kernel debugger to identify a foreign PC value as 'foo+n',
where 'foo' is the nearest preceding (external, IIRC) symbol.

> 
> I first wasn't able to recompile the kernel on Ubuntu 10 (perhaps because it
> has glibc 2.7?), but compiling on CentOS and moving to Ubuntu did the trick.
> The libcfsm needs 2.7.?

I don't know of any problems with compiling the kernel on Ubuntu 10.x,
though a lot of the necessary tools/headers/libraries may not be installed
by default.  (That's especially true of trying to compile a 32-bit kernel
on 64-bit Ubuntu.)

There are sometimes problems with trying to run a kernel (or any other C
application) if the system uses libraries that're significantly older
than the system it was built on.  Up to a point at least, newer systems
tend to support backward compatibility.

>
>       I need significant caffeination before R'ing TFM to see how to
>       avoid that
> on Darwin; I'll get back to you when I've done so.

I couldn't find a way to affect the search order on Darwin, so I
wound up changing the build process so that we only export the one
symbol that we truly need to.  That change is in the SVN trunk; after
it's smoke-tested a bit it or a better solution is probably worth moving
to the release branch as well.




More information about the Openmcl-devel mailing list