On 8/8/03 16:07, in article 40D44152-C9E4-11D7-809C-003065CCCEE6@...,
"Raffael Cavallaro" <raffaelcavallaro@...> wrote:
> On Friday, August 8, 2003, at 12:03 PM, Christophe Rhodes wrote:
>> You probably do need to rebuild test.so, don't you?
> Yes, of course, I have been doing that, every time. In other words,
> each time I try a new test, I rebuild both test.so and test.fasl from
> their respective c and lisp sources.
> More to the point, however, is the fact that sbcl is still linking to
> libdl.1.dylib, which is the wrong version.
> otool -L /usr/local/bin/sbcl
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 63.0.0)
> /usr/local/lib/libdl.1.dylib (compatibility version 1.0.0,
> current version 1.0.0)
> Since it's using the wrong version, it keeps returning an error because
> the foreign symbols all have an underscore prepended to them, which is
> the wrong behavior as far as sbcl is concerned.
> Is there any way to _force_ sbcl to use libdl.0.dylib. I've tried
> setting DYLD_LIBRARY_PATH. I've tried removing libdl.1.dylib
> altogether. I've tried renaming libdl.0.dylib to libdl.1.dylib, but
> this results in a version error (the compatibility_version and
> current_version numbers don't match, so one can't be substituted for
> the other).
> In other words, sbcl seems to have been linked in such a way that is
> will only accept libdl.1.dylib as the one true libdl. This is why I
> asked if I need to rebuild sbcl. I still have all the intermediate
> build products (assuming that make.sh doesn't do any cleanup - that's
> what clean.sh is for, right) Is there something I could change in a
> makefile (or make.sh) that would force the built binary to use
> libdl.0.dylib as it should?
Hm, you can just rebuild the runtime in this case. All of the symbols should
stay at the same location. To do this, go into your src/runtime directory
mv sbcl sbcl.bak
mv sbcl.nm sbcl.nm.foo
And then use that sbcl runtime. All should be well then.