Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
Peter Jones wrote:
Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
There's one, called dolt. Problem is, packages ship with generated files so they won't pick it up unless you want to do the 'autoconf; libtoolize; automake; ...' at build time, which breaks more stuff than it fixes. dolt is not fully transparent. One needs to add one line to configure.ac, but that can be worked around if we wanted to.
behdad
On Fri, 2008-12-05 at 00:41 -0500, Behdad Esfahbod wrote:
Peter Jones wrote:
Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
There's one, called dolt. Problem is, packages ship with generated files so they won't pick it up unless you want to do the 'autoconf; libtoolize; automake; ...'
=> It's an alternative to developers, not an alternative "at build-time".
at build time, which breaks more stuff than it fixes. dolt is not fully transparent. One needs to add one line to configure.ac, but that can be worked around if we wanted to.
On Fri, 2008-12-05 at 00:28 -0500, Peter Jones wrote:
Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know).
Right, ... and libtool-2 is a completely different beast once again.
Future will tell if it improves or worsens the situation. It definitely cleans up part of the mess older libtools suffered from.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
Such a tool would widely contradict libtools purposes (portability).
I.e. such a tool will only help "linux-only packages" and package for which portability to other OS is of minor interest (such as glibc).
Ralf
On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE-----
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
A Linux only replacement is of minimal interest to large majority of libs in Fedora which are portable across multiple OS. Very few libs are truely Linux only
Daniel
On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
No one has explained yet how these packages that don't use libtool will work when cross-compiling to Windows (or on HP-SUX / all the other platforms that have different ways to make shared libraries).
Really: use libtool, it helps.
Rich.
On Fri, 2008-12-05 at 10:29 +0000, Richard W.M. Jones wrote:
On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
I agree that a Linux-only replacement for libtool should be used, if at all. So why isn't there one available in Fedora that deps on "libtool" will pick by default?
No one has explained yet how these packages that don't use libtool will work when cross-compiling to Windows (or on HP-SUX / all the other platforms that have different ways to make shared libraries).
Really: use libtool, it helps.
gcc -shared works on windows now, you know.
If the assertion is that we still need to care about non-gnu toolchains, then that's one thing, but if all libtool is doing is wrapping gcc, then it's worse than useless.
- ajax
On Fri, Dec 05, 2008 at 11:23:33AM -0500, Adam Jackson wrote:
gcc -shared works on windows now, you know.
That's not true.
You also need to generate an implib on Windows, which requires an extra Windows-specific gcc option.
Furthermore you would normally want your Windows shared library to be called foo-VERSION.dll versus foo.so.VERSION on Linux (and another, completely different name on AIX or HP-UX).
You might also want to generate a *.def file on Windows (if you were going to use/link with any VC code).
Libtool deals with this crap. It's dumb to get every packager to replicate it.
Rich.
On Fri, 2008-12-05 at 16:40 +0000, Richard W.M. Jones wrote:
On Fri, Dec 05, 2008 at 11:23:33AM -0500, Adam Jackson wrote:
gcc -shared works on windows now, you know.
That's not true.
You also need to generate an implib on Windows, which requires an extra Windows-specific gcc option.
Furthermore you would normally want your Windows shared library to be called foo-VERSION.dll versus foo.so.VERSION on Linux (and another, completely different name on AIX or HP-UX).
You might also want to generate a *.def file on Windows (if you were going to use/link with any VC code).
At the risk of another flamewar, Cmake does all this on Windows just fine, and is its major selling point really. Cmake supports Visual Studio, which GNU tools will never, ever do. Say what you want about MSVC, (It sucks.) but if you want to win over the masses of Windows developers, you have to support it.
Libtool deals with this crap. It's dumb to get every packager to replicate it.
Richard W.M. Jones wrote:
You also need to generate an implib on Windows, which requires an extra Windows-specific gcc option.
MinGW can actually link a DLL directly these days.
The problem is with directories: the executable wants the DLL in bin, but the linker will only find it in lib. For this reason, and in some cases also because of compatibility with M$VC, import libraries are usually still used.
Kevin Kofler
On Fri, Dec 05, 2008 at 12:28:44AM -0500, Peter Jones wrote:
Responding to the correct mailing list for this discussion. Cc:ing the other one.
Ulrich Drepper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Dennis wrote:
I've had my fill of autotool problems (especially libtool)
Don't throw in libtool with the rest. libtool was available in the spirit of the auto tools only in its very first version (which of those reading this only Jim and Tom will know). Then came the windows and HP-SUX idiots and ruined it. I've for the longest time said libtool should not be used (and I don't do it in my code). In the worst case a simple Linux-only replacement for libtool should be used.
Could I ask you how are you building shared librares from one source for multiple platforms? I need, for example, to compile and run shared library on Linux, AIX, HP-UX and Solaris. Do you know what tool is better than libtool?
Adam
I can't speak for Ulrich, but:
Adam Tkac wrote:
Could I ask you how are you building shared librares from one source for multiple platforms? I need, for example, to compile and run shared library on Linux, AIX, HP-UX and Solaris. Do you know what tool is better than libtool?
CMake.
Kevin Kofler