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
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

> 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

- Raw text -