@mflatt I assume you noticed the current DrDr failure — is there a change that would make it stop failing to run all the other tests?

No, I forgot to check after recent changes. I’ll fix the compiler warnings(?) when I can this afternoon

@mflatt I’m having a weird issue in which Racket installed on Ubuntu can’t load a .so put in its lib directory via ffi-lib, complaining it doesn’t even exist: root@d82c5e3ffd27:/# ls /racket/lib/libMagick* /racket/lib/libMagickCore-7.Q16HDRI.so /racket/lib/libMagickWand-7.Q16HDRI.so root@d82c5e3ffd27:/# racket -e '(require ffi/unsafe) (ffi-lib "libMagickWand-7.Q16HDRI")' ffi-lib: couldn't open "libMagickWand-7.Q16HDRI.so" (libMagickWand-7.Q16HDRI.so: cannot open shared object file: No such file or directory) However, if I set LD_LIBRARY_PATH to /racket/lib, then ffi-lib loads it correctly, so somehow the OS can find it, but Racket can’t. Do you know how I could debug this?

It sounds like that shared object depends on others that are on only found if you set LD_LIBRARY_PATH

Wand needs Core?

That seems likely, yes. What is the proper way to express that dependency to Racket?

I forget how it goes on Linux, but does loading Core first help?

Hmm, let me see.

@mflatt Annoyingly, Core depends on symbols in Wand, so loading it first produces an undefined symbol error. However, that still only happens with LD_LIBRARY_PATH set… doing it without it set still fails with libMagickCore-7.Q16HDRI.so: cannot open shared object file: No such file or directory.

What does ldd say for the two ".so"s?

The ldd output makes sense, but the undefined symbol error doesn’t make sense to me. So, I don’t understand why libMagickCore doesn’t load, either.

Well, to be clear, I get the undefined symbol error if I do this: ~ $ LD_LIBRARY_PATH=/app/racket/lib racket -e '(require ffi/unsafe) (ffi-lib "libMagickCore-7.Q16HDRI")' ffi-lib: couldn't open "libMagickCore-7.Q16HDRI.so" (/app/racket/lib/libMagickCore-7.Q16HDRI.so: undefined symbol: DrawPathStart) since apparently libMagickCore uses symbols from libMagickWand for whatever reason.

That makes sense to me. What I don’t understand is why omitting LD_LIBRARY_PATH causes that to fail with a different error, namely No such file or directory.

Oh, maybe the issue is the dependencies on other libraries (like freetype) that have different builds in “lib”

Or does Core use dlopen to implement mutual dependencies?

(But I don’t see how that would fail at load time.)

Right… both those things don’t seem to reflect the error message I’m seeing, which is ffi-lib: couldn't open "libMagickCore-7.Q16HDRI.so" (libMagickCore-7.Q16HDRI.so: cannot open shared object file: No such file or directory)

…which seems to indicate to me that for some reason Racket can’t find the .so at all. But I don’t know how that could be possible.

I suppose I’m not going to be able to guess the problem at this point. I can tell you that the recipe for success has been to (1) make sure all the relevant libraries are built together (really: make sure the load-time library is compatible with the build-time one); (2) adjust the dependencies to have no path, so that the right library really will be used at load time; and (3) load libraries that are dependencies before the libraries that depend on them. As far as I know, shared libraries cannot have direct mutual dependencies, so that’s why step 3 has seemed well-defined.

Alright, I’ll keep fiddling with knobs. ImageMagick is very complicated… and I’m still not sure I’m configuring it properly when I build it.

@mflatt FWIW, I managed to get ImageMagick to build in such a way that libMagickCore stopped referencing symbols in libMagickWand, and that plus your suggestion of explicitly loading Core before Wand seems to have solved the problem. Thanks!

The error message when I load Wand without first loading Core is still perplexing… but I am willing to be happy with this now that it works. :)