Date: Tue, 19 Jun 2001 16:26:10 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: djgpp-workers AT delorie DOT com, Richard Dawe Subject: Re: Package of libtool? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.