Re: dll names on windows

2007-05-01 Thread Ralf Wildenhues
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

2007-05-01 Thread Bob Rossi
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

2007-04-29 Thread Bob Rossi
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

2007-04-19 Thread Bob Rossi
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

2007-04-14 Thread Max Bowsher
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

2007-04-12 Thread Bob Rossi
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