On Fri, Sep 01, 2000 at 07:40:09PM +0300, Paul Sokolovsky wrote:
Hello Charles,
Charles S. Wilson [EMAIL PROTECTED] wrote:
CSW Well, the problem with libtool is that it's a developer's tool. Take
CSW the gettext package, for instance. It uses some version of libtool that
CSW does not understand cygwin/dlls. The only way to 'fix' it is to replace
CSW the libtool that is distributed WITH gettext, with a newer version.
Yep, it's all about doing 'libtoolize --force'. When that will
work (I mean, it will be possible to take some existing GNU/*nix
package, run libtoolize --force/aclocal/automake -a/autoconf and have
it compile cute little dll without any other changes), wouldn't it be
nice?
This will never work reliably. If a configure.in file (hell, the
entire package configuration) was written for an old version of
autoconf/automake/libtool, a forced configury upgrade can cause all
sorts of problems... I'll concede that some of the time (if the
author of the original configury wasn't too ambitious) brute force
will work. There is no way to guarantee that it will work though.
CSW See, libtool isn't a tool that lives on the end-user's system. It's a
CSW couple of scripts that are distributed with each package that uses
CSW libtool. So, you've probably got 27 versions of libtool on your system
CSW right now.
Yes - it is *developer* tool. But see what Gary Vaugham says:
pedanticGary Vaughan/pedantic
"remember that libtool only want's you to see (and thus link against)
the libfoo.la file". That's nice, but on typical *nix system you can
build shared lib with libtool, but link against it without it. But
they want to deprive win32 users off such possibility! (Technical
note: what corresponds to shared library on *nix system is a pair of
implib,dll on win32. *Pair*)
You're right. I remember why I did it this way now -- the libtool
machinery is not at all equipped to deal with a shared library that is
not in a single file. It is a fair amount of work to teach it to
understand that. I do agree that libtool could be nicer to the world
by installing an appropriate implib.
CSW Perhaps the current version of libtool groks cygwin dlls. (In the 'old'
CSW dlltool way; I'm positive it doesn't use 'gcc -shared').
Yes. And know why? Because they want to support outdated betas!
That was then. When we had that conversation you still needed to use
dlltool on the latest net release of cygwin at that time. I would
very much like to get rid of the dlltool dependency before 1.4 is
released.
Note - *beta* versions of systems, for which official release is
available for quite some time. Suppose libtool supported some NeXT
alpha or Solaris pre-release of early '90? Nor even it is standard
practise - I with regret read about dropping support of some systems
in gdb 5.0. My last argument would be as follows:
Suppose someone has cygwin b19 and libtool 1.2 and he wants to
build DLLs with it. But he can't - libtool 1.2 simply doesn't support
building DLLs! So, he's got to upgrade to libtool 1.3.x, but the same way,
he might upgrade cygwin to 1.1 also. So, rule is simple: want DLLs - use
release of cygwin and fresh libtool. Before that, there was some
support, but it was experimental and changes since. Don't want to
upgrade - enjoy static linking which is always available.
CSW But none of the commonly-used libraries or applications out there USE the most
CSW current libtool.
Libtool has quite stable usage interface and principles. Following
to them will allow to build shared libraries on *any* system with a
handful of sanity (win32 goes into this category). Matter is
implementing support for different systems.
It is only the case that libtool adoption among non-GNU packages is
low. Almost everything you can download from ftp.gnu.org that builds
a library uses libtool these days.
If I (or you Paul) can make libtool a better citizen in the Cygwin
environment, I'd like to think that cygwin porters would port
non-cygwin packages to libtool so that everyone can enjoy the benefits
of shared libraries in those packages -- rather than cygwin specific
ports which probably won't even be accepted into the upstream package.
Cheers,
Gary.
--
___ _ ___ __ _ mailto: [EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
