From: "Laurynas Biveinis" <lauras AT softhome DOT net>
Date: Wed, 20 Jun 2001 18:43:07 +0200
To: djgpp-workers AT delorie DOT com
Subject: Re: gcc-3.0
Message-ID: <20010620184307.A8351@lauras.lt>
Mail-Followup-To: djgpp-workers AT delorie DOT com
References: <Pine DOT A41 DOT 4 DOT 05 DOT 10106201027140 DOT 26430-100000 AT ieva06 DOT lanet DOT lv>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.A41.4.05.10106201027140.26430-100000@ieva06.lanet.lv>
User-Agent: Mutt/1.3.18i
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


> I also met problems building libtool-1.4 which tried to detect whether
> -fPIC works by simply compiling source but not linking. So maybe we should
> still reject it for DJGPP as it is not supported by binutils. I can take
> it off of course if needed

So it seems that GCC should not reject -fPIC, at least until better
solution is found.

> If we're going to get rid of x-*, xm-*.h and t-* files, then how to
> add for example some extra host specific source file (like I used to
> check for DJGPP installation problems in gcc-2.95.X or host or target
> specific generated file (like djgpp.ver in this case). Of course
> sometimes we can workaround that but I don't think it reasonable 
> to enforce that	

No, of course, everybody does things easier (or cleaner, or better...)
way after all. Most stuff in x-*, xm-*.h is going to be autoconfiscated,
but some of t-* files will stay - there is no other way to describe target.
So I was just asking :)

Laurynas