Re: mingw install directory for shared lib
On Mon, Jun 30, 2008 at 05:36:48PM -0400, Bob Rossi wrote: 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. Here there been any progress on this issue? Are there any workarounds I could use? Also, if I use AM_LDFLAGS = -no-undefined -module -avoid-version or AM_LDFLAGS = -no-undefined -avoid-version instead of just AM_LDFLAGS = -no-undefined Then the dll doesn't get built at all. Am I doing something silly? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
On Tue, Jul 01, 2008 at 10:32:53AM -0400, Bob Rossi wrote: On Mon, Jun 30, 2008 at 05:36:48PM -0400, Bob Rossi wrote: 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. Here there been any progress on this issue? Are there any workarounds I could use? Also, if I use AM_LDFLAGS = -no-undefined -module -avoid-version or AM_LDFLAGS = -no-undefined -avoid-version instead of just AM_LDFLAGS = -no-undefined Then the dll doesn't get built at all. Am I doing something silly? Sorry to spam, I did see this in the build output, libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries Does that explain why I don't have any dll's in the above case? Thanks, Bob Rossi ___ 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. Here there been any progress on this issue? Are there any workarounds I could use? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
On Tue, Jan 08, 2008 at 11:29:15PM +0200, Tor Lillqvist wrote: 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. I tried this. I never did get it to work. Perhaps I should try libtool CVS? Have any changes been made recently? I could post more details if you suspect this should work. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
On Wed, 9 Jan 2008, 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... Modules should not be linked with an executable. That would surely be bad design and should not be supported. There should be no need to load a module by yourself since libtool offers libltdl which does it for you by requesting to load the associated .la file. Regardless, loading modules directly is trivially easy under Windows. 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... There should be no dependencies between plugins. That would surely be bad design and should not be supported. Libtool should be supporting portable behavior. If the user does not desire to implement portable behavior, then there is little value to using libtool or libltdl. The portable definition for windows should be: library - Executables (usually) link directly with libraries and when the library is a DLL it should be installed in the executable search path, and (ideally) be in the same 'bin' directory as the dependent executables. module - Modules are only loaded via an explicit loading mechanism (e.g. Windows LoadLibrary() or libltdl. Modules may depend on libraries (see above) but should not depend on other modules. Since modules are explicitly loaded, they may be installed in an application-specific lib directory (just like for Unix). 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: mingw install directory for shared lib
On Wed, 9 Jan 2008, Bob Rossi wrote: There should be no dependencies between plugins. I don't know. That sentence goes a little to far really. When pcre is built on windows, it creates two dlls. The first is the regex dll which supports the POSIX regex functionality. The second is a C++ interface to the first library. Therefore, the C++ interface depends on the regex library. Do you think that's bad? You are saying that POSIX regular expressions is implemented as a loadable module? That is odd. Normally one would find such things in a library. Regardless, if care is taken, a module can be used to implement such functionality without linkage dependency. There are problems if linkage dependencies are on a module: 1) If module is not available then program (or subsequent modules) do not run. 2) OS-dependent search/loading procedures are used. 3) Modules need to be loaded in a particular order or else program fails with an ugly run-time error due to an unresolved symbol (e.g. Microsoft Windows dialog box) or otherwise mis-behaves. 4) Module namespace needs to be exported globally (not the libltdl default) so that subsequently-loaded modules may use its symbols. This is not portable and may result in duplicate symbol issues. Such modules can never be safely unloaded again. Where did you get this definition? I don't know, maybe I'm wrong, I don't have a lot of experience in this area. The pcre behavior comes I just made it up. 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: mingw install directory for shared lib
On Tue, Jan 08, 2008 at 11:29:15PM +0200, Tor Lillqvist wrote: 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. I previously had, libfoo_la_LDFLAGS = -no-undefined When I change it to this, libfoo_la_LDFLAGS = -no-undefined -module or this, libfoo_la_LDFLAGS = -no-undefined -module -avoid-version Then the dll doesn't seem to get installed at all. I really don't understand this at all. Any ideas? Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
Bob Friesenhahn mailto:[EMAIL PROTECTED] wrote: On Wed, 9 Jan 2008, 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... Modules should not be linked with an executable. That would surely be bad design and should not be supported. There should be no need to load a module by yourself since libtool offers libltdl which does it for you by requesting to load the associated .la file. Regardless, loading modules directly is trivially easy under Windows. Ok, i agree here. 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... There should be no dependencies between plugins. That would surely be bad design and should not be supported. Libtool should be supporting portable behavior. If the user does not desire to implement portable behavior, then there is little value to using libtool or libltdl. The portable definition for windows should be: library - Executables (usually) link directly with libraries and when the library is a DLL it should be installed in the executable search path, and (ideally) be in the same 'bin' directory as the dependent executables. I wrote some routines to support runpaths on windows, so i install all my libs in the lib directory ;) Also all my executables and libraries built with parity are LD_LIBRARY_PATH aware... So i can use full UNIX like semantics on windows, without any costs (except writing parity before, which of corse costed lots of nerves...) module - Modules are only loaded via an explicit loading mechanism (e.g. Windows LoadLibrary() or libltdl. Modules may depend on libraries (see above) but should not depend on other modules. Since modules are explicitly loaded, they may be installed in an application-specific lib directory (just like for Unix). When thinking of the default windows behaviour, i agree here too. Markus Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- 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
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: 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
