On Wednesday 14 Jul 2004 9:21 am, Silvan wrote: > Well hell. It's looking for liblo.so > > ->ls /usr/lib/liblo* > /usr/lib/liblo@ /usr/lib/liblo.0.0.0* [etc] > > ->ldd `which rosegarden`|grep liblo > liblo.0 => /usr/lib/liblo.0 (0x41419000)
That looks like a fuckup in the liblo configuration, specifically its use of libtool. If you look in liblo.la (which is a text file, you can just read it) it specifies a library name of liblo.0 without the .so, and so that's what libtool has built. Rosegarden is getting away with it probably just because it also uses libtool, and so reads the .la file to determine what to link against. Other things built against liblo will sometimes work if they use the static library; checking my own copy of dssi_example_host and friends, it seems that's what's happening for me. I'll ask Steve what's up there. > .so .a .la, I don't really appreciate the difference. Something to > do with static vs. dynamic linking, but I don't know which is for > which .so is your shared object, used for dynamic linking. It's like an incomplete executable, in the same ELF format as actual executables. Linking against one of those gets you the symbols in it resolved at run time. .a is an archive file, used for static linking. It's the traditional Unix library format, and it's nothing more than an aggregation of .o object files. (The program that makes them, ar, is a general archive program somewhat like a more basic version of tar, with a tweak for special handling of symbol tables in object files.) Linking against one of those is a bit like linking against all the object files in it individually: the symbols you need will be picked out and linked in to your executable at link time, and the .a file won't be used at run time at all. .la, in contrast, is a nonsense made-up thing designed for use with the despised libtool. It's just a text file that describes what other files are connected with a particular library. > There's no fluidsynth.h in the *src* directory. That's what it is, > now that I've had a closer look. So installing the -dev package > makes it findable without having to explicitly -I it. Right, we should fix up the Makefile to get fluidsynth.h from the right place without requiring that, then. Chris ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Rosegarden-devel mailing list [EMAIL PROTECTED] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
