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:
<pedantic>Gary 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
