Mail Archives: djgpp-workers/1999/03/02/11:51:12
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
- Raw text -