On Tue, Jan 08, 2008 at 09:53:24PM +0100, Ralf Wildenhues wrote: > Hello Bob, > > * Bob Rossi wrote on Tue, Jan 08, 2008 at 08:18:56PM CET: > > > > plugindir = $(libdir)/plugins > > plugin_LTLIBRARIES = > > plugin_LTLIBRARIES += libfoo.la > > libfoo_la_SOURCES = foo.cc > > libfoo_la_LDFLAGS = "-no-undefined" > > > > Now when I do 'make install' with --prefix=install I see this, > > on linux, I get install/lib/plugins/libfoo.so > > on windows, I get install/lib/bin/libfoo-0.dll > > > > Any idea why the dll isn't going into the plugins dir and why > > it is going into lib/bin? > > I'd say that's a bug. Thanks for the report. > > It comes from the normal libdir libraries going into $libdir but the > DLL into $libdir/../bin so that they are found automatically by the > programs that are in $bindir. Obviously there are a few assumptions > present here, namely that bindir is libdir/../bin, and that you don't > do such reasonable things as above. ;-) > > General question before fixing this: on w32, should even plugins have > their DLLs go to $bindir?
I don't know. I can tell you that I'm successfully loading a plugin that is not in the $bindir using apr (apache portable runtime). I don't think that apr modifies the PATH or anything like that to get this to work. Bob Rossi _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
