Re: 1.1.2 Prerelease

Re: 1.1.2 Prerelease

[Santos Halpar]

nbecker@fred.net wrote:
> I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.
> I will then build glibc-2.1.  I think I need to now rebuild 
> libstdc++-2.9, right?

That's what the rumor around the campfire is.  I'd rebuild libstdc++
after installing glibc-2.1.

> I will then try installing glibc-2.1 and (assuming I'm not dead yet) 
> see if the binaries still work.
>
> If glibc-2.1 install breaks everything, is there an easier way to
> remove it, other than restore everything from tape?

Been there, done that -- one of the 2.1 betas failed to function for
me.  Thankfully, I had copied the previous contents of /lib over to
another partition and had saved an "ls -al" of /lib to ensure I knew
where the symlinks had to point (ldconfig is statically linked on my
system, but it's nice to have a sanity check).

Since then, I've done two things:

1.  Use LD_PRELOAD and LD_LIBRARY_PATH promiscuously when testing new
libraries.  Build glibc-2.1, add the glibc build directory to the
front of LD_LIBRARY_PATH, and try running something.  e.g:

(LD_LIBRARY_PATH=/tmp/glibc-build:$LD_LIBRARY_PATH /bin/ls)

for zsh/bash/ksh.  [t]csh needs setenv, I guess.  This works quite
well.

2.  Keep a minimal bootable setup on a second partition.  Probably a
good idea anyway.  Or keep some rescue disks with a kernel that can
access your hardware around.  Or both.

No problems with glibc-2.1 final release (though there may be some
legal issues that make it hard to find), built with egcs-1.1.1; I
replaced glibc-2.0.7 and things kept running fine (read the glibc
docs about updating ncurses et alia; I didn't have any problems with
ncurses, but I rebuilt it anyway just to be safe).

--Sumner Hayes

this e-mail address may expire 1 April 1999; username pthisis, also
at yahoo.com, can be used to contact me after that time.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: 1.1.2 Prerelease

[Andris Pavenis]

On Thu, 18 Feb 1999, Santos Halpar wrote:
>nbecker@fred.net wrote:
>> I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.
>> I will then build glibc-2.1.  I think I need to now rebuild 
>> libstdc++-2.9, right?
>
>That's what the rumor around the campfire is.  I'd rebuild libstdc++
>after installing glibc-2.1.
>
>> I will then try installing glibc-2.1 and (assuming I'm not dead yet) 
>> see if the binaries still work.
>>
>> If glibc-2.1 install breaks everything, is there an easier way to
>> remove it, other than restore everything from tape?
>
>Been there, done that -- one of the 2.1 betas failed to function for
>me.  Thankfully, I had copied the previous contents of /lib over to
>another partition and had saved an "ls -al" of /lib to ensure I knew
>where the symlinks had to point (ldconfig is statically linked on my
>system, but it's nice to have a sanity check).

I perhaps have done something slightly more difficult:

upgraded to glibc-2.1 directly from libc-5.4.46. 
  - I downloaded glibc2 binaries of X11, Netscape;
  - rebuilt egcs-2.91.60.1 19990115/Linux (egcs-1.1.1 release).
  - rebuilt ncurses
  - rebuilt Qt-1.42, KDE-1.1, groff and many other packages (the Linux
     distribution were Slackware-3.6)

I currently don't see reason to return back, but it's very common that packages
needs hacking to be built with glibc-2.1 and 2.2.X kernels. 

So today I found that ftpd does not work. So I rebuilt latest version but
I needed to patch it in one place to get it built at all. (Possible workaround
for many problems is -D__NO_STRING_INLINES)

Andris

Re: 1.1.2 Prerelease

[Santos Halpar]

nbecker@fred.net wrote:
> I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.
> I will then build glibc-2.1.  I think I need to now rebuild 
> libstdc++-2.9, right?

That's what the rumor around the campfire is.  I'd rebuild libstdc++
after installing glibc-2.1.

> I will then try installing glibc-2.1 and (assuming I'm not dead yet) 
> see if the binaries still work.
>
> If glibc-2.1 install breaks everything, is there an easier way to
> remove it, other than restore everything from tape?

Been there, done that -- one of the 2.1 betas failed to function for
me.  Thankfully, I had copied the previous contents of /lib over to
another partition and had saved an "ls -al" of /lib to ensure I knew
where the symlinks had to point (ldconfig is statically linked on my
system, but it's nice to have a sanity check).

Since then, I've done two things:

1.  Use LD_PRELOAD and LD_LIBRARY_PATH promiscuously when testing new
libraries.  Build glibc-2.1, add the glibc build directory to the
front of LD_LIBRARY_PATH, and try running something.  e.g:

(LD_LIBRARY_PATH=/tmp/glibc-build:$LD_LIBRARY_PATH /bin/ls)

for zsh/bash/ksh.  [t]csh needs setenv, I guess.  This works quite
well.

2.  Keep a minimal bootable setup on a second partition.  Probably a
good idea anyway.  Or keep some rescue disks with a kernel that can
access your hardware around.  Or both.

No problems with glibc-2.1 final release (though there may be some
legal issues that make it hard to find), built with egcs-1.1.1; I
replaced glibc-2.0.7 and things kept running fine (read the glibc
docs about updating ncurses et alia; I didn't have any problems with
ncurses, but I rebuilt it anyway just to be safe).

--Sumner Hayes

this e-mail address may expire 1 April 1999; username pthisis, also
at yahoo.com, can be used to contact me after that time.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: 1.1.2 Prerelease

[Andris Pavenis]

On Thu, 18 Feb 1999, Santos Halpar wrote:
>nbecker@fred.net wrote:
>> I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.
>> I will then build glibc-2.1.  I think I need to now rebuild 
>> libstdc++-2.9, right?
>
>That's what the rumor around the campfire is.  I'd rebuild libstdc++
>after installing glibc-2.1.
>
>> I will then try installing glibc-2.1 and (assuming I'm not dead yet) 
>> see if the binaries still work.
>>
>> If glibc-2.1 install breaks everything, is there an easier way to
>> remove it, other than restore everything from tape?
>
>Been there, done that -- one of the 2.1 betas failed to function for
>me.  Thankfully, I had copied the previous contents of /lib over to
>another partition and had saved an "ls -al" of /lib to ensure I knew
>where the symlinks had to point (ldconfig is statically linked on my
>system, but it's nice to have a sanity check).

I perhaps have done something slightly more difficult:

upgraded to glibc-2.1 directly from libc-5.4.46. 
  - I downloaded glibc2 binaries of X11, Netscape;
  - rebuilt egcs-2.91.60.1 19990115/Linux (egcs-1.1.1 release).
  - rebuilt ncurses
  - rebuilt Qt-1.42, KDE-1.1, groff and many other packages (the Linux
     distribution were Slackware-3.6)

I currently don't see reason to return back, but it's very common that packages
needs hacking to be built with glibc-2.1 and 2.2.X kernels. 

So today I found that ftpd does not work. So I rebuilt latest version but
I needed to patch it in one place to get it built at all. (Possible workaround
for many problems is -D__NO_STRING_INLINES)

Andris

Re: 1.1.2 Prerelease

[Jeffrey A Law]

  In message <14031.11407.718834.375650@arthur.rhein-neckar.de>you write:
  > >>>>> Jeffrey A Law writes:
  > 
  > Jeff>   In message <u8ogmoalq0.fsf@arthur.rhein-neckar.de>you write:
  > >> With egcs 1.1.1 (egcs-2.91.60 19981201):
  > >> $ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
  > >> #define _UFC_32_  
  > Jeff> Odd:
  > 
  > Jeff> gcc -V egcs-2.91.60 -dM -E foo.c | grep UFC
  > Jeff> foo.c:5: warning: integer constant out of range
  > Jeff> #define _UFC_64_  
  > 
  > Indeed odd.
  > 
  > Jeff> gcc -v -V egcs-2.91.60
  > Jeff> Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.
  > 60/specs
  > Jeff> gcc driver version egcs-2.93.06 19990212 (gcc2 ss-980929 experimental
  > ) executing gcc version egcs-2.91.60
  > 
  > Jeff> Seems to me like your egcs-1.1.1 installation is behaving differently
  >  than
  > Jeff> it probably should.
  > 
  > Are you sure?  IMHO the test UINT_FAST32_MAX == UINT_FAST64_MAX should
  > be false and therefore _UFC_32_ should be defined.  Or does the
  > warning warns me that I've got undefined behaviour here?
Hmmm, unsure.

  > My question remains is glibc 2.1 broken which uses the construct?
It's unclear how much precision in a number one can actually rely on in cpp
and the compiler it's dependent on the host word size to some extent.

While we've been working on improving support for 64bit numbers in the
preprocessor, I wouldn't be at all suprised if problems still remain after
the recent flurry of fixes.

jeff

Re: 1.1.2 Prerelease

[Jeffrey A Law]

  In message <14031.11407.718834.375650@arthur.rhein-neckar.de>you write:
  > >>>>> Jeffrey A Law writes:
  > 
  > Jeff>   In message <u8ogmoalq0.fsf@arthur.rhein-neckar.de>you write:
  > >> With egcs 1.1.1 (egcs-2.91.60 19981201):
  > >> $ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
  > >> #define _UFC_32_  
  > Jeff> Odd:
  > 
  > Jeff> gcc -V egcs-2.91.60 -dM -E foo.c | grep UFC
  > Jeff> foo.c:5: warning: integer constant out of range
  > Jeff> #define _UFC_64_  
  > 
  > Indeed odd.
  > 
  > Jeff> gcc -v -V egcs-2.91.60
  > Jeff> Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.
  > 60/specs
  > Jeff> gcc driver version egcs-2.93.06 19990212 (gcc2 ss-980929 experimental
  > ) executing gcc version egcs-2.91.60
  > 
  > Jeff> Seems to me like your egcs-1.1.1 installation is behaving differently
  >  than
  > Jeff> it probably should.
  > 
  > Are you sure?  IMHO the test UINT_FAST32_MAX == UINT_FAST64_MAX should
  > be false and therefore _UFC_32_ should be defined.  Or does the
  > warning warns me that I've got undefined behaviour here?
Hmmm, unsure.

  > My question remains is glibc 2.1 broken which uses the construct?
It's unclear how much precision in a number one can actually rely on in cpp
and the compiler it's dependent on the host word size to some extent.

While we've been working on improving support for 64bit numbers in the
preprocessor, I wouldn't be at all suprised if problems still remain after
the recent flurry of fixes.

jeff

Re: 1.1.2 Prerelease

[Jeffrey A Law]

  In message < x88d837yh5l.fsf@nbeckerpc.hns.com >you write:
  > I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I 
  > will then build glibc-2.1.  I think I need to now rebuild
  > libstdc++-2.9, right?
If you install glibc-2.1, then I think you need to rebuild libstdc++, yes.


  > I will then build some c++ binaries.  I
  > will then try installing glibc-2.1 and (assuming I'm not dead yet) see 
  > if the binaries still work.
  > 
  > If glibc-2.1 install breaks everything, is there an easier way to
  > remove it, other than restore everything from tape?
I would think you could build glibc, run its internal tests (make check)
before taking the plunge and installing it.

Once it's installed?  No idea how to recover.    Presumably there's some
statically linked programs in /sbin that you can use to put humpty dumpty
back together again.


jeff

Re: 1.1.2 Prerelease

[Jeffrey A Law]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

  In message < 199902180006.BAA01080@mira.isdn.cs.tu-berlin.de >you write:
  > > Comments and suggestions would be greatly appreciated.
  > 
  > I noticed there aren't that many C++ fixes. The specific one I'd like
  > to see in 1.1.2 is
  > 
  > 1999-01-25  Martin von Löwis  <loewis@informatik.hu-berlin.de>
  > 
  > 	* tree.c (equal_functions): New function.
  > 	(ovl_member): Call it.
  > 
  > This is a quality-of-implementation issue: Compile time will be
  > significantly reduced. I have not seen bug reports related to it
  > since it got into the development branch.
Installed.

Can you give me a quick description of when it will reduce compile-time
for inclusion in the egcs-1.1.2 announcement?  One or two sentences is all
I'm looking for.

Thanks,
jeff

Re: 1.1.2 Prerelease

[Adam Moyes]

Adam Moyes wrote:
> 
> Jeffrey A Law wrote:
> >
> >   In message < x88d837yh5l.fsf@nbeckerpc.hns.com >you write:
> >   > I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I
> >   > will then build glibc-2.1.  I think I need to now rebuild
> >   > libstdc++-2.9, right?
> > If you install glibc-2.1, then I think you need to rebuild libstdc++, yes.
> >
> 
> libstdc++ is contained (and built) in the glibc-2.1 distribution. However
> for some programs (Netscape is one I think) you might need libg++. This
> has to be put in the build tree for glibc-2.1 before you start the build
> if you want it.
> 
Oops, oops, damn!!

CORECTION.
It is contained the the egcs-1.1.1 distribution. I upgraded both libc and
gcc at the same time, so I got a bit mixed up.

Sorry guys.

Adam.
-- 
Signs of crime: screaming or cries for help.
                -- from the Brown Security Crime Prevention Pamphlet

Re: 1.1.2 Prerelease

[Jeffrey A Law]

  In message < u8ogmoalq0.fsf@arthur.rhein-neckar.de >you write:
  > With egcs 1.1.1 (egcs-2.91.60 19981201):
  > $ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
  > #define _UFC_32_  
Odd:

gcc -V egcs-2.91.60 -dM -E foo.c | grep UFC
foo.c:5: warning: integer constant out of range
#define _UFC_64_  

gcc -v -V egcs-2.91.60
Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/specs
gcc driver version egcs-2.93.06 19990212 (gcc2 ss-980929 experimental) executing gcc version egcs-2.91.60

Seems to me like your egcs-1.1.1 installation is behaving differently than
it probably should.


jeff

1.1.2 Prerelease

[Jeffrey A Law]

I've put a pre-release of egcs-1.1.2 in the pub/egcs/snapshots directory
"egcs-1.1.2-prerelease" on the egcs ftp server.

I suspect we'll have a second pre-release later this week to wrap up the few
remaining open issues (cpp script, file initializer scopes, doc updates, etc).

I'd like to be sure that egcs-1.1.2 will correctly compile both glibc-2.1
and linux-2.2.1 on the major Linux architectures (x86, alpha, powerpc, sparc).

So if folks could make a point to build & test glibc-2.1 and linux-2.2.1 
kernels on those architectures with the prerelease it would be greatly
appreciated.

The prototype announcement for egcs-1.1.2 is available at

http://www.cygnus.com/egcs/egcs-1.1/egcs-1.1.2.html

Comments and suggestions would be greatly appreciated.

jeff

ps. I'm pretty happy with the state of the language front-ends for egcs-1.1.2,
but if the language mantainers have critical bugs they want to fix, we do have
time.

pps.  egcs-1.1.2 is projected as the last release in the egcs-1.1 series.  Our
focus will turn to egcs-1.2 in the immediate future.

Re: 1.1.2 Prerelease

[Martin v. Loewis]

> Can you give me a quick description of when it will reduce compile-time
> for inclusion in the egcs-1.1.2 announcement?  One or two sentences is all
> I'm looking for.

It reduces compile time when the program calls overloaded
functions. That should be pretty much every C++ program.

Martin

Re: 1.1.2 Prerelease

[Andreas Jaeger]

>>>>> Jeffrey A Law writes:

Jeff>   In message < u8ogmoalq0.fsf@arthur.rhein-neckar.de >you write:
>> With egcs 1.1.1 (egcs-2.91.60 19981201):
>> $ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
>> #define _UFC_32_  
Jeff> Odd:

Jeff> gcc -V egcs-2.91.60 -dM -E foo.c | grep UFC
Jeff> foo.c:5: warning: integer constant out of range
Jeff> #define _UFC_64_  

Indeed odd.

Jeff> gcc -v -V egcs-2.91.60
Jeff> Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/specs
Jeff> gcc driver version egcs-2.93.06 19990212 (gcc2 ss-980929 experimental) executing gcc version egcs-2.91.60

Jeff> Seems to me like your egcs-1.1.1 installation is behaving differently than
Jeff> it probably should.

Are you sure?  IMHO the test UINT_FAST32_MAX == UINT_FAST64_MAX should
be false and therefore _UFC_32_ should be defined.  Or does the
warning warns me that I've got undefined behaviour here?

My question remains is glibc 2.1 broken which uses the construct?

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: 1.1.2 Prerelease

[Toon Moene]

I just built:

[toon@moene LAPACK]$ /usr/rel/bin/gcc -v
Reading specs from
/usr/rel/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.61/specs
gcc version egcs-2.91.61 19990216 (egcs-1.1.2 pre-release-1)

It passed the LAPACK tests with the following compile time options:

-g -O3 -funroll-loops -fomit-frame-pointer -fno-emulate-complex
-malign-double

Tonight I'll run our NWP code with it.  If you don't hear otherwise,
assume it successful.

I use the following options for that:

-g -O2 -malign-double -ffast-math -fomit-frame-pointer -funroll-loops
-Wall -Wsurprising -funix-intrinsics-hide

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: 1.1.2 Prerelease

[Paul Derbyshire]

At 10:31 PM 2/18/99 +0100, you wrote:

>-g -O2 -malign-double -ffast-math -fomit-frame-pointer -funroll-loops
>-Wall -Wsurprising -funix-intrinsics-hide

-Wsurprising???? Is this a joke or is there really such a warning option
(and what does it do)?



-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: 1.1.2 Prerelease

[Andreas Jaeger]

>>>>> Jeffrey A Law writes:

 > I've put a pre-release of egcs-1.1.2 in the pub/egcs/snapshots directory
 > "egcs-1.1.2-prerelease" on the egcs ftp server.

 > I suspect we'll have a second pre-release later this week to wrap up the few
 > remaining open issues (cpp script, file initializer scopes, doc updates, etc).

 > I'd like to be sure that egcs-1.1.2 will correctly compile both glibc-2.1
 > and linux-2.2.1 on the major Linux architectures (x86, alpha, powerpc, sparc).

 > So if folks could make a point to build & test glibc-2.1 and linux-2.2.1 
 > kernels on those architectures with the prerelease it would be greatly
 > appreciated.

I've compiled and installed the prerelease successully but noticed the 
following warning compiling glibc 2.1:
../crypt/sysdeps/unix/ufc-crypt.h:25: warning: integer constant out of range

This can be reproduced with the following small file:
# define UINT_FAST32_MAX        (4294967295U)
# define UINT_FAST64_MAX        (18446744073709551615ULL)

#if UINT_FAST32_MAX == UINT_FAST64_MAX
# define _UFC_64_
#else
# define _UFC_32_
#endif

With egcs 1.1.1 (egcs-2.91.60 19981201):
$ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
#define _UFC_32_  

With the prerelease (egcs-2.91.61 19990216)
$ /opt/egcs/bin/gcc  -V egcs-2.91.61 -dM -E test-egcs.c  |grep UFC
test-egcs.c:4: warning: integer constant out of range
#define _UFC_64_  

The current egcs 1.2 CVS version (egcs-2.93.08 19990216) [1]

$ /opt/egcs-1.2/bin/gcc   -dM -E test-egcs.c  
test-egcs.c:4:39: warning: integer constant out of range

With gcc 2.7.2.3:
$ gcc   -dM -E test-egcs.c  |grep UFC
test-egcs.c:4: two `l's in integer constant
#define _UFC_32_  


Please note that egcs 1.1.2 defines _UFC_64_ but the other compilers
define _UFC_32_.

I don't know if this is correct.  Since this is a change of behaviour
in the test environment (glibc 2.1), I'd like to know if glibc needs
to be fixed and if egcs is ok.

Andreas

Footnotes: 
[1]  Using --enable-c-cpp-lib which might be the reason that the
     define is not output.  I'm not sure if this counts as an error.

-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: 1.1.2 Prerelease

[H.J. Lu]

> 
> 
> I'd like to be sure that egcs-1.1.2 will correctly compile both glibc-2.1
> and linux-2.2.1 on the major Linux architectures (x86, alpha, powerpc, sparc).
> 

Just for the record, please try to build egcs 1.1.2 on a glibc 2.0
based Linux/x86 system and build a few C++ applications, groff should
be ok. Then install glibc 2.1 and rebuild egcs 1.1.2. Now try to see
if the old groff binaries still work. "man fopen" will do. I have no
idea how to make a simple testcase out of it. Even if I did, I am
afraid noone, but who work on symbol versioning in glibc, would
understand what is going on.

BTW, my library versioing patch is created to deal with this problem.



H.J.

Re: 1.1.2 Prerelease

[nbecker]

>>>>> "Adam" == Adam Moyes <adam@macfar.demon.co.uk> writes:

    Adam> Jeffrey A Law wrote:
    >> 
    >> In message < x88d837yh5l.fsf@nbeckerpc.hns.com >you write:
    >> > I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I
    >> > will then build glibc-2.1.  I think I need to now rebuild
    >> > libstdc++-2.9, right?
    >> If you install glibc-2.1, then I think you need to rebuild libstdc++, yes.
    >> 

    Adam> libstdc++ is contained (and built) in the glibc-2.1 distribution. However
    Adam> for some programs (Netscape is one I think) you might need libg++. This
    Adam> has to be put in the build tree for glibc-2.1 before you start the build
    Adam> if you want it.

Are you sure?  I thought libstdc++ came from egcs distribution.

Re: 1.1.2 Prerelease

[nbecker]

I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I 
will then build glibc-2.1.  I think I need to now rebuild
libstdc++-2.9, right?

I will then build some c++ binaries.  I
will then try installing glibc-2.1 and (assuming I'm not dead yet) see 
if the binaries still work.

If glibc-2.1 install breaks everything, is there an easier way to
remove it, other than restore everything from tape?

Re: 1.1.2 Prerelease

[Mumit Khan]

Paul Derbyshire <pderbysh@usa.net> writes:
> At 10:31 PM 2/18/99 +0100, you wrote:
> 
> >-g -O2 -malign-double -ffast-math -fomit-frame-pointer -funroll-loops
> >-Wall -Wsurprising -funix-intrinsics-hide
> 
> -Wsurprising???? Is this a joke or is there really such a warning option
> (and what does it do)?

Why not just look at the documentation? Since you're on egcs list, I'm 
going to assume you have access to it.

Regards,
Mumit

Re: 1.1.2 Prerelease

[Martin v. Loewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

> Comments and suggestions would be greatly appreciated.

I noticed there aren't that many C++ fixes. The specific one I'd like
to see in 1.1.2 is

1999-01-25  Martin von Löwis  <loewis@informatik.hu-berlin.de>

	* tree.c (equal_functions): New function.
	(ovl_member): Call it.

This is a quality-of-implementation issue: Compile time will be
significantly reduced. I have not seen bug reports related to it
since it got into the development branch.

Regards,
Martin

Re: 1.1.2 Prerelease

[Martin v. Loewis]

> Can you give me a quick description of when it will reduce compile-time
> for inclusion in the egcs-1.1.2 announcement?  One or two sentences is all
> I'm looking for.

It reduces compile time when the program calls overloaded
functions. That should be pretty much every C++ program.

Martin

Re: 1.1.2 Prerelease

[Jeffrey A Law]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

  In message < 199902180006.BAA01080@mira.isdn.cs.tu-berlin.de >you write:
  > > Comments and suggestions would be greatly appreciated.
  > 
  > I noticed there aren't that many C++ fixes. The specific one I'd like
  > to see in 1.1.2 is
  > 
  > 1999-01-25  Martin von Löwis  <loewis@informatik.hu-berlin.de>
  > 
  > 	* tree.c (equal_functions): New function.
  > 	(ovl_member): Call it.
  > 
  > This is a quality-of-implementation issue: Compile time will be
  > significantly reduced. I have not seen bug reports related to it
  > since it got into the development branch.
Installed.

Can you give me a quick description of when it will reduce compile-time
for inclusion in the egcs-1.1.2 announcement?  One or two sentences is all
I'm looking for.

Thanks,
jeff

Re: 1.1.2 Prerelease

[Andreas Jaeger]

>>>>> Jeffrey A Law writes:

Jeff>   In message < u8ogmoalq0.fsf@arthur.rhein-neckar.de >you write:
>> With egcs 1.1.1 (egcs-2.91.60 19981201):
>> $ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
>> #define _UFC_32_  
Jeff> Odd:

Jeff> gcc -V egcs-2.91.60 -dM -E foo.c | grep UFC
Jeff> foo.c:5: warning: integer constant out of range
Jeff> #define _UFC_64_  

Indeed odd.

Jeff> gcc -v -V egcs-2.91.60
Jeff> Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/specs
Jeff> gcc driver version egcs-2.93.06 19990212 (gcc2 ss-980929 experimental) executing gcc version egcs-2.91.60

Jeff> Seems to me like your egcs-1.1.1 installation is behaving differently than
Jeff> it probably should.

Are you sure?  IMHO the test UINT_FAST32_MAX == UINT_FAST64_MAX should
be false and therefore _UFC_32_ should be defined.  Or does the
warning warns me that I've got undefined behaviour here?

My question remains is glibc 2.1 broken which uses the construct?

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: 1.1.2 Prerelease

[Jeffrey A Law]

  In message < u8ogmoalq0.fsf@arthur.rhein-neckar.de >you write:
  > With egcs 1.1.1 (egcs-2.91.60 19981201):
  > $ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
  > #define _UFC_32_  
Odd:

gcc -V egcs-2.91.60 -dM -E foo.c | grep UFC
foo.c:5: warning: integer constant out of range
#define _UFC_64_  

gcc -v -V egcs-2.91.60
Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/specs
gcc driver version egcs-2.93.06 19990212 (gcc2 ss-980929 experimental) executing gcc version egcs-2.91.60

Seems to me like your egcs-1.1.1 installation is behaving differently than
it probably should.


jeff

Re: 1.1.2 Prerelease

[Andreas Jaeger]

>>>>> Jeffrey A Law writes:

 > I've put a pre-release of egcs-1.1.2 in the pub/egcs/snapshots directory
 > "egcs-1.1.2-prerelease" on the egcs ftp server.

 > I suspect we'll have a second pre-release later this week to wrap up the few
 > remaining open issues (cpp script, file initializer scopes, doc updates, etc).

 > I'd like to be sure that egcs-1.1.2 will correctly compile both glibc-2.1
 > and linux-2.2.1 on the major Linux architectures (x86, alpha, powerpc, sparc).

 > So if folks could make a point to build & test glibc-2.1 and linux-2.2.1 
 > kernels on those architectures with the prerelease it would be greatly
 > appreciated.

I've compiled and installed the prerelease successully but noticed the 
following warning compiling glibc 2.1:
../crypt/sysdeps/unix/ufc-crypt.h:25: warning: integer constant out of range

This can be reproduced with the following small file:
# define UINT_FAST32_MAX        (4294967295U)
# define UINT_FAST64_MAX        (18446744073709551615ULL)

#if UINT_FAST32_MAX == UINT_FAST64_MAX
# define _UFC_64_
#else
# define _UFC_32_
#endif

With egcs 1.1.1 (egcs-2.91.60 19981201):
$ /opt/egcs/bin/gcc  -V egcs-2.91.60 -dM -E test-egcs.c  |grep UFC
#define _UFC_32_  

With the prerelease (egcs-2.91.61 19990216)
$ /opt/egcs/bin/gcc  -V egcs-2.91.61 -dM -E test-egcs.c  |grep UFC
test-egcs.c:4: warning: integer constant out of range
#define _UFC_64_  

The current egcs 1.2 CVS version (egcs-2.93.08 19990216) [1]

$ /opt/egcs-1.2/bin/gcc   -dM -E test-egcs.c  
test-egcs.c:4:39: warning: integer constant out of range

With gcc 2.7.2.3:
$ gcc   -dM -E test-egcs.c  |grep UFC
test-egcs.c:4: two `l's in integer constant
#define _UFC_32_  


Please note that egcs 1.1.2 defines _UFC_64_ but the other compilers
define _UFC_32_.

I don't know if this is correct.  Since this is a change of behaviour
in the test environment (glibc 2.1), I'd like to know if glibc needs
to be fixed and if egcs is ok.

Andreas

Footnotes: 
[1]  Using --enable-c-cpp-lib which might be the reason that the
     define is not output.  I'm not sure if this counts as an error.

-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: 1.1.2 Prerelease

[Mumit Khan]

Paul Derbyshire <pderbysh@usa.net> writes:
> At 10:31 PM 2/18/99 +0100, you wrote:
> 
> >-g -O2 -malign-double -ffast-math -fomit-frame-pointer -funroll-loops
> >-Wall -Wsurprising -funix-intrinsics-hide
> 
> -Wsurprising???? Is this a joke or is there really such a warning option
> (and what does it do)?

Why not just look at the documentation? Since you're on egcs list, I'm 
going to assume you have access to it.

Regards,
Mumit

Re: 1.1.2 Prerelease

[Paul Derbyshire]

At 10:31 PM 2/18/99 +0100, you wrote:

>-g -O2 -malign-double -ffast-math -fomit-frame-pointer -funroll-loops
>-Wall -Wsurprising -funix-intrinsics-hide

-Wsurprising???? Is this a joke or is there really such a warning option
(and what does it do)?



-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: 1.1.2 Prerelease

[Adam Moyes]

Adam Moyes wrote:
> 
> Jeffrey A Law wrote:
> >
> >   In message < x88d837yh5l.fsf@nbeckerpc.hns.com >you write:
> >   > I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I
> >   > will then build glibc-2.1.  I think I need to now rebuild
> >   > libstdc++-2.9, right?
> > If you install glibc-2.1, then I think you need to rebuild libstdc++, yes.
> >
> 
> libstdc++ is contained (and built) in the glibc-2.1 distribution. However
> for some programs (Netscape is one I think) you might need libg++. This
> has to be put in the build tree for glibc-2.1 before you start the build
> if you want it.
> 
Oops, oops, damn!!

CORECTION.
It is contained the the egcs-1.1.1 distribution. I upgraded both libc and
gcc at the same time, so I got a bit mixed up.

Sorry guys.

Adam.
-- 
Signs of crime: screaming or cries for help.
                -- from the Brown Security Crime Prevention Pamphlet

Re: 1.1.2 Prerelease

[nbecker]

>>>>> "Adam" == Adam Moyes <adam@macfar.demon.co.uk> writes:

    Adam> Jeffrey A Law wrote:
    >> 
    >> In message < x88d837yh5l.fsf@nbeckerpc.hns.com >you write:
    >> > I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I
    >> > will then build glibc-2.1.  I think I need to now rebuild
    >> > libstdc++-2.9, right?
    >> If you install glibc-2.1, then I think you need to rebuild libstdc++, yes.
    >> 

    Adam> libstdc++ is contained (and built) in the glibc-2.1 distribution. However
    Adam> for some programs (Netscape is one I think) you might need libg++. This
    Adam> has to be put in the build tree for glibc-2.1 before you start the build
    Adam> if you want it.

Are you sure?  I thought libstdc++ came from egcs distribution.

Re: 1.1.2 Prerelease

[Toon Moene]

I just built:

[toon@moene LAPACK]$ /usr/rel/bin/gcc -v
Reading specs from
/usr/rel/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.61/specs
gcc version egcs-2.91.61 19990216 (egcs-1.1.2 pre-release-1)

It passed the LAPACK tests with the following compile time options:

-g -O3 -funroll-loops -fomit-frame-pointer -fno-emulate-complex
-malign-double

Tonight I'll run our NWP code with it.  If you don't hear otherwise,
assume it successful.

I use the following options for that:

-g -O2 -malign-double -ffast-math -fomit-frame-pointer -funroll-loops
-Wall -Wsurprising -funix-intrinsics-hide

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: 1.1.2 Prerelease

[Jeffrey A Law]

  In message < x88d837yh5l.fsf@nbeckerpc.hns.com >you write:
  > I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I 
  > will then build glibc-2.1.  I think I need to now rebuild
  > libstdc++-2.9, right?
If you install glibc-2.1, then I think you need to rebuild libstdc++, yes.


  > I will then build some c++ binaries.  I
  > will then try installing glibc-2.1 and (assuming I'm not dead yet) see 
  > if the binaries still work.
  > 
  > If glibc-2.1 install breaks everything, is there an easier way to
  > remove it, other than restore everything from tape?
I would think you could build glibc, run its internal tests (make check)
before taking the plunge and installing it.

Once it's installed?  No idea how to recover.    Presumably there's some
statically linked programs in /sbin that you can use to put humpty dumpty
back together again.


jeff

Re: 1.1.2 Prerelease

[nbecker]

I'm going to try building 1.1.2 on my glibc2.0.7/egcs-1.1.1 system.  I 
will then build glibc-2.1.  I think I need to now rebuild
libstdc++-2.9, right?

I will then build some c++ binaries.  I
will then try installing glibc-2.1 and (assuming I'm not dead yet) see 
if the binaries still work.

If glibc-2.1 install breaks everything, is there an easier way to
remove it, other than restore everything from tape?

Re: 1.1.2 Prerelease

[Martin v. Loewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

> Comments and suggestions would be greatly appreciated.

I noticed there aren't that many C++ fixes. The specific one I'd like
to see in 1.1.2 is

1999-01-25  Martin von Löwis  <loewis@informatik.hu-berlin.de>

	* tree.c (equal_functions): New function.
	(ovl_member): Call it.

This is a quality-of-implementation issue: Compile time will be
significantly reduced. I have not seen bug reports related to it
since it got into the development branch.

Regards,
Martin

Re: 1.1.2 Prerelease

[H.J. Lu]

> 
> 
> I'd like to be sure that egcs-1.1.2 will correctly compile both glibc-2.1
> and linux-2.2.1 on the major Linux architectures (x86, alpha, powerpc, sparc).
> 

Just for the record, please try to build egcs 1.1.2 on a glibc 2.0
based Linux/x86 system and build a few C++ applications, groff should
be ok. Then install glibc 2.1 and rebuild egcs 1.1.2. Now try to see
if the old groff binaries still work. "man fopen" will do. I have no
idea how to make a simple testcase out of it. Even if I did, I am
afraid noone, but who work on symbol versioning in glibc, would
understand what is going on.

BTW, my library versioing patch is created to deal with this problem.



H.J.

1.1.2 Prerelease

[Jeffrey A Law]

I've put a pre-release of egcs-1.1.2 in the pub/egcs/snapshots directory
"egcs-1.1.2-prerelease" on the egcs ftp server.

I suspect we'll have a second pre-release later this week to wrap up the few
remaining open issues (cpp script, file initializer scopes, doc updates, etc).

I'd like to be sure that egcs-1.1.2 will correctly compile both glibc-2.1
and linux-2.2.1 on the major Linux architectures (x86, alpha, powerpc, sparc).

So if folks could make a point to build & test glibc-2.1 and linux-2.2.1 
kernels on those architectures with the prerelease it would be greatly
appreciated.

The prototype announcement for egcs-1.1.2 is available at

http://www.cygnus.com/egcs/egcs-1.1/egcs-1.1.2.html

Comments and suggestions would be greatly appreciated.

jeff

ps. I'm pretty happy with the state of the language front-ends for egcs-1.1.2,
but if the language mantainers have critical bugs they want to fix, we do have
time.

pps.  egcs-1.1.2 is projected as the last release in the egcs-1.1 series.  Our
focus will turn to egcs-1.2 in the immediate future.