Date: Wed, 20 Jun 2001 10:39:08 +0300 (WET) From: Andris Pavenis To: Laurynas Biveinis Cc: djgpp-workers AT delorie DOT com Subject: Re: gcc-3.0 In-Reply-To: <20010619200501.A203@lauras.lt> 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, 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