Date:	Wed, 20 Jun 2001 10:39:08 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Laurynas Biveinis <lauras AT softhome DOT net>
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: gcc-3.0
In-Reply-To:	<20010619200501.A203@lauras.lt>
Message-ID:	<Pine.A41.4.05.10106201027140.26430-100000@ieva06.lanet.lv>
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, Laurynas Biveinis wrote:

> 
> > scripts I used and diffs against original gcc-3.0.tar.gz
> > 	http://www.ltn.lv/~pavenis/gcc30s2.zip
> 
> Thanks, and just two minor comments:
> 
> 1) Patch to djgpp.h - you've made it to abort if -fPIC given. IMHO
> this might be a wrong solution, if there are some packages which
> assume that -fPIC is supposed to work.

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

> 
> 2) Patch to t-djgpp - this patch would make GCC maintainers angry. Very
> angry indeed - they are working to get rid of most x-*, xm-*.h, t-* files.
> Any other possible solutions there? It's OK with our release, but I'm
> thinking about upstream.

There is 2 ways how to get sys/version.h included at start:
	-imacros %s ../include/sys/version.h
which looks rather ugly and hack with generated djgpp.ver file which
includes sys/version.h. I think the second way looks more nice.
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	

Andris

- Raw text -