Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Marco atzeri
On 6/17/2011 2:10 AM, Bob Friesenhahn wrote: On Fri, 17 Jun 2011, Vadim Zeitlin wrote: Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just too accustomed to the "traditional" Windows way and have trouble accepting auto-import magic. It's true that projects using auto-impor

Re: Shared library versioning

2011-06-17 Thread Lasse Collin
On 2011-06-17 Charles Wilson wrote: > On 6/16/2011 2:50 PM, Lasse Collin wrote: > > Major:minor:revision is easier to understand than > > current:revision:age, > > Major:minor:revision artificially entangles package release numbering > with API/ABI changes. Typically when one 'goes up' so does th

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Peter Rosin
Den 2011-06-17 01:15 skrev Bob Friesenhahn: > On Thu, 16 Jun 2011, Vadim Zeitlin wrote: >> BF> >> BF> In what way was libtool specifically requested to build a DLL? >> >> I'm not sure about the details (please keep in mind that we're speaking >> about libxml2 here and not my own project) but config

Re: Shared library versioning

2011-06-17 Thread Charles Wilson
On 6/17/2011 5:26 AM, Lasse Collin wrote: > At that point, Debian had bumped major to 2. Other distros might have > had other versions. If I had tracked the ABI breakages in development > versions, current in -version-info would now be close to a three-digit > number. Probably I wouldn't have re

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 3:46 AM, Marco atzeri wrote: > on cygwin > > "lt_cv_deplibs_check_method=pass_all" > > is my workaround at configure stage to bypass incorrect > libtool detection of system capabilities and to allow > shared libs building. It's not about "system capabilities" in this case. It's abou

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Marco atzeri
On 6/17/2011 4:14 PM, Charles Wilson wrote: On 6/17/2011 3:46 AM, Marco atzeri wrote: on cygwin "lt_cv_deplibs_check_method=pass_all" is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It's not about "system cap

Re[4]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Vadim Zeitlin
On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn wrote: BF> On Fri, 17 Jun 2011, Vadim Zeitlin wrote: BF> > BF> > Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just BF> > too accustomed to the "traditional" Windows way and have trouble accepting BF> > auto-import m

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 11:03 AM, Marco atzeri wrote: > Sorry Chuck, > but I can assure you that I am linking against shared dlls, > but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the de

rpath encoded in binary linking a .la-.so file

2011-06-17 Thread Jan Engelhardt
-- Forwarded message -- Date: Tue, 24 May 2011 15:16:36 From: Jan Engelhardt To: bug-libt...@gnu.org Cc: Jozsef Kadlecsik, Peter Volkov Subject: rpath encoded in binary linking a .la-.so file On Tuesday 2011-05-24 15:01, Peter Volkov wrote via private mail: > >>>Final ipset binary