Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <42D30E4B.4060500@cwilson.fastmail.fm>
Date: Mon, 11 Jul 2005 20:26:51 -0400
From: Charles Wilson <cygwin@cwilson.fastmail.fm>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: gcc: .rdata problem
References: <42D30B5D.4040807@users.sourceforge.net>
In-Reply-To: <42D30B5D.4040807@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yaakov Selkowitz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Gerrit,
> 
> After all the updates to the toolchain and libtool, what is the current
> status of the .rdata problem?  Does code still need to be edited as with
> gcc-3.3?

I dunno about the .rdata issue, but you can't use /usr/bin/libtool with 
g++-3.4.4 because /usr/bin/libtool encodes explicit predep and postdep 
objects and paths specific to g++-3.3.3.

This does not affect libtool + gcc (C code).  Nor does it affect the 
typical case where YourFavoriteProject builds a local libtool script 
during its configure step.

It only blows up if (a) you're compiling C++ code, and (b) you use 
libtool, but (c) you don't create your own version of the libtool script 
during configure.

At present, I've only seen this "in the wild" when building ncurses. 
But as it might impact somebody else, I figured I'd get it in the archives.

Quick fix: download the libtool1.5 src package using setup.exe, and 
rebuild it on your own machine using your current installed toolset.

Long term fix: I need to release libtool packages in sync with gcc 
releases.  Look for a g++-3.4.4 compatible (but g++-3.3.3 INcompatible) 
libtool1.5 update soon.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/