Date: Mon, 25 Jun 2001 19:36:28 +0300 (WET) From: Andris Pavenis To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com Subject: Re: gcc 3.0 released In-Reply-To: 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 y On Mon, 25 Jun 2001, Eli Zaretskii wrote: > > On Mon, 25 Jun 2001, Andris Pavenis wrote: > > > One more problem is dxegen failure on gcc-3.0 compiled object files due to > > .comment section (it misinterprets it as unresolved reference). In last > > time I patched dxegen.c to workaround this problem (ignore .comment), but > > I'm almost sure Eli would not like such patch > > I don't know why should I not like it. What is the cleanest way to solve > this? Can dxegen do anything useful with these sections? If it cannot, > then ignoring them is an okay solution, IMHO. They simply contain info that object file is generated by GCC-3.0 and nothing else. For DJGPP it is defined as containing debug info, so it's later removed by strip. There may be also something wrong with reading COFF file in mkdexe.c and related functions. I don't know. > > > About Eli's initial question. How possible is some change in > > binutils that would make linker script from current djdev incompatible > > with binutils (I think it's unlikely ...) > > I don't know. The fact is that this happened with GCC; it can happen > again with Binutils. I'd prefer that such problems could be detected > during the development of each one of the packages (GCC and Binutils), > and avoided by submitting appropriate patches into the mainstream > sources. But given the size and complexity of these packages and the > scarcity of resources, I understand how hard it could be to find these > problems in time. So I guess a possibility that such problems are found > late is something we will have to live with. > I suggested temporary solution we can change back when the solution will be available in DJGPP port of binutils. Even fixing linker scripts in binutils Mark plans to do should not break binaries of gcc-3.0 which could contain their own linker script for some time. don't see serious problems here also as it's unlikely gcc-3.0 will be newest version for a long time Andris