Re: dll names on windows
On Tue, May 01, 2007 at 10:04:12AM +0200, Ralf Wildenhues wrote: > Hello Bob, Max, all, > > * Bob Rossi wrote on Mon, Apr 30, 2007 at 12:26:25AM CEST: > > On Thu, Apr 19, 2007 at 05:12:49PM -0400, Bob Rossi wrote: > > > > > > Is there any way that I can have libtool simply create a dll with the > > > new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code > > > into the Makefile some commands to provide the user with what they want. > > I think you may be able to hack^Wworkaround like this: > lib_LTLIBRARIES = pcre.la > pcre_la_SOURCES = ... > pcre_la_LDFLAGS = -module Brain Dessent said I could try the '-avoid-version' switch. It seems to work. Does that sound good to you? > Another possibility is to manually copy the file after installation. Hmm, I hadn't even thought of that. I wasn't sure if copying dll's worked. That is, I thought maybe the name of the dll was embedded in it somehow. > > Ping. Maybe this is a stupid question. I'm not really knowledgeable > > enough to know if what I'm asking for doesn't even make sense. I'd like > > to at least find out if it's a reasonable question that I'm asking. :) > > Sorry for the delay. Nonsense! Thanks for the help! Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dll names on windows
Hello Bob, Max, all, * Bob Rossi wrote on Mon, Apr 30, 2007 at 12:26:25AM CEST: > On Thu, Apr 19, 2007 at 05:12:49PM -0400, Bob Rossi wrote: > > > > Is there any way that I can have libtool simply create a dll with the > > new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code > > into the Makefile some commands to provide the user with what they want. I think you may be able to hack^Wworkaround like this: lib_LTLIBRARIES = pcre.la pcre_la_SOURCES = ... pcre_la_LDFLAGS = -module Note though that it's somewhat of a hack, and that I'm not sure whether it was intended to be (ab)used this way, so maybe I should not recommend it. Note also that you cannot build pcre.la and libpcre.la in the same directory, for namespace collision issues. Another possibility is to manually copy the file after installation. > Ping. Maybe this is a stupid question. I'm not really knowledgeable > enough to know if what I'm asking for doesn't even make sense. I'd like > to at least find out if it's a reasonable question that I'm asking. :) Yes, the question is reasonable. Sorry for the delay. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dll names on windows
On Thu, Apr 19, 2007 at 05:12:49PM -0400, Bob Rossi wrote: > On Sat, Apr 14, 2007 at 11:23:20PM +0100, Max Bowsher wrote: > > Bob Rossi wrote: > > > I've recently converted pcre's (http://www.pcre.org/) build > > > system to use the autotools. > > > > > > The previous stable version of libtool, pcre-7.0, used to create dll's > > > on mingw. It would create > > > $ ls .libs/*.dll > > > > > > .libs/pcre.dll .libs/pcreposix.dll > > > > > > > > > Now, the new autotools version creates, > > > $ ls ../../pcre-7.1-RC4/prefix-shared/bin > > > > > > libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config > > So, now pcre uses the names directly above, which is the default > behavior. However, the pcre project would like to provide a backwards > compatible dll the user can use if they enable the configure switch > --enable-alt-win-dll (or something like that). > > Is there any way that I can have libtool simply create a dll with the > new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code > into the Makefile some commands to provide the user with what they want. Above I meant to say 'with the name 'pcre.dll'. Ping. Maybe this is a stupid question. I'm not really knowledgeable enough to know if what I'm asking for doesn't even make sense. I'd like to at least find out if it's a reasonable question that I'm asking. :) Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dll names on windows
On Sat, Apr 14, 2007 at 11:23:20PM +0100, Max Bowsher wrote: > Bob Rossi wrote: > > I've recently converted pcre's (http://www.pcre.org/) build > > system to use the autotools. > > > > The previous stable version of libtool, pcre-7.0, used to create dll's > > on mingw. It would create > > $ ls .libs/*.dll > > > > .libs/pcre.dll .libs/pcreposix.dll > > > > > > Now, the new autotools version creates, > > $ ls ../../pcre-7.1-RC4/prefix-shared/bin > > > > libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config So, now pcre uses the names directly above, which is the default behavior. However, the pcre project would like to provide a backwards compatible dll the user can use if they enable the configure switch --enable-alt-win-dll (or something like that). Is there any way that I can have libtool simply create a dll with the new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code into the Makefile some commands to provide the user with what they want. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dll names on windows
Bob Rossi wrote: > I've recently converted pcre's (http://www.pcre.org/) build > system to use the autotools. > > The previous stable version of libtool, pcre-7.0, used to create dll's > on mingw. It would create > $ ls .libs/*.dll > > .libs/pcre.dll .libs/pcreposix.dll > > > Now, the new autotools version creates, > $ ls ../../pcre-7.1-RC4/prefix-shared/bin > > libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config ... > A user has complained that the new filename change, on windows, will > effect the way they have to load pcre as a plugin. They said that on > windows it's common to always name the dll simply pcre.dll and then > provide a coff file, which is metadata describing the version number > and characteristics of the dll. > > My question is, what's the correct way to name these dll's on windows? > What would be an appropriate response to this user? AFAIK, the coff file is purely informational, and not involved in any way with the actual linking/loading - unlike the filename, which is clearly important here. The reason for placing the number into the name is to make it possible for multiple incompatible versions of a DLL to be present on a system without colliding - the aptly named "DLL Hell". I'd tend to assume that the only way that this will affect your user is that they will have to specify the new name - which ought to be pretty trivial. Perhaps you'd like to nudge them for clarification on why they think this is a difficulty? Numbering of DLLs in this way is perhaps a bit rare on Windows in general, but hardly unknown. A prime example is: msxml.dll msxml2.dll msxml3.dll msxml4.dll > Finally, here is the version numbering in configure.ac, > m4_define(libpcre_version, [0:1:0]) > m4_define(libpcreposix_version, [0:0:0]) > m4_define(libpcrecpp_version, [0:0:0]) > not sure if that's good or not. Those numbers mean: libpcreposix and libpcrecpp: this is the first release since versioning began. libpcre: this is the second release since versioning began, but the ABI is unchanged since the first release. Max. signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
dll names on windows
Hi, I'm mostly new to libtool, so please be patient if I'm misinformed. I've recently converted pcre's (http://www.pcre.org/) build system to use the autotools. The previous stable version of libtool, pcre-7.0, used to create dll's on mingw. It would create $ ls .libs/*.dll .libs/pcre.dll .libs/pcreposix.dll Now, the new autotools version creates, $ ls ../../pcre-7.1-RC4/prefix-shared/bin libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config I mostly know on unix how this works. This is just a rough overview of how I think things could work, please correct me if I'm wrong. Typically there is a major and minor number. The major number is bumped on incompatible version changes, and the minor number is bumped on compatible version changes. Finally there is a symlink that provides just the name of the .a or .so, with only the major version number. A user has complained that the new filename change, on windows, will effect the way they have to load pcre as a plugin. They said that on windows it's common to always name the dll simply pcre.dll and then provide a coff file, which is metadata describing the version number and characteristics of the dll. My question is, what's the correct way to name these dll's on windows? What would be an appropriate response to this user? Finally, here is the version numbering in configure.ac, m4_define(libpcre_version, [0:1:0]) m4_define(libpcreposix_version, [0:0:0]) m4_define(libpcrecpp_version, [0:0:0]) not sure if that's good or not. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
