Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Christopher Faylor]

I've just uploaded new versions of the gcc test versions to
sources.redhat.com.  This trio of releases fixes some problems that have
been recently reported here.

I ran ths release through Chuck's "test suite" and it got most of the
way through building setup.exe before it bogged down in some
incompatibilities due to some problems with Pavel Tsekov's patch (sent
to me privately) and cvs setup trunk.

As promised, the gcc2 release contains a copy of the mingw libstdc++.a
and libgc2.a libraries.  so "g++-2 -mno-cygwin" should work a little
better.  g++-2 -mno-cygwin header files should now be correctly located.

gcc 3.1.1 should correctly find files in /usr/include/w32api.  gcc was
also completely built from a three stage bootstrapping process.

g77-2 should also work correctly.

Replies to the list, please.

cgf
--
Please do not send me personal email with cygwin questions.
Use the resources at http://cygwin.com/ .

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Nicholas Wourms]

--- Christopher Faylor <cgf-cygwin@cygwin.com> wrote:
> I've just uploaded new versions of the gcc test versions to
> sources.redhat.com.  This trio of releases fixes some problems that have
> been recently reported here.
> 
> I ran ths release through Chuck's "test suite" and it got most of the
> way through building setup.exe before it bogged down in some
> incompatibilities due to some problems with Pavel Tsekov's patch (sent
> to me privately) and cvs setup trunk.
> 
> As promised, the gcc2 release contains a copy of the mingw libstdc++.a
> and libgc2.a libraries.  so "g++-2 -mno-cygwin" should work a little
> better.  g++-2 -mno-cygwin header files should now be correctly located.
> 
> gcc 3.1.1 should correctly find files in /usr/include/w32api.  gcc was
> also completely built from a three stage bootstrapping process.
> 
> g77-2 should also work correctly.

Chris,

Did you try the suggestions I made in:

http://cygwin.com/ml/cygwin-apps/2002-07/msg00384.html

to get libiconv working?  Just curious to see if it helped.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Christopher Faylor]

On Mon, Jul 15, 2002 at 03:00:13PM -0700, Nicholas Wourms wrote:
>Did you try the suggestions I made in:
>
>http://cygwin.com/ml/cygwin-apps/2002-07/msg00384.html
>
>to get libiconv working?  Just curious to see if it helped.

No.  If this isn't working then I wasn't looking for a workaround.

As it turns out, apparently only some parts of java used this.  Those
are correctly linked with -liconv.  The rest of the tool chain doesn't use
-lintl, though, since there are specific tests to invalidate this under
cross compilation.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Dylan Cuthbert]

Hello there,

I've taken this version and compiled the same source code I was compiling
the 3.1.1-2 version with, and all text output to the rxvt shell seems to
have vanished.  Text to a standard cygwin shell is still ok.

This text output was there with the prior version of the compiler - any idea
what could cause this?

Regards

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Pavel Tsekov]

CF> I ran ths release through Chuck's "test suite" and it got most of the
CF> way through building setup.exe before it bogged down in some
CF> incompatibilities due to some problems with Pavel Tsekov's patch (sent
CF> to me privately) and cvs setup trunk.

Yes, it was for version 2.249.2.4 - I will prepare a new one agains
CVS head once I download the new gcc package :)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Nicholas Wourms]

--- Pavel Tsekov <ptsekov@gmx.net> wrote:
> CF> I ran ths release through Chuck's "test suite" and it got most of
> the
> CF> way through building setup.exe before it bogged down in some
> CF> incompatibilities due to some problems with Pavel Tsekov's patch
> (sent
> CF> to me privately) and cvs setup trunk.
> 
> Yes, it was for version 2.249.2.4 - I will prepare a new one agains
> CVS head once I download the new gcc package :)
> 
Pavel,

When you get around to rebuilding setup with the new gcc's, let us know
what flags needed to be passed to setup.  My main question is:  is the
CPPFLAGS option, noted on the setup homepage, still required for building
setup?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Christopher Faylor]

On Tue, Jul 16, 2002 at 10:47:11AM +0200, Pavel Tsekov wrote:
>CF> I ran ths release through Chuck's "test suite" and it got most of the
>CF> way through building setup.exe before it bogged down in some
>CF> incompatibilities due to some problems with Pavel Tsekov's patch (sent
>CF> to me privately) and cvs setup trunk.
>
>Yes, it was for version 2.249.2.4 - I will prepare a new one agains
>CVS head once I download the new gcc package :)

Right.  Mega apologies if this sounded critical in any way.  I was happy
to get your patch but I didn't want to spend too much time tweaking it
when I discovered that it didn't work with the trunk.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Dylan Cuthbert]

Hello all

There hasn't been any response so I presume noone else is getting this
problem.  I have whittled down the options that seem to cause it the most:

It is very strange but it occurs after compiling large-ish programs with
gcc's new sparkly -march=pentium2 (or 3) option enabled.  Are there any ABI
changes causing problems between older dlls maybe?

Depending on the..erm.. weather?, it will also crash immediately upon
execution, not even bothering to write out a
stackdump file.  This situation changes if I re-arrange sections of the
code, or link in a different order.

It *doesn't* crash when running from a command.com style bash shell prompt.

System is very latest cygwin, win2k, Athlon MP dual processor, and
everything else bog-standard.

Regards

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com

"Dylan Cuthbert" <dylan@q-games.com> wrote in message
news:ah0bkt$s62$1@main.gmane.org...
> Hello there,
>
> I've taken this version and compiled the same source code I was compiling
> the 3.1.1-2 version with, and all text output to the rxvt shell seems to
> have vanished.  Text to a standard cygwin shell is still ok.
>
> This text output was there with the prior version of the compiler - any
idea
> what could cause this?
>
> Regards
>
> ---------------------------------
> Q-Games, Dylan Cuthbert.
> http://www.q-games.com
>
>
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Christopher Faylor]

On Wed, Jul 17, 2002 at 05:14:46PM +0900, Dylan Cuthbert wrote:
>Hello all
>
>There hasn't been any response so I presume noone else is getting this
>problem.  I have whittled down the options that seem to cause it the most:
>
>It is very strange but it occurs after compiling large-ish programs with
>gcc's new sparkly -march=pentium2 (or 3) option enabled.  Are there any ABI
>changes causing problems between older dlls maybe?
>
>Depending on the..erm.. weather?, it will also crash immediately upon
>execution, not even bothering to write out a
>stackdump file.  This situation changes if I re-arrange sections of the
>code, or link in a different order.
>
>It *doesn't* crash when running from a command.com style bash shell prompt.

Wouldn't it make perfect sense to run a crashing application in gdb and
see *where* it crashes?  Or does it make better sense to send email to
a mailing list hoping someone will know why your specific applications
are crashing, wait a day or so, and then ask again?

Personally, I would want to know why things weren't working.  Apparently
YMMV.

cgf

>System is very latest cygwin, win2k, Athlon MP dual processor, and
>everything else bog-standard.
>
>Regards
>
>---------------------------------
>Q-Games, Dylan Cuthbert.
>http://www.q-games.com
>
>"Dylan Cuthbert" <dylan@q-games.com> wrote in message
>news:ah0bkt$s62$1@main.gmane.org...
>> Hello there,
>>
>> I've taken this version and compiled the same source code I was compiling
>> the 3.1.1-2 version with, and all text output to the rxvt shell seems to
>> have vanished.  Text to a standard cygwin shell is still ok.
>>
>> This text output was there with the prior version of the compiler - any
>idea
>> what could cause this?
>>
>> Regards
>>
>> ---------------------------------
>> Q-Games, Dylan Cuthbert.
>> http://www.q-games.com
>>
>>
>>
>>
>> --
>> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>> Bug reporting:         http://cygwin.com/bugs.html
>> Documentation:         http://cygwin.com/docs.html
>> FAQ:                   http://cygwin.com/faq/
>>
>>
>
>
>
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting:         http://cygwin.com/bugs.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Dylan Cuthbert]

If the debugger worked, yes I would *of course* run gdb and see where it
crashes.

At the moment when I run the debugger (the latest exp version of gdb) it
puts its "start of main" breakpoint in a piece of code that is nowhere near
main and when I try to step or run my program, my program seg-faults.  The
debugger at this point freezes completely.  I have compiled the entire
source code with -ggdb and even -g but to no avail.

As I may have mentioned, the program we are developing uses a large amount
of modern C++ (boost/mpl/loki etc) and it seems to kind of push the compiler
and gdb to their limits.  Simpler programs I've compiled and tested work
fine.

I'm clutching at straws, which is why I was asking about ABI changes
between -march=pentiumpro and -march=pentium2/3, would alignment adjustments
in the linker (I think you mentioned you had to revert some changes to get
the old gcc to work properly?)

Now, the reasons I'm mailing to this list are that the program works *fine*
without the -mpentium2/3 option to gcc.  It also works *fine* even with
those options if I run it from a command.com bash shell.  The program itself
is a 3d OpenGL program and a non-cygwin application (although not currently
compiling with -mno-cygwin because mingw wasn't up to gccv3.1 until
recently), the program (when it runs from a command.com bash shell) exhibits
absolutely no problems at all.  When it is able to run from rxvt at all,
simply no output appears whatsoever... when it doesn't run, it crashes
immediately and doesn't even write a stackdump file.

The problem might simply be gcc-related but its odd how it is broken "in
combination" with rxvt.

Just trying to catch some of these problems before they get to other
people... any help appreciated.

Regards

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com

PS. rxvt seems to have a no. of problems - sometimes pushing ctrl-o simply
freezes it completely, I haven't tracked down the exact conditions but it is
really annoying sometimes. .Clicking on the top-right close-window button
when it is running a child-process causes the window to disappear but the
task to keep running.- type "sleep 1h" into an rxvt shell, close the window
with the X button and type ps in another shell and you'll see what I mean...




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Nicholas Wourms]

> PS. rxvt seems to have a no. of problems - sometimes pushing ctrl-o
> simply
> freezes it completely, I haven't tracked down the exact conditions but
> it is
> really annoying sometimes. .Clicking on the top-right close-window
> button
> when it is running a child-process causes the window to disappear but
> the
> task to keep running.- type "sleep 1h" into an rxvt shell, close the
> window
> with the X button and type ps in another shell and you'll see what I
> mean...

I do know what you mean.  I have been corresponding privately with the
rxvt mainatainer,Steve O., and he is planning to release a new version
soon.  However, Steve is short on time, so if you feel like helping him,
please send him an email to the address in the README file.  He has
indicated that any help would be appreciated.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Robert Collins]

libtool creates metalibrary files that contain dependency information,
sonames, dlopen names and the like. They are called foo.la.

Rob
===
----- Original Message -----
From: "Heribert Dahms" <heribert_dahms@icon-scm.com>
To: "'Robert Collins'" <robert.collins@syncretize.net>; "'Billinghurst,
David (CRTS)'" <David.Billinghurst@riotinto.com>; <cygwin@cygwin.com>
Sent: Saturday, July 20, 2002 6:47 AM
Subject: RE: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9,
gcc-mingw-3_1-20020516-2


> Hi Rob,
>
> what is *.la, please?
> I know *.a, *.so, *.sl, *.dll etc for years,
> but I've seen *.la mentioned only in a few recent mails.
>
> Bye, Heribert (heribert_dahms@icon-scm.com)
>
> > -----Original Message-----
> > From: Robert Collins [SMTP:robert.collins@syncretize.net]
> > Sent: Wednesday, July 17, 2002 15:39
> > To: 'Billinghurst, David (CRTS)'; cygwin@cygwin.com
> > Subject: RE: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9,
> > gcc-mingw-3_1-20020516-2
> >
> > >  - /usr/lib/libstdc++.la
> > >  - /usr/lib/libsupc++.la
> > >  - /usr/lib/libgcj.la
> >
> > Hmm, I smell a libtool problem in the generation of the .la files.
> >
> > Sigh, I'll add this to my list of libtool bugs to review.
> >
> > Rob
> >
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Christopher Faylor]

On Wed, Jul 17, 2002 at 11:38:41PM +1000, Robert Collins wrote:
>
>
>> -----Original Message-----
>> From: cygwin-owner@cygwin.com 
>> [mailto:cygwin-owner@cygwin.com] On Behalf Of Billinghurst, 
>> David (CRTS)
>> Sent: Wednesday, 17 July 2002 11:26 PM
>> To: cygwin@cygwin.com
>> Subject: RE: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, 
>> gcc-mingw-3_1-20020516-2
>> 
>> 
>> The latest g77 seems fine.  LAPACK testsuite results are similar
>> to 2.95 and my own builds of 3.[012].
>> 
>> There is a problem with:
>>  - /usr/lib/libstdc++.la
>>  - /usr/lib/libsupc++.la
>>  - /usr/lib/libgcj.la
>> The paths that are hardcoded into the dependency_libs line
>> don't exist on my machine, so attempts to use c++ with libtool
>> fail.  (Just deleting the *.la files seems to solve the problem,
>> but I expect there are more subtle fixes.)  Once the libtool 
>> problem was overcome I could build ImageMagick including the 
>> c++ libraries.
>
>Hmm, I smell a libtool problem in the generation of the .la files.
>
>Sigh, I'll add this to my list of libtool bugs to review.

I know zero about libtool, but libtool is obviously taking my local
configury (below) and placing it into libstdc++\.la.  I don't know if
that is right or wrong but it seems strange -- especially when the tools
are cross-compiled.

I'm going to remove all of the .la files from the release for now.
I could rectify the dependency_libs but looking at what it is including,
even with the paths fixes, I don't think it really is very useful.

cgf

dependency_libs=' -L/cygwin/lib/gcc-lib/i686-pc-cygwin/3.1.1 -L/cygwin/lib/gcc-lib/i686-pc-cygwin/3.1.1/../../../../i686-pc-cygwin/lib -L/netrel/native/gcc3/i686-pc-cygwin/libstdc++-v3/src -L/netrel/native/gcc3/i686-pc-cygwin/libstdc++-v3/src/.libs -L/netrel/native/gcc3/gcc -L/cygwin/i686-pc-cygwin/bin -L/cygwin/i686-pc-cygwin/lib -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /cygwin/lib/gcc-lib/i686-pc-cygwin/3.1.1/libstdc++.la -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc'

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Billinghurst, 
> David (CRTS)
> Sent: Wednesday, 17 July 2002 11:26 PM
> To: cygwin@cygwin.com
> Subject: RE: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, 
> gcc-mingw-3_1-20020516-2
> 
> 
> The latest g77 seems fine.  LAPACK testsuite results are similar
> to 2.95 and my own builds of 3.[012].
> 
> There is a problem with:
>  - /usr/lib/libstdc++.la
>  - /usr/lib/libsupc++.la
>  - /usr/lib/libgcj.la
> The paths that are hardcoded into the dependency_libs line
> don't exist on my machine, so attempts to use c++ with libtool
> fail.  (Just deleting the *.la files seems to solve the problem,
> but I expect there are more subtle fixes.)  Once the libtool 
> problem was overcome I could build ImageMagick including the 
> c++ libraries.

Hmm, I smell a libtool problem in the generation of the .la files.

Sigh, I'll add this to my list of libtool bugs to review.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Available for test: gcc-3.1.1-3, gcc2-2.95.3-9, gcc-mingw-3_1-20020516-2

[Billinghurst, David (CRTS)]

The latest g77 seems fine.  LAPACK testsuite results are similar
to 2.95 and my own builds of 3.[012].

There is a problem with:
 - /usr/lib/libstdc++.la
 - /usr/lib/libsupc++.la
 - /usr/lib/libgcj.la
The paths that are hardcoded into the dependency_libs line
don't exist on my machine, so attempts to use c++ with libtool
fail.  (Just deleting the *.la files seems to solve the problem,
but I expect there are more subtle fixes.)  Once the libtool 
problem was overcome I could build ImageMagick including the 
c++ libraries.

Similar problems occur in:
 - libexslt.la
 - libguile-srfi-srfi-13-14.la
 - libguile.la
 - libguilereadline.la
 - libxsltbreakpoint.la

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/