Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Peter O'Gorman
On 02/06/2012 06:35 PM, Jan Engelhardt wrote: Much to my disappointment, I found that the newly-released libkmod v5 has made the following non-trivial change to its source tree, the latter of which I want to bring to attention: commit e479598b7d19ae7be45bf5329d6e4df32d646c16

Single static library from multiple Libtool .a files

2012-02-07 Thread Nate Bargmann
This is probably going to be long and somewhat complex. I am involved with a library project that has used the Autotools for some time. We primarily focus on Linux and other UNIX platforms as well as build using Mingw32 for Win32. All of this works well with shared libraries. We have a

The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Jan Engelhardt
Much to my disappointment, I found that the newly-released libkmod v5 has made the following non-trivial change to its source tree, the latter of which I want to bring to attention: commit e479598b7d19ae7be45bf5329d6e4df32d646c16 diff --git a/Makefile.am b/Makefile.am

[PLATFORM] sparc-sun-solaris2.10 gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

2012-02-07 Thread Robert A. Schmied
libtool-2.4.2 built and tested 100% on subject plat host-triplet: sparc-sun-solaris2.10 shell: /bin/bash compiler: gcc compiler flags: -O2 -H -mcpu=v9 -mfpu linker: /usr/ccs/bin/ld (gnu? no) libtool:

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Vincent Torri
On Tue, Feb 7, 2012 at 3:03 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Tue, 7 Feb 2012, Jan Engelhardt wrote: Much to my disappointment, I found that the newly-released libkmod v5 has made the following non-trivial change to its source tree, the latter of which I want to bring

Re: Single static library from multiple Libtool .a files

2012-02-07 Thread Bob Friesenhahn
On Mon, 6 Feb 2012, Nate Bargmann wrote: For some reason, that I have yet to understand, his static build succeeded with all the backends in libdir but fails with them in pkgdir. In my opinion, it would be better to be able to provide him with a single .a library that includes the entirety of

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Bob Friesenhahn
On Tue, 7 Feb 2012, Lucas De Marchi wrote: Hopefully your intention is only to illustrate what projects should not do and not to submit a patch.  This libkmod project seems to be less than two months old and perhaps the developers still have a bit to learn about library versioning. Yes. We

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Lucas De Marchi
Hi Bob [ Please don't remove CC ] On Tue, Feb 7, 2012 at 12:03 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Tue, 7 Feb 2012, Jan Engelhardt wrote: Much to my disappointment, I found that the newly-released libkmod v5 has made the following non-trivial change to its source tree,

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Peter O'Gorman
On 02/07/2012 07:06 PM, Lucas De Marchi wrote: Yes. We can always learn. It seems that this is not the case here. There are other projects releasing like this and no one pointed out to a reasonable argument against it. That means these arguments are not valid in our case: Again, use

Re: The case of libkmod's .so versioning attempts, and induced collisions

2012-02-07 Thread Jan Engelhardt
On Wednesday 2012-02-08 03:45, Peter O'Gorman wrote: On 02/07/2012 07:06 PM, Lucas De Marchi wrote: Yes. We can always learn. It seems that this is not the case here. There are other projects releasing like this and no one pointed out to a reasonable argument against it. That means these