Date:	Tue, 19 Jun 2001 16:26:10 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com, Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
Subject:	Re: Package of libtool?
In-Reply-To:	<Pine.LNX.4.10.10106191429540.5716-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1010619162001.9970A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 19 Jun 2001, Hans-Bernhard Broeker wrote:

> On Mon, 18 Jun 2001, Tim Van Holder wrote:
> 
> > From my attempts at building cvs gettext (which now uses 1.4) there should
> > be no problem, save one.  ltconfig uses -fPIC as compiler option to
> > produce PIC code.  
> 
> Hm... but doesn't it only do that if building of *shared* libraries is
> active? Since those are a non-issue for DJGPP anyway, can't we just
> disable that whole branch of it once and for all, for a DJGPP port
> (effictively forcing the --disable-shared option for all DJGPP builds)? At
> least to me, that seems like the obvious thing to do.

IIRC, libtool in packages I looked into used to detect that DJGPP doesn't 
support shared libraries and stop using -fPIC.  Unless my memory fails me 
(wouldn't be the first time ;-), something's changed in libtool, and that 
change is now causing us grief.

> > An obvious fix is to simply edit ltconfig to not use this option; I've
> > also mailed a report to Mark & Andris, but I'm not sure if this is something
> > that should be handled in binutils (ie add support to bfd) or gcc (ie
> > disallow -fPIC for a djgpp host).
> 
> That would be another possibility, indeed. We don't need PIC

We don't need -fPIC for building normal DJGPP applications.  But someone 
might need that (or even might depend on it being present) for various 
non-standard tricks people sometimes play with DJGPP, like building 
custom stand-alone executables etc.

In addition, disabling -fPIC is only a solution for future versions of 
GCC.  It doesn't solve the problem of people who use older versions (I 
still use GCC 2.7.2.1 on some of my machines from time to time).

> > Otherwise, libtool 1.4 seems to work very well (at least with autoconf 2.50
> > and a cvs automake).
> 
> Which currently is a big stumbling block, IMHO. It's somewhat silly for
> a released version of one tool to require a (hacked) CVS-only version of
> some other to work properly.

Unfortunately, this is quite common in some of the GNU projects where the 
maintainers use unstable versions of other development tools to develop 
their packages, without considering possible problems such as this one.

- Raw text -