DejaGnu 1.4.1 fix

DejaGnu 1.4.1 fix

[Gerald Pfeifer]

Rob, please find below a patch that fixes a problem in DejaGnu 1.4.1.

(Apparently this fix is in Red Hat's package, but not in the CVS sources
of DejaGnu.)

Hope this helps,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

---------- Forwarded message ----------
From: Jakub Jelinek <jakub@redhat.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: ab@chaos2.streamgroup.co.uk, Mailing List - GCC <gcc@gcc.gnu.org>
Date: Fri, 7 Sep 2001 12:29:35 +0200
Subject: Re: 2.95.4 testsuite problems
Sender: gcc-owner@gcc.gnu.org

On Fri, Sep 07, 2001 at 11:09:02AM +0200, Franz Sirl wrote:
> At 10:54 07.09.2001, ab@chaos2.streamgroup.co.uk wrote:
> >There seems to be problems with the testsuite. When I configured the
> >software in a build directory, it didn't seem to copy the testsuite over,
> >and when I tried to fix it by manually copying the testsuite over,
> >dejagnu didn't seem to like it too well.
> >
> >I'm using dejagnu 1.4.1. If you need further details, give me a shout.
>
> 1.4.1 from redhat rawhide/roswell? I never got that to work, try 1.4.

This was fixed already in our rpm. dejagnu 1.4.1 from ftp.gnu.org contains a
typo (this regsub does not appear in CVS dejagnu on sources though):

--- dejagnu-1.4.1/lib/target.exp.jj	Fri Apr 20 10:06:08 2001
+++ dejagnu-1.4.1/lib/target.exp	Fri Sep  7 12:27:10 2001
@@ -272,8 +272,7 @@ proc prune_warnings { text } {
     regsub -all "(^|\n)\[^\n\]*: In function\[^\n\]*\n\[^\n\]\[^\n\]*is not implemented and will always fail\[^\n\]*" $text "" text

     # Cygwin cc1 warns about -fpic and -fPIC
-    regsub -all ".*: warning: -f(pic|PIC) ignored for target .*" $text ""
-text
+    regsub -all ".*: warning: -f(pic|PIC) ignored for target .*" $text "" text

     # It might be tempting to get carried away and delete blank lines, etc.
     # Just delete *exactly* what we're ask to, and that's it.

	Jakub

Re: DejaGnu 1.4.1 fix

[Joseph S. Myers]

On Wed, 12 Sep 2001, Gerald Pfeifer wrote:

> Rob, please find below a patch that fixes a problem in DejaGnu 1.4.1.
> 
> (Apparently this fix is in Red Hat's package, but not in the CVS sources
> of DejaGnu.)

Until there's a new release of DejaGnu, we ought to provide this patch in
wwwdocs/install/, linked to from the installation instructions.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [Bug-dejagnu] DejaGnu 1.4.1 fix

[Rob Savoye]

On Wed, Sep 12, 2001 at 04:38:36PM +0200, Gerald Pfeifer wrote:
> Rob, please find below a patch that fixes a problem in DejaGnu 1.4.1.
> (Apparently this fix is in Red Hat's package, but not in the CVS sources
> of DejaGnu.)

  Which CVS sources ? This has been fixed for ages in the official CVS
repository at gnu.org. Maybe it's just the one at sources.redhat.com that
is missing this fix.

  I guess I should push out a 1.4.2 release with this fix in it, and a few
others. (like the bugs in the unit.cc test case)

	- rob -

Re: [Bug-dejagnu] DejaGnu 1.4.1 fix

[Alex Buell]

On Wed, 12 Sep 2001, Rob Savoye wrote:

>   I guess I should push out a 1.4.2 release with this fix in it, and a
> few others. (like the bugs in the unit.cc test case)

Please do - the problem exists in the 1.4.1 release on ftp.gnu.org.

-- 
Love is good. Hate is bad.

http://www.tahallah.demon.co.uk

Re: [Bug-dejagnu] DejaGnu 1.4.1 fix

[Rob Savoye]

On Wed, Sep 12, 2001 at 05:13:45PM +0100, Alex Buell wrote:
> On Wed, 12 Sep 2001, Rob Savoye wrote:
> 
> >   I guess I should push out a 1.4.2 release with this fix in it, and a
> > few others. (like the bugs in the unit.cc test case)
> 
> Please do - the problem exists in the 1.4.1 release on ftp.gnu.org.

  The bug crept in while doing the release somehow... cause I tested it
on multiple native platforms, and it was fine. I should do some cross testing,
but the net releases of GCC don't seem to want to build as a cross compiler
anymore... At least not for any target with full libgloss and simulator
support.

	- rob -

Re: [Bug-dejagnu] DejaGnu 1.4.1 fix

[Gerald Pfeifer]

On Wed, 12 Sep 2001, Rob Savoye wrote:
> Which CVS sources ? This has been fixed for ages in the official CVS
> repository at gnu.org. Maybe it's just the one at sources.redhat.com that
> is missing this fix.

Probably, as far as I understood Jakub, yes.

> I guess I should push out a 1.4.2 release with this fix in it, and a few
> others. (like the bugs in the unit.cc test case)

That would be great, thanks!  (Would you mind sending the announcement
also to gcc@gcc.gnu.org in this case?)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: [Bug-dejagnu] DejaGnu 1.4.1 fix

[Jakub Jelinek]

On Wed, Sep 12, 2001 at 07:54:45PM +0200, Gerald Pfeifer wrote:
> On Wed, 12 Sep 2001, Rob Savoye wrote:
> > Which CVS sources ? This has been fixed for ages in the official CVS
> > repository at gnu.org. Maybe it's just the one at sources.redhat.com that
> > is missing this fix.
> 
> Probably, as far as I understood Jakub, yes.

That line is not in sources dejagnu at all, so there is no need for a fix
there (but maybe it should be updated from gnu.org repository).

	Jakub

Re: [Bug-dejagnu] DejaGnu 1.4.1 fix

[Rob Savoye]

On Wed, Sep 12, 2001 at 08:01:06PM +0200, Jakub Jelinek wrote:

> That line is not in sources dejagnu at all, so there is no need for a fix
> there (but maybe it should be updated from gnu.org repository).

  All the active development and patches go into the CVS repository at
gnu.org, so what's on sources should be updated. Since I'm about to make
a few other small changes for the 1.4.2 release, you might want to wait
till those are done so you only have to do the merge once.
	
	- rob -

limits.h bug in gcc

[Rob Savoye]

On Wed, Sep 12, 2001 at 07:54:45PM +0200, Gerald Pfeifer wrote:

> That would be great, thanks!  (Would you mind sending the announcement
> also to gcc@gcc.gnu.org in this case?)

  This is probably a stupid question, but is gcc 3.0.1 going to be fixed so
it'll build as a cross compiler ? I'm trying to get it to build for arm-elf
or sh-elf, so I can test the cross testing support in DejaGnu. I saw the same
bug in GCC 3.0, where the script that generates the limits.h file was hardcoded
to only work on a native system.

  I guess I'll drop back to gcc 2.95.3 to build a cross complier, but I was
hoping 3.0.1 would have this fixed. Gcc 3.0.1 also doesn't build natively with
--enable-threads either... 
  
                 from ../../../../gcc-3.0.1/gcc/libgcc2.c:1166:
/home/rob/projects/gnu/obj/redhat/arm-elf/gcc/include/limits.h:125:75: limits.h: No such file or directory
make[2]: *** [libgcc/./_fixunsdfsi.o] Error 1

	- rob -

Re: limits.h bug in gcc

[Andrew Stubbs]

On Wed, 12 Sep 2001 rob@welcomehome.org wrote:

> On Wed, Sep 12, 2001 at 07:54:45PM +0200, Gerald Pfeifer wrote:
> 
> > That would be great, thanks!  (Would you mind sending the announcement
> > also to gcc@gcc.gnu.org in this case?)
> 
>   This is probably a stupid question, but is gcc 3.0.1 going to be fixed so
> it'll build as a cross compiler ? I'm trying to get it to build for arm-elf
> or sh-elf, so I can test the cross testing support in DejaGnu. I saw the same
> bug in GCC 3.0, where the script that generates the limits.h file was hardcoded
> to only work on a native system.
> 
>   I guess I'll drop back to gcc 2.95.3 to build a cross complier, but I was
> hoping 3.0.1 would have this fixed. Gcc 3.0.1 also doesn't build natively with
> --enable-threads either... 
>   
>                  from ../../../../gcc-3.0.1/gcc/libgcc2.c:1166:
> /home/rob/projects/gnu/obj/redhat/arm-elf/gcc/include/limits.h:125:75: limits.h: No such file or directory
> make[2]: *** [libgcc/./_fixunsdfsi.o] Error 1
> 
> 	- rob -

I have absolutly no trouble building and using an sh-elf cross compiler
under cygwin, solaris and linux using newlib. I have successfully built
both 3.0 and 3.0.1. As far as I am concerned the target can be added to
the list on the web site.

On the other hand I did have a lot of trouble getting dejagnu working - I
have managed to get it cobbled together after a lot of grief so that it
works. Best of luck fixing it!

------------------------------------------------------------------------
|  Andrew Stubbs,                   |  E-mail: Andrew.Stubbs@st.com    |
|  STMicroelectronics Ltd.,         |  or      stubbsa@bristol.st.com  |
|  1000 Aztec West,                 |                                  |
|  Almondsbury,                     |  Tel:    +44 (0)1454 462325      |
|  Bristol, BS32 4SQ, U.K.          |  Fax:    +44 (0)1454 617910      |
------------------------------------------------------------------------

Re: limits.h bug in gcc

[Rob Savoye]

On Thu, Sep 13, 2001 at 12:53:50PM +0100, Andrew Stubbs wrote:

> I have absolutly no trouble building and using an sh-elf cross compiler
> under cygwin, solaris and linux using newlib. I have successfully built
> both 3.0 and 3.0.1. As far as I am concerned the target can be added to
> the list on the web site.

  I guess I should be more specific. libstdc++-v3 wouldn't build in gcc 3.0,
but xgcc itself always did. The mknumeric_limits script was setup to only
work natively. 3.0.1 did build after I played around with the configure
arguments some, so I'm happy now.

	- rob -

Re: limits.h bug in gcc

[Andrew Stubbs]

On Thu, 13 Sep 2001 rob@welcomehome.org wrote:

> On Thu, Sep 13, 2001 at 12:53:50PM +0100, Andrew Stubbs wrote:
> 
> > I have absolutly no trouble building and using an sh-elf cross compiler
> > under cygwin, solaris and linux using newlib. I have successfully built
> > both 3.0 and 3.0.1. As far as I am concerned the target can be added to
> > the list on the web site.
> 
>   I guess I should be more specific. libstdc++-v3 wouldn't build in gcc 3.0,
> but xgcc itself always did. The mknumeric_limits script was setup to only
> work natively. 3.0.1 did build after I played around with the configure
> arguments some, so I'm happy now.

I'll believe you about the script, but I've never had any trouble. I
configure it with --enable-languages=c,c++ and there are no other c++
libraries present so I guess it must be using it. I can compile hello
world (and therefore the standard c++ library), but I must admit I havn't
really done much more.

For C on the other hand I am more certain it works - in particular I have
used it to build the SHLinux kernel (doesn't really test the run time
libraries though).

------------------------------------------------------------------------
|  Andrew Stubbs,                   |  E-mail: Andrew.Stubbs@st.com    |
|  STMicroelectronics Ltd.,         |  or      stubbsa@bristol.st.com  |
|  1000 Aztec West,                 |                                  |
|  Almondsbury,                     |  Tel:    +44 (0)1454 462325      |
|  Bristol, BS32 4SQ, U.K.          |  Fax:    +44 (0)1454 617910      |
------------------------------------------------------------------------

RE: limits.h bug in gcc

[GNUTeam]

Hi!!!

I am also trying to build the gcc 3.0 and gcc 3.0.1 for sh-elf, sh-hms and
sh-coff targets on cygwin. Sh-elf target build successfully for both without
my changing any script. But the sh-coff and sh-hms are failing in build of
library libstdc++-v3.

Rob can you please send me what all changes you have done in configure
script, so that I can try that change for sh-hms and sh-coff and see whether
they built. I am building these targets for languages c and c++. The build
for sh-hms and sh-coff for only C is successful.

The error what I am getting is that the PC stops  after the 'checking for
working strncmp...' statement.

checking whether we are using GNU C... (cached) yes
checking whether
/home/kpit/sh-hmsbld3.0.1/build-gcc-3.0.1/gcc/xgcc -B/home/kpit
/sh-hmsbld3.0.1/build-gcc-3.0.1/gcc/ -nostdinc -B/home/kpit/sh-hmsbld3.0.1/b
uild
-gcc-3.0.1/sh-hms/newlib/ -isystem
/home/kpit/sh-hmsbld3.0.1/build-gcc-3.0.1/sh-
hms/newlib/targ-include -isystem
/home/kpit/src/gcc-3.0.1/newlib/libc/include -B
/usr/sh-hms3.0.1/sh-hms/bin/ -B/usr/sh-hms3.0.1/sh-hms/lib/ -isystem
/usr/sh-hms
3.0.1/sh-hms/include accepts -g... (cached) yes
checking for POSIXized ISC... no
checking for working const... yes
checking for sys/file.h... yes
checking for sys/param.h... yes
checking for limits.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for unistd.h... yes
checking for strings.h... no
checking for sys/time.h... yes
checking for time.h... yes
checking for sys/resource.h... yes
checking for sys/stat.h... yes
checking for sys/mman.h... no
checking for fcntl.h... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether errno must be declared... no
checking for unistd.h... (cached) yes
checking for getpagesize... no
checking for working mmap... no
checking for working strncmp...

Thanks & Regards
Rekha

-----Original Message-----
From: gcc-bugs-owner@gcc.gnu.org [ mailto:gcc-bugs-owner@gcc.gnu.org]On
Behalf Of Rob Savoye
Sent: Thursday, September 13, 2001 8:30 PM
To: Andrew Stubbs
Cc: gcc@gcc.gnu.org; gcc-bugs@gcc.gnu.org
Subject: Re: limits.h bug in gcc


On Thu, Sep 13, 2001 at 12:53:50PM +0100, Andrew Stubbs wrote:

> I have absolutly no trouble building and using an sh-elf cross compiler
> under cygwin, solaris and linux using newlib. I have successfully built
> both 3.0 and 3.0.1. As far as I am concerned the target can be added to
> the list on the web site.

  I guess I should be more specific. libstdc++-v3 wouldn't build in gcc 3.0,
but xgcc itself always did. The mknumeric_limits script was setup to only
work natively. 3.0.1 did build after I played around with the configure
arguments some, so I'm happy now.

	- rob -

RE: limits.h bug in gcc

[Andrew Stubbs]

On Fri, 14 Sep 2001 gnuteam@kpit.com wrote:

> Hi!!!
> 
> I am also trying to build the gcc 3.0 and gcc 3.0.1 for sh-elf, sh-hms and
> sh-coff targets on cygwin. Sh-elf target build successfully for both without
> my changing any script. But the sh-coff and sh-hms are failing in build of
> library libstdc++-v3.
> 
> Rob can you please send me what all changes you have done in configure
> script, so that I can try that change for sh-hms and sh-coff and see whether
> they built. I am building these targets for languages c and c++. The build
> for sh-hms and sh-coff for only C is successful.
> 
> The error what I am getting is that the PC stops  after the 'checking for
> working strncmp...' statement.

Yes, I get that problem occassionally. It doesn't seem to be consistent.
It causes the cygwin/dos window to change size and lose it's scroll bars
and then the cursor moves around the screen randomly at short intervals -
very odd. strncmp does work (I think) and indeed the test seems to pass
sometimes, so I just set the environment variable
ac_cv_func_strncmp_works=yes so it skips the test.

Perhaps smebody ought to do something about this, but it doesn't seem to
affect the end product. It only ever happens on Windows.

------------------------------------------------------------------------
|  Andrew Stubbs,                   |  E-mail: Andrew.Stubbs@st.com    |
|  STMicroelectronics Ltd.,         |  or      stubbsa@bristol.st.com  |
|  1000 Aztec West,                 |                                  |
|  Almondsbury,                     |  Tel:    +44 (0)1454 462325      |
|  Bristol, BS32 4SQ, U.K.          |  Fax:    +44 (0)1454 617910      |
------------------------------------------------------------------------

RE: limits.h bug in gcc

[GNUTeam]

Hi!!

Thanks a lot for the reply. I will just try the build by skipping the test
by following your instructions.

Thanks & Regards
Rekha

-----Original Message-----
From: Andrew Stubbs [ mailto:Andrew.Stubbs@st.com ]
Sent: Friday, September 14, 2001 2:09 PM
To: gnuteam@kpit.com
Cc: rob@welcomehome.org; gcc@gcc.gnu.org; gcc-bugs@gcc.gnu.org
Subject: RE: limits.h bug in gcc


On Fri, 14 Sep 2001 gnuteam@kpit.com wrote:

> Hi!!!
>
> I am also trying to build the gcc 3.0 and gcc 3.0.1 for sh-elf, sh-hms and
> sh-coff targets on cygwin. Sh-elf target build successfully for both
without
> my changing any script. But the sh-coff and sh-hms are failing in build of
> library libstdc++-v3.
>
> Rob can you please send me what all changes you have done in configure
> script, so that I can try that change for sh-hms and sh-coff and see
whether
> they built. I am building these targets for languages c and c++. The build
> for sh-hms and sh-coff for only C is successful.
>
> The error what I am getting is that the PC stops  after the 'checking for
> working strncmp...' statement.

Yes, I get that problem occassionally. It doesn't seem to be consistent.
It causes the cygwin/dos window to change size and lose it's scroll bars
and then the cursor moves around the screen randomly at short intervals -
very odd. strncmp does work (I think) and indeed the test seems to pass
sometimes, so I just set the environment variable
ac_cv_func_strncmp_works=yes so it skips the test.

Perhaps smebody ought to do something about this, but it doesn't seem to
affect the end product. It only ever happens on Windows.

------------------------------------------------------------------------
|  Andrew Stubbs,                   |  E-mail: Andrew.Stubbs@st.com    |
|  STMicroelectronics Ltd.,         |  or      stubbsa@bristol.st.com  |
|  1000 Aztec West,                 |                                  |
|  Almondsbury,                     |  Tel:    +44 (0)1454 462325      |
|  Bristol, BS32 4SQ, U.K.          |  Fax:    +44 (0)1454 617910      |
------------------------------------------------------------------------

Re: limits.h bug in gcc

[Benjamin Kosnik]

> This is probably a stupid question, but is gcc 3.0.1 going to be
> fixed so it'll build as a cross compiler ? I'm trying to get it to
> build for arm-elf or sh-elf,

Rob, I strongly suggest trying to get powerpc-eabism working
first. For one thing, the ARM backend is not supported in gcc-3.0:

http://gcc.gnu.org/gcc-3.0/buildstat.html

You'll have better lucking picking backends that are represented on this list.

For another thing, the regression tester uses powerpc-eabism, so it
usually works. Look through this list and see when it's working:

http://gcc.gnu.org/ml/gcc-regression/2001-09/


best,
benjamin