Message-ID: <B0000078086@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: "Mark E." <snowball3 AT usa DOT net>, djgpp-workers AT delorie DOT com
Date: Tue, 2 Mar 1999 18:14:10 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Problems with collect2 in egcs-1.1.1 and 1.1.2preX
In-reply-to: <199903021511.PAA59936@out1.ibm.net>
References: <B0000078064 AT stargate DOT astr DOT lu DOT lv>
X-mailer: Pegasus Mail for Win32 (v3.02b14)
Reply-To: djgpp-workers AT delorie DOT com

On 2 Mar 99, at 10:12, Mark E. wrote:
> 
> > About linker problems when using templates with egcs. Currently only way I
> > see is to use command line option -frepo when compiling sources. However
> > this all may require additional testing.
> > 
> 
> I think you're right.
> 
> > I don't expect other solution (other than -frepo) in nearest future. 
> > 

If we accept this (taking some source files from a different version) then I think
it's last thing to make official release of egcs-1.1.2 when it will be out (no more
betas):
	- exceptions support seems to be fixed even if binutils 2.8.1 is being used
          (no special need for development snapshots). Lazlo sent related patches 
          for gcc/dwarf2out.c and I hope they'll go into egcs tree after some time
          (but perhaps not in 1.1.2). We can even reproduce exceptions problems
          in Linux  (-Wl,--traditional-format to turn of eh frame optimization). I think
          fixing non zero padding in .eh_frame in AS is very ugly hack. So may be
          it will be finally fixed. So I don't see more significant exceptions related 
          regressions against gcc-2.8.1 (-fsjlj-exceptions still seems to be broken
          but I think there is no need to use them)
       -  If collect2 will work as expected we'll be able to workaround linking
          problems in programs that uses STL. I don't thing it will make
          Paul Derbyshire happy as I think its impossible as there always will be
          thing from standards that will be not fully implemented and we cannot be 
          sure he'll have the latest version of standards. But for normal users it
          could be significant step ahead in comparisson with port of gcc-2.8.1 

> Me neither. The next release of binutils will have weak symbol support, 
> but no telling when that will be. It wouldn't be very hard to backport 
> weak symbol support to the latest of the binutils 2.9 series, but that 
> would have to be a last resort. 

Week symbols is not only thing with template support. There is also 
static members in template classes that are generated.

> And it would also have the unfortunate 
> side effect of making Paul Derbyshire happy <g>.

As I said I'm afraid it's impossible.

> Since I'm already sending you a note...
> Would you have any objections to renaming the egcs config files for 
> DJGPP to eliminate go32 from the filenames? Ex. xm-go32.h -> xm-
> djgpp.h, go32.h -> djgpp.h, etc. I've sent off the paperwork to do this, 
> but I won't bother if you think it is a bad idea.

I think it's Ok. Currently even there is conflict between djdev202 and 
egcs sources as both have file go32.h. It required special hack in Makefiles 
for mktemp-djgcc.c to include go32.h from DJGPP not egcs.

> I've also resent paperwork for the collect2 patches. But I'm not sure I'll 
> ever be able to those in since it only helps DJGPP and Jeff Law has on 
> several occasions expressed his bias against DOS.

Patches must be done in the way they are not breaking any other system.
Current version of Your patch I have elminates some Cygwin related stuff and
I'm afraid it may be not accepted. Of course I don't know if it really breaks 
cygwin.

There are more things:

Current way how I got egcs-1.1.X build for DJGPP (splitting tree into two 
parts: gcc itself and libraries) cannot more be done so easy with current 
development snapshots of egcs and perhaps we'll not be able to do it easy 
for egcs-1.2 when it will be released (not the question for next some months)

Second question is about including support for GNU Pascal. My latest builds
are together with latest beta of GPC. But there are problems with Pascal runtime
I don't want to mess with for example use of curses in some standard units.
Of course one can require to install pdcurses with GPC, but it will be source
of huge amount of questions. Perhaps we can build this all together but put
Pascel related binaries in beta directory.

I did my latest tests with egcs-1.1.2 prerelease 2

Andris