mingw install directory for shared lib
Hi, I have something like this, plugindir = $(libdir)/plugins plugin_LTLIBRARIES = and 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? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
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? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
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
Re: mingw install directory for shared lib
Shouldn't plug-in -type shared libraries be built with the -module -avoid-version libtool flags? I think with those flags, such libtool-built DLLs get installed in the libdir of the Makefile in question, not libdir/../bin like normal DLLs. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
On Tue, 8 Jan 2008, Ralf Wildenhues wrote: General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Plugin modules should be installed adjacent to the .la files in the directory the user specifies since the plugin module should be loaded directly without need to consult the PATH. Of course the .la file needs to correctly reference the location of the plugin module. Only general-purpose DLLs need to be installed in the executable search path. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ld --rpath problem using libtool
Hi Ralf, Attached are the two logs that you have requested. I hope this helps you further. At least my assumption that libtool should get a library's path information from libx.la is not wrong. ;) Sorry for sending the logs unzipped previously. Many thanks for your help. - Richard config.log.gz Description: GNU Zip compressed data relink.log.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ld --rpath problem using libtool
Hello Richard, * Richard Hacker wrote on Wed, Jan 09, 2008 at 07:40:57AM CET: > > Attached are the two logs that you have requested. I hope this helps you > further. At least my assumption that libtool should get a library's path > information from libx.la is not wrong. ;) > > Sorry for sending the logs unzipped previously. Thanks for the resend. I think the issue is this: libtool doesn't add a run path to /opt/etherlab/lib because it thinks the runtime linker will already search that by default. Your --config output shows that it is listed as such: | # Run-time system search path for libraries | sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/X11R6/lib/Xaw3d /usr/X11R6/lib /usr/lib/Xaw3d /usr/i386-suse-linux/lib /usr/local/lib /opt/kde3/lib /opt/gnome/lib /opt/etherlab/lib " This typically happens on GNU/Linux if the path is listed in /etc/ld.so.conf* (the Libtool configure macros try to parse that). I'm wondering, if it's listed there (could you please confirm that?), why doesn't the runtime linker find it then in your case? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
Bob Friesenhahn <> wrote: > On Tue, 8 Jan 2008, Ralf Wildenhues wrote: >> >> General question before fixing this: on w32, should even plugins have >> their DLLs go to $bindir? Yes, i'd agree to this... ;o) If you try to load a library by yourself, you will have to know what you're doing. If the DLL is linked to the executable, you have no (easy) way to influence what is done by the loader... Of course there may still be problems if there are dependencies between plugins, that are installed in different directories, since loading one plugin will load all libraries this dll is linked to. If those are plugins themselves, they will have to be in PATH to be found (or in the same directory, etc.). The easiest solution is using parity ;) but thats self-advertisement again, sorry... Cheers, Markus > > Plugin modules should be installed adjacent to the .la files in the > directory the user specifies since the plugin module should be loaded > directly without need to consult the PATH. Of course the .la file > needs to correctly reference the location of the plugin module. Only > general-purpose DLLs need to be installed in the executable search > path. > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED], > http://www.simplesystems.org/users/bfriesen/ GraphicsMagick > Maintainer,http://www.GraphicsMagick.org/ > > > > ___ > http://lists.gnu.org/mailman/listinfo/libtool -- 19. - 21. Februar 2008 Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland Halle 6, Stand 527 23. - 27. Februar 2008 MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland Halle 6, Stand C50 Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
Hm, sorry, as i reread my mail, i realized that the text is in the wrong position ;) of course my comment is targeted ar bob's text, not ralf's question... Duft Markus <> wrote: > Bob Friesenhahn <> wrote: >> On Tue, 8 Jan 2008, Ralf Wildenhues wrote: >>> >>> General question before fixing this: on w32, should even plugins >>> have their DLLs go to $bindir? > > Yes, i'd agree to this... ;o) If you try to load a library by > yourself, you will have to know what you're doing. If the DLL is > linked to the executable, you have no (easy) way to influence what is > done by the loader... > > Of course there may still be problems if there are dependencies > between plugins, that are installed in different directories, since > loading one plugin will load all libraries this dll is linked to. If > those are plugins themselves, they will have to be in PATH to be > found (or in the same directory, etc.). The easiest solution is using > parity ;) but thats self-advertisement again, sorry... > > Cheers, Markus > >> >> Plugin modules should be installed adjacent to the .la files in the >> directory the user specifies since the plugin module should be loaded >> directly without need to consult the PATH. Of course the .la file >> needs to correctly reference the location of the plugin module. Only >> general-purpose DLLs need to be installed in the executable search >> path. >> >> Bob >> == >> Bob Friesenhahn >> [EMAIL PROTECTED], >> http://www.simplesystems.org/users/bfriesen/ GraphicsMagick >> Maintainer,http://www.GraphicsMagick.org/ >> >> >> >> ___ >> http://lists.gnu.org/mailman/listinfo/libtool -- 19. - 21. Februar 2008 Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland Halle 6, Stand 527 23. - 27. Februar 2008 MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland Halle 6, Stand C50 Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz ___ http://lists.gnu.org/mailman/listinfo/libtool
