linux-gcc-digest         Thursday, February 24 2000     Volume 01 : Number 403

In this issue:

        Re: stl const_iterator question.
        Re: stl const_iterator question.
        Greetings for MusicYo.com!
        binutils 2.9.5.0.24 is released
        problems with linking
        remote debugging
        Re: problems with linking
        Re: remote debugging
        Re: problems with linking
        installing gcc 2.8.1 for cross compilation
        Re: problems with linking
        How to generate a.out binary on RedHat6.0?
        Re: How to generate a.out binary on RedHat6.0?
        bugfix: incorrect va_arg() definition for 32bit MIPS
        warning stuff
        gcc 2.95.2 wrong install?
        G++ & Fortran
        Re: G++ & Fortran
        C and Postgresql
        Re: C and Postgresql
        VIRUS ALERT!  THIS IS NOT A DRILL!
        trouble with gcc
        binutils 2.9.5.0.27 is released.
        
=?ISO-8859-1?Q?Bug=20when=20compiling=20a=20"C"=20program=20with=20gcc=20under=20linux=20Red=20Hat=206.0?=
        g++
        gcc v2.95.2 behavior
        C++ executable linked with libm
        Re: gcc 2.95.2 wrong install?
        glibc 2.1.3pre4
        Re: C++ executable linked with libm
        Re: g++
        Re: gcc 2.95.2 wrong install?
        Re: g++
        Re: g++
        Prombles regarding gcc 
        Re: Prombles regarding gcc
        Re: warning stuff
        glibc 2.1.3
        Re: glibc 2.1.3

See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.

----------------------------------------------------------------------

From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Thu, 13 Jan 2000 22:23:54 +0100
Subject: Re: stl const_iterator question.

> i is not a const_iterator, just an iterator.

Maybe I'm still missing something, but I cannot observe the behaviour
that you report. When I compile

#include <vector>
struct A
{
};

int main()
{
  vector<A> x;
  vector<A>::iterator i= x.begin();
  A& a = *i;
}

with g++ 2.95.2, it compiles just fine.

Regards,
Martin

------------------------------

From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Fri, 14 Jan 2000 10:39:58 +0800 (CST)
Subject: Re: stl const_iterator question.

Yes, for vector, it has no error, but for set,
it has errors and warnings.

On Thu, 13 Jan 2000, Martin v. Loewis wrote:

> > i is not a const_iterator, just an iterator.
> 
> Maybe I'm still missing something, but I cannot observe the behaviour
> that you report. When I compile
> 
> #include <vector>
> struct A
> {
> };
> 
> int main()
> {
>   vector<A> x;
>   vector<A>::iterator i= x.begin();
>   A& a = *i;
> }
> 
> with g++ 2.95.2, it compiles just fine.
> 
> Regards,
> Martin
> 

Sincerely Yours,

FengLou Mao
*******************************
ADD:Mr. FengLou Mao
    Institute of Physical Chemistry
    Peking University
    BeiJing
    P.R.China
Tel:86-10-62756833
Fax:86-10-62751725


------------------------------

From: <[EMAIL PROTECTED]>
Date: Fri, 14 Jan 2000 14:31:45 -0600
Subject: Greetings for MusicYo.com!

Dear [EMAIL PROTECTED],

Greetings from www.MusicYo.com! Your only source for brand-name, brand-new
gear at factory-direct prices!

In case you haven't visited us lately, here's what's new!

WIN A KRAMER GUITAR!
- --------------------
        * Stop by and enter to WIN a Kramer Baretta FX-404S guitar!
          http://www.musicyo.com/freestuf.asp?target=freesuf%2Easp

PRODUCT NEWS!
- -------------
On the product front we've now got IN STOCK AND READY FOR IMMEDIATE
PURCHASE...

        * Slingerland 5-pc Jam Session Drum Kits for $229
          http://www.musicyo.com/product.asp?dept%5Fid=2&pf%5Fid=017


        * MusicYo Personal Guitar Amplifiers for $17.99
          http://www.musicyo.com/product.asp?dept%5Fid=4&pf%5Fid=223


        * Celestion G12T-75 Speakers for $49.99
          http://www.musicyo.com/product.asp?dept%5Fid=4&pf%5Fid=224


        * Kramer Vanguards for $179
          http://www.musicyo.com/product.asp?dept%5Fid=1&pf%5Fid=014


        * MusicYo Gigbags for $7.99
          http://www.musicyo.com/product.asp?dept%5Fid=4&pf%5Fid=100

YO PLANET!
- ----------
        * Check out our new section called 'Yo Planet'. In it you will find
instructions on the set-up and maintenance of your instrument as well as
product reviews and more!
          http://www.musicyo.com/yoplanet.asp

        * You can even download 'Rock-Hard' - our exclusive Kramer ScreenMate -
for FREE! He walks... he talks... he gets down!
          http://www.musicyo.com/yoplanet.asp

Thanks a lot and thanks for visiting www.MusicYo.com!

Doc Yo
MusicYo.com
'What Will I Play Today?'


_____________________________________________________________________
Further transmissions to you by the sender of this e-mail may be stopped
at no cost to you by visiting http://www.musicyo.com/mailinglist.asp. If
you wish to change your mailing list options, such as request future
mailings in HTML format, please visit
http://www.musicyo.com/mailinglist.asp.


------------------------------

From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Mon, 17 Jan 2000 10:53:14 -0800
Subject: binutils 2.9.5.0.24 is released

This is the beta release of binutils 2.9.5.0.24 for Linux, which is
based on binutils 2000 0113 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.

I am planning to make the public release soon. Please test it as much
as you can.

Please report any bugs related to binutils 2.9.5.0.24 to [EMAIL PROTECTED]

For arm-linux targets, there are some important differences in behaviour 
between these tools and binutils 2.9.1.0.x.  The linker emulation name has 
changed from elf32arm{26} to armelf_linux{26}.  Also, the "-p" flag must be 
passed with the linker when working with object files (or static libraries) 
created using older versions of the assembler.  If this flag is omitted the 
linker will silently generate bad output when given old input files.

To get the correct behaviour from gcc, amend the *link section of your specs 
file as follows:

*link:
%{h*} %{version:-v}    %{b} %{Wl,*:%*}    %{static:-Bstatic}    %{shared:-shared
}    %{symbolic:-Bsymbolic}    %{rdynamic:-export-dynamic}    %{!dynamic-linker:
- -dynamic-linker /lib/ld-linux.so.2}    -X    %{mbig-endian:-EB} %{mapcs-26:-m ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p


Changes from binutils 2.9.5.0.22:

1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.

Changes from binutils 2.9.5.0.21:

1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.

Changes from binutils 2.9.5.0.19:

1. Update from binutils 1999 1122. An ia32 gas bug is fixed.

Changes from binutils 2.9.5.0.16:

1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.

Changes from binutils 2.9.5.0.14:

1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".

Changes from binutils 2.9.5.0.13:

1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.

Changes from binutils 2.9.5.0.12:

1. Update from binutils 1999 0922.
2. i370 update.

Changes from binutils 2.9.5.0.11:

1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
   and sparc introduced in the last release.
2. i370 update.

Changes from binutils 2.9.5.0.10:

1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
   and sparc.
2. Remove elf/hppa since it is WIP.

Changes from binutils 2.9.5.0.8:

1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
   in x86 FP register names.

Changes from binutils 2.9.5.0.7:

1. Update from binutils 1999 0821.
2. Some MIPS changes.

Changes from binutils 2.9.5.0.6:

1. Update from binutils 1999 0813.
2. i370 update.

Changes from binutils 2.9.5.0.5:

1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.

Changes from binutils 2.9.5.0.4:

1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.

Changes from binutils 2.9.5.0.3:

1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.

Changes from binutils 2.9.4.0.8:

1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.

Changes from binutils 2.9.4.0.7:

1. Update from binutils 1999 0710. A weak symbol bug

http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html

is fixed.

Changes from binutils 2.9.4.0.6:

1. Update from binutils 1999 0626.

Changes from binutils 2.9.4.0.5:

1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
   for objcopy.

Changes from binutils 2.9.4.0.4:

1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
   now.

Changes from binutils 2.9.4.0.3:

1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.

Changes from binutils 2.9.4.0.2:

1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.

Changes from binutils 2.9.4.0.1:

1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
   Linux kernel can build.
3. Fix i370 for the new gas.

Changes from binutils 1999 0605:

1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.

The file list:

1. binutils-2.9.5.0.24.tar.gz. Source code.
2. binutils-2.9.5.0.22-2.9.5.0.24.diff.gz. Patch against the previous
   beta source code.
3. binutils-2.9.5.0.24-1.i386.rpm. IA-32 binary RPM for RedHat 6.1.

There is no separate source rpm. You can do

# rpm -ta binutils-2.9.5.0.24.tar.gz

to create both binary and source rpms.

The primary ftp sites for the beta Linux binutils are:

1. ftp://ftp.valinux.com/pub/support/hjl/binutils

Thanks.


H.J. Lu
[EMAIL PROTECTED]
01/13/2000

------------------------------

From: Great One <[EMAIL PROTECTED]>
Date: Wed, 19 Jan 2000 21:49:30 +0000
Subject: problems with linking

hi

I've created two libraries (static ones)
and the second one uses a function from
the first one. 

I normally link them like this

ar r lib1.a lib1.o
ranlib r lib1.a

ar r lib2.a lib2.o
ranlib r lib2.a

then I try to link my program like this

gcc -o program program.o -l1 -l2

The linker keeps telling me that it's
impossible to find the function called
in the second library which is normally
present in the first one. Everything starts
to work when I call this function in program.c.

Does anybody know how to solve this ?

Thank You.



------------------------------

From: Great One <[EMAIL PROTECTED]>
Date: Wed, 19 Jan 2000 21:50:10 +0000
Subject: remote debugging

hi

Is it possible to debug a program remotely
via network (by GDB, the word network means
real network with ethernet cards, not serial
cable) ?
The program uses svgalib, so it's difficult to
debug it normally.

thank you


------------------------------

From: [EMAIL PROTECTED]
Date: Wed, 19 Jan 2000 20:33:51 EST
Subject: Re: problems with linking

On Wed, 19 Jan 2000, Great One wrote:

> 
> hi
> 
> I've created two libraries (static ones)
> and the second one uses a function from
> the first one. 
> 
> I normally link them like this
> 
> ar r lib1.a lib1.o
> ranlib r lib1.a
> 
> ar r lib2.a lib2.o
> ranlib r lib2.a
> 
> then I try to link my program like this
> 
> gcc -o program program.o -l1 -l2
> 
> The linker keeps telling me that it's
> impossible to find the function called
> in the second library which is normally
> present in the first one. Everything starts
> to work when I call this function in program.c.
> 
> Does anybody know how to solve this ?
> 
> Thank You.
> 
gcc -o program program.o '-Wl,-(,-l1,-l2,-)'


from info ld:


`-( ARCHIVES -)'
`--start-group ARCHIVES --end-group'
     The ARCHIVES should be a list of archive files.  They may be
     either explicit file names, or `-l' options.

     The specified archives are searched repeatedly until no new
     undefined references are created.  Normally, an archive is
     searched only once in the order that it is specified on the
     command line.  If a symbol in that archive is needed to resolve an
     undefined symbol referred to by an object in an archive that
     appears later on the command line, the linker would not be able to
     resolve that reference.  By grouping the archives, they all be
     searched repeatedly until all possible references are resolved.

     Using this option has a significant performance cost.  It is best
     to use it only when there are unavoidable circular references
     between two or more archives.
> 
I don't see why you don't just put both .o files in the same lib.a, but
you are the programmer.

Lawson

<< Sardines of the world unite! <<
>> You have nothing to lose but your cans. >>




________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

------------------------------

From: [EMAIL PROTECTED]
Date: Wed, 19 Jan 2000 19:37:00 EST
Subject: Re: remote debugging

I don't see why not.  For instance, you can fire up gdb in a telnet
session and give it the program file and pid of the process you are
trying to debug, and it should attach that process.

A serial cable over which you run ppp or slip is just as much a network
as a 2 node ethernet lashup.

Lawson

On Wed, 19 Jan 2000, Great One wrote:

> 
> hi
> 
> Is it possible to debug a program remotely
> via network (by GDB, the word network means
> real network with ethernet cards, not serial
> cable) ?
> The program uses svgalib, so it's difficult to
> debug it normally.
> 
> thank you
> 




________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

------------------------------

From: The Chazman <[EMAIL PROTECTED]>
Date: Thu, 20 Jan 2000 00:47:43 -0800
Subject: Re: problems with linking

> I've created two libraries (static ones)
> and the second one uses a function from
> the first one. 
>
> I normally link them like this
>
> ar r lib1.a lib1.o
> ranlib r lib1.a
>
> ar r lib2.a lib2.o
> ranlib r lib2.a
>
> then I try to link my program like this
>
> gcc -o program program.o -l1 -l2
>
> The linker keeps telling me that it's
> impossible to find the function called
> in the second library which is normally
> present in the first one. Everything starts
> to work when I call this function in program.c.
>
> Does anybody know how to solve this ?

Reverse the order in which the libraries are linked:

gcc -o program program.o -l2 -l1

GNU ld (the linker called by gcc) will link in only what is needed
up until the current point.  If program.o doesn't call anything in
lib1, then lib1 will be ignored in your original comand line.  The
linker then moves on to lib2, which is needed because program.o
references something in it.  If this generates a dependency on a
symbol in lib1, that will go unresolved, because the linker does not
go back and try lib1 again.  Each library is linked once, in the order
given on the command line.  If you want the linker to try a library
multiple times, you must list it multiple times on the command line,
as in:

gcc -o program program.o -l1 -l2 -l1

This is perfectly legal, and in fact, used all the time by gcc for
its own internal and standard libraries.

                            ------Carl

------------------------------

From: "Tan Su Wei" <[EMAIL PROTECTED]>
Date: Fri, 21 Jan 2000 11:16:14 +0700
Subject: installing gcc 2.8.1 for cross compilation

This is a multi-part message in MIME format.

- ------=_NextPart_000_0100_01BF6400.EE02C600
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
    I'm new to linux, and currently need to install a program on my =
redhat 6.0 (kernel 2.2.15) on an i686 which needs gcc 2.8.1.=20
    The gcc need to be configure for c and c++ compiler and as a cross =
compiler...
I'd tried to read the instruction for gcc INSTALL file and gcc-HOWTO =
document...but I still not sure how to do it...

    Can some please show me how to do it...

Thank you.
Regards
Tan Su Wei

- ------=_NextPart_000_0100_01BF6400.EE02C600
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I'm new to linux, =
and currently=20
need to install a&nbsp;program on my redhat 6.0 (kernel 2.2.15) on an =
i686 which=20
needs gcc 2.8.1. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; The gcc need to be =
configure for=20
c and c++ compiler and as a cross compiler...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'd tried to read the instruction for =
gcc INSTALL=20
file and gcc-HOWTO document...but I still not sure how to do =
it...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Can some please show =
me how to=20
do it...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Tan Su Wei</FONT></DIV></BODY></HTML>

- ------=_NextPart_000_0100_01BF6400.EE02C600--


------------------------------

From: [EMAIL PROTECTED]
Date: Fri, 21 Jan 2000 13:33:04 -0500 (EST)
Subject: Re: problems with linking

In fact, most/all linkers work this way.  For example, libXm
the motif library contains symbols that duplicate symbols in
libXt (i.e. 'overload' them).  Thus linking -lXm -lXt will
produce correct libraries, whereas -lXt -lXm will create apps with
weird coredumps/bad behaviour.

- --linas

It's been rumoured that The Chazman said:
> 
> > I've created two libraries (static ones)
> > and the second one uses a function from
> > the first one. 
> >
> > I normally link them like this
> >
> > ar r lib1.a lib1.o
> > ranlib r lib1.a
> >
> > ar r lib2.a lib2.o
> > ranlib r lib2.a
> >
> > then I try to link my program like this
> >
> > gcc -o program program.o -l1 -l2
> >
> > The linker keeps telling me that it's
> > impossible to find the function called
> > in the second library which is normally
> > present in the first one. Everything starts
> > to work when I call this function in program.c.
> >
> > Does anybody know how to solve this ?
> 
> Reverse the order in which the libraries are linked:
> 
> gcc -o program program.o -l2 -l1
> 
> GNU ld (the linker called by gcc) will link in only what is needed
> up until the current point.  If program.o doesn't call anything in
> lib1, then lib1 will be ignored in your original comand line.  The
> linker then moves on to lib2, which is needed because program.o
> references something in it.  If this generates a dependency on a
> symbol in lib1, that will go unresolved, because the linker does not
> go back and try lib1 again.  Each library is linked once, in the order
> given on the command line.  If you want the linker to try a library
> multiple times, you must list it multiple times on the command line,
> as in:
> 
> gcc -o program program.o -l1 -l2 -l1
> 
> This is perfectly legal, and in fact, used all the time by gcc for
> its own internal and standard libraries.
> 
>                             ------Carl
> 


------------------------------

From: =?gb2312?q?Song=20Jianping?= <[EMAIL PROTECTED]>
Date: Tue, 25 Jan 2000 00:20:14 -0800 (PST)
Subject: How to generate a.out binary on RedHat6.0?

Hello all,
  As in RH6.0, gcc will generate ELF binary by
default.
How can i tell it to generate a.out binary for me?

Thanks in advance.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

------------------------------

From: [EMAIL PROTECTED]
Date: Tue, 25 Jan 2000 15:32:16 EST
Subject: Re: How to generate a.out binary on RedHat6.0?

Hello one :-)

Why would you want to?  I think you would have to run it as a
cross-compiler, meaning it (the compiler) would have to have been
configured with a target of i386-*-linux-gnuaout or so.  You can see
what targets you have available with ls /usr[/local]/lib/gcc-lib, but I
doubt any stock distro compiler bothers with a.out on x86 any more.  You
could install the source for the compiler, configure it for a.out, and
build and install it, but it seems like a lot of work.

Lawson

Blore's Razor:
        Given a choice between two theories, take the one which is
funnier.

On Tue, 25 Jan 2000, [gb2312] Song Jianping wrote:

> Hello all,
>   As in RH6.0, gcc will generate ELF binary by
> default.
> How can i tell it to generate a.out binary for me?
> 
> Thanks in advance.
> 
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
> 




________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.

------------------------------

From: Hiroyuki Machida <[EMAIL PROTECTED]>
Date: Wed, 26 Jan 2000 13:27:53 +0900
Subject: bugfix: incorrect va_arg() definition for 32bit MIPS

Hi.
I have been building gcc 2.95.2 on 32bit MIPS/Linux box.
During this work, I found a inverted 'ifdef' on defining 
va_arg() macro in gcc/ginclude/va-mips.h.
That is, definition of va_arg for 32bit little endian and 32bit big
endian is inverted.

You can repeat this problem running a attached test program.
I guess gcc on IRIX 5.? or O32 ABI box has same problem.
Have you ever experienced same problem on 32bit MIPS box?

Sample fix is attached at the bottom.

VERSION:
        gcc 2.95.2 on MIPS/Linux
        gcc 2.7.2  on MIPS/Linux 
        egcs-1.0.2 on MIPS/Linux


REPEAT BY:

Compile and run this program. 
The program will print "OK", if va_arg() accept args correclty.

/*
 * 
 * stdarg.c  -- Simple stdarg test.
 *      Pass #of pairs and (type, value) pairs using stdarg.h.
 *      And check if passed values are correctly accepted.
 *
 */

#include<stdarg.h>

int foo(int nargs, ...)
{
        va_list ap;
        int i;
        int ng = 0;
        long long expected;
        long long passed;

        /* get # of args */
        va_start(ap, nargs);
        printf("  # of args:%d\n",nargs);

        for (i=1; i<= nargs ; i++) {
                char type;
                int d; long long ll; char c; char *s;

                /* calc. expceted value */
                expected=i; 
                if ( expected & 1 ) expected = -expected;

                /* get type of the arg */
                type = (char ) va_arg(ap, char);
                switch (type) {
                   case 'i': /* int */
                        d = va_arg(ap, int);
                        passed=d; 
                        printf("%10s: expected:%3lld,\t passed:%3lld\n",
                                "int", expected, passed);
                        if ( passed != expected) ng ++;
                        break;
                  case 'L':  /* long long */
                        ll = va_arg(ap, long long);
                        passed=ll;
                        printf("%10s: expected:%3lld,\t passed:%3lld\n",
                                "long long", expected, passed);
                        if ( passed != expected) ng ++;
                        break;
                  case 'c':  /* char */
                        c = (char) va_arg(ap, char);
                        passed=(long long) (c - '0');
                        printf("%10s: expected:%3lld,\t passed:%3lld\n",
                                "char", expected, passed);
                        if ( passed != expected) ng ++;
                        break;
                  case 's':  /* char * */
                        s = va_arg(ap, char *);
                        passed=(long long)atol(s);
                        printf("%10s: expected:%3lld,\t passed:%3lld\n",
                                "string", expected, passed);
                        if ( passed != expected) ng ++;
                        break;
                  default:  /* Unknown */
                        printf("  unkown type:%4d: argptr:0x%8.8x\n",
                                type,(void *)ap);
                        ng ++;
                        break;
                }
        }
        va_end(ap);
        return ng;
}

int main()
{
        int ng;

        printf("*\n");
        printf("* Simple stdarg test.\n");
        printf("*\n");

        /* Pass # of pairs and  (type, order<*>) pairs  */
        /* order<*> number must be minus value if order is odd */
        ng = foo(6,
                'i', -1,
                'c', '2',
                'L', (long long)-3,
                's', "4",
                'i', -5 ,
                'c', '6');

        if (ng) {
                printf("NG\n");
        }
        else {
                printf("OK\n");
        }
        return ng;
}






SAMPLE FIX:

gcc/ginclude/va-mips.h

retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -p -r1.1.1.1 -r1.2
- --- va-mips.h 1999/05/19 13:14:31     1.1.1.1
+++ va-mips.h   1999/11/08 09:48:26     1.2
@@ -254,19 +254,19 @@ void va_end (__gnuc_va_list);             /* Define
 
 #ifdef __MIPSEB__
 /* For big-endian machines.  */
+#define va_arg(__AP, __type)                                               \
+  ((__type *) (void *) (__AP = (char *) ((__alignof__(__type) > 4          \
+                               ? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8     \
+                               : ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4)    \
+                                        + __va_rounded_size(__type))))[-1]
+#else
+/* For little-endian machines.  */
 #define va_arg(__AP, __type)                                   \
   ((__AP = (char *) ((__alignof__ (__type) > 4                 \
                      ? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8   \
                      : ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4)  \
                     + __va_rounded_size (__type))),            \
    *(__type *) (void *) (__AP - __va_rounded_size (__type)))
- -#else
- -/* For little-endian machines.  */
- -#define va_arg(__AP, __type)                                             \
- -  ((__type *) (void *) (__AP = (char *) ((__alignof__(__type) > 4        \
- -                             ? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8     \
- -                             : ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4)    \
- -                                      + __va_rounded_size(__type))))[-1]
 #endif
 #endif
 #endif /* ! defined (__mips_eabi)  */


- ---
Hiroyuki Machida                [EMAIL PROTECTED]
Creative Station                SCEI / Sony Corp.

------------------------------

From: Przemek Borys <[EMAIL PROTECTED]>
Date: Wed, 26 Jan 2000 16:11:26 +0100
Subject: warning stuff

EHLO!

On a newsgroup one person had the following problem:
He wanted gcc to issue warning about unused functions of a program.
Is it possible at all?
If not, then will it be possible one day? :)

- -- 
____\___\___
(_(\|,|_|,|_  Gassho! [http://dione.ids.pl/~pborys][pinfo&mr  home]
    |   | |.  [PTM,teksty o zen,programowaniu,moje sf,xfaq_pl,inne]

------------------------------

From: "Gabor Z. Papp" <[EMAIL PROTECTED]>
Date: Thu, 27 Jan 2000 18:45:26 +0100
Subject: gcc 2.95.2 wrong install?

Wichert Akkerman wrote:

| > c++ -D_REENTRANT -D_GNU_SOURCE -O2 -DHAVE_CONFIG_H 
|-DLOCALEDIR=\"/usr/local/share/locale\" -I../intl -I../intl -I../include -I.. -I. 
|-I../include -I.. -I. -D_REENTRANT -D_GNU_SOURCE -O2 -c helpmsgs.cc
| > In file included from ../config.h:257,
| >                  from helpmsgs.h:9,
| >                  from helpmsgs.cc:6:
| > /usr/lib/gcc-lib/i486-pc-linux-gnu/2.95.2/include/stddef.h:118: declaration does 
|not declare anything
| > make[1]: *** [helpmsgs.o] Error 1
| > make[1]: Leaving directory `/mnt/part2/src/dpkg-1.6.7/dselect'
| > make: *** [all-recursive] Error 2
| 
| This is definitely an error in your compiler installation, not a dpkg
| bug.

This is a linux 2.3.40 running on x86, glibc 2.1.2
gcc 2.95.2 installed manually. What can be the problem?

My gcc's configure options was the following:

- --prefix=/usr
- --enable-shared
- --enable-threads
- --enable-cpp
- --enable-languages=c,c++

------------------------------

From: South Wind <[EMAIL PROTECTED]>
Date: Wed, 02 Feb 2000 18:09:22 +0800
Subject: G++ & Fortran

Hello..

   As we know, C functions adding '_' behind
   can be called by a fortran program.

   But it is useless to a C++ function.


   The error will look like this
     fortran_pro.o(.text+0x18): undefined reference to 'xxx_'

   Could someone give a hints...

    Thanks....

------------------------------

From: Burak Serdar <[EMAIL PROTECTED]>
Date: Wed, 02 Feb 2000 08:32:12 -0500
Subject: Re: G++ & Fortran

C++ decorates the names of the functions with its type and parameters.
You have to use C linkage for those functions.

extern "C" { void func(...);}


South Wind wrote:

> Hello..
>
>    As we know, C functions adding '_' behind
>    can be called by a fortran program.
>
>    But it is useless to a C++ function.
>
>    The error will look like this
>      fortran_pro.o(.text+0x18): undefined reference to 'xxx_'
>
>    Could someone give a hints...
>
>     Thanks....


------------------------------

From: "dung nguyen" <[EMAIL PROTECTED]>
Date: Wed, 02 Feb 2000 10:23:33 PST
Subject: C and Postgresql

Hello,
  I want to make a C program using Postgresql server. Please show me where I 
can find documentation about this?
Thanks.
D
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------------------------------

From: Bongo deGilligan <[EMAIL PROTECTED]>
Date: Thu, 03 Feb 2000 07:59:22 +0000
Subject: Re: C and Postgresql

dung nguyen wrote:

> Hello,
>   I want to make a C program using Postgresql server. Please show me where I
> can find documentation about this?
> Thanks.
> D

You can find documentation on this at  http://www.postgresql.org

What you are looking for is documentation on "libpq". "libpq" is a C
programming interface to Postgresql providing functionality that you can use
from your C program.

If you have Postgresql installed on your system this should also be part of
your user documentation.

John <[EMAIL PROTECTED]>


>

- --
email: [EMAIL PROTECTED]
Local mailserver  , remote
- --------
Linx:
http://www.computer.net/
http://einval.vol.8m.com/

People need individuality and freedom to do what they want!!




------------------------------

From: "William Scott Lockwood III" <[EMAIL PROTECTED]>
Date: Thu, 3 Feb 2000 09:20:22 -0600
Subject: VIRUS ALERT!  THIS IS NOT A DRILL!

Hello to EVERYONE in my address book:

Yesterday I was hit by a "virus" that may have replicated and mailed itself to
everyone in my address book.  I'm very sorry about this.  I didn't send this
out right away, because I wanted to know what to do about it FIRST.  With that
in mind, here's the scoop.

The file was actually a script, written in Visual Basic.  A standard scan with
McAfee will NOT pick this file up, because it has an odd extension, .VBS.
This is not a binary, it's text, so removal is simple.  One copy of the script
is renamed RUNDLL.VBS and is stored in your \WINDOWS\SYSTEM or \WINNT\SYSTEM32
(on NT systems) folder.  Removal is simple, just delete the file.  The other
copy of the file will reside in your TEMP directory, I.E. \WINDOWS\TEMP, which
is where mine was.  Note that the second copy will NOT be named RUNDLL, but
will have the same extension of .VBS and is easily found and removed as no
other file in that directory should have that extension.

HOW DO I KNOW I HAVE THE SCRIPT/VIRUS?
A message will show up on your system, from me (not actually, from the script
really) saying "Enjoy the links".  It will have a file attachment, which is
the afore mentioned file.  CLICKING ON IT will LAUNCH the virus, and offer to
put XXX links on your desktop.  If this happened to you, you have the
script/virus and need to follow the directions above (or below for you
non-techies out there) and clean your system.

For the NON-TECHNICAL who get this message:
READ ALL DIRECTIONS BEFORE PROCEEDING!  IF YOU CAN'T FIGURE IT OUT, CALL ME
FOR HELP!

Go and Download McAfee 4.0 from ftp.mcafee.com , http://www.mcafee.com/ or
similar.  Be sure you download the latest scan.dat file.  Install McAfee, and
then the latest scan.dat file.  You may get an error telling you the file is
locked!  If so, you must restart your machine in MS-DOS mode, and manually
copy the file scan.dat to the McAfee Directory.  Be sure to write down where
that is when you first install McAfee so you know where to copy the file to!
You will also need either pkzip or WinZip (http://www.winzip.com/ ) to open
the file the new dat files are in.  Tell it so scan all files, and the
script/virus if present will be deleted my McAfee.  I have not tested any
other scanners, but I'm sure if you have current files, you should be fine
with Dr. Solomon, Norton, etc.

Again, I'm very sorry about this, and regret any inconvenience this may have
caused.

Sincerely,
Scott



------------------------------

From: "creach.stephane" <[EMAIL PROTECTED]>
Date: Sun, 06 Feb 2000 18:14:28 +0100
Subject: trouble with gcc

Hello,
I can't do anything with gcc.
The message error is :
BUG IN DYNAMIC LINKER ld.so : dynamic-link.h:57:elf-get-dynamic-info:
Assertion '!. "bad dynamic tag" failed'.
Can you explain me what's wrong, please ?
Thank you.

------------------------------

From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Tue, 8 Feb 2000 17:52:02 -0800
Subject: binutils 2.9.5.0.27 is released.

This is the beta release of binutils 2.9.5.0.27 for Linux, which is
based on binutils 2000 0204 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.

I am planning to make the public release soon. Please test it as much
as you can.

Please report any bugs related to binutils 2.9.5.0.27 to [EMAIL PROTECTED]

For arm-linux targets, there are some important differences in behaviour 
between these tools and binutils 2.9.1.0.x.  The linker emulation name has 
changed from elf32arm{26} to armelf_linux{26}.  Also, the "-p" flag must be 
passed with the linker when working with object files (or static libraries) 
created using older versions of the assembler.  If this flag is omitted the 
linker will silently generate bad output when given old input files.

To get the correct behaviour from gcc, amend the *link section of your specs 
file as follows:

*link:
%{h*} %{version:-v}    %{b} %{Wl,*:%*}    %{static:-Bstatic}    %{shared:-shared
}    %{symbolic:-Bsymbolic}    %{rdynamic:-export-dynamic}    %{!dynamic-linker:
- -dynamic-linker /lib/ld-linux.so.2}    -X    %{mbig-endian:-EB} %{mapcs-26:-m ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p


Changes from binutils 2.9.5.0.24:

1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.

Changes from binutils 2.9.5.0.22:

1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.

Changes from binutils 2.9.5.0.21:

1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.

Changes from binutils 2.9.5.0.19:

1. Update from binutils 1999 1122. An ia32 gas bug is fixed.

Changes from binutils 2.9.5.0.16:

1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.

Changes from binutils 2.9.5.0.14:

1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".

Changes from binutils 2.9.5.0.13:

1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.

Changes from binutils 2.9.5.0.12:

1. Update from binutils 1999 0922.
2. i370 update.

Changes from binutils 2.9.5.0.11:

1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
   and sparc introduced in the last release.
2. i370 update.

Changes from binutils 2.9.5.0.10:

1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
   and sparc.
2. Remove elf/hppa since it is WIP.

Changes from binutils 2.9.5.0.8:

1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
   in x86 FP register names.

Changes from binutils 2.9.5.0.7:

1. Update from binutils 1999 0821.
2. Some MIPS changes.

Changes from binutils 2.9.5.0.6:

1. Update from binutils 1999 0813.
2. i370 update.

Changes from binutils 2.9.5.0.5:

1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.

Changes from binutils 2.9.5.0.4:

1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.

Changes from binutils 2.9.5.0.3:

1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.

Changes from binutils 2.9.4.0.8:

1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.

Changes from binutils 2.9.4.0.7:

1. Update from binutils 1999 0710. A weak symbol bug

http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html

is fixed.

Changes from binutils 2.9.4.0.6:

1. Update from binutils 1999 0626.

Changes from binutils 2.9.4.0.5:

1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
   for objcopy.

Changes from binutils 2.9.4.0.4:

1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
   now.

Changes from binutils 2.9.4.0.3:

1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.

Changes from binutils 2.9.4.0.2:

1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.

Changes from binutils 2.9.4.0.1:

1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
   Linux kernel can build.
3. Fix i370 for the new gas.

Changes from binutils 1999 0605:

1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.

The file list:

1. binutils-2.9.5.0.27.tar.gz. Source code.
2. binutils-2.9.5.0.24-2.9.5.0.27.diff.gz. Patch against the previous
   beta source code.
3. binutils-2.9.5.0.27-1.i386.rpm. IA-32 binary RPM for RedHat 6.1.

There is no separate source rpm. You can do

# rpm -ta binutils-2.9.5.0.27.tar.gz

to create both binary and source rpms.

The primary ftp sites for the beta Linux binutils are:

1. ftp://ftp.valinux.com/pub/support/hjl/binutils

Thanks.


H.J. Lu
[EMAIL PROTECTED]
02/08/2000

------------------------------

From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Date: Tue, 15 Feb 2000 22:28:38 +0100 (MET)
Subject: 
=?ISO-8859-1?Q?Bug=20when=20compiling=20a=20"C"=20program=20with=20gcc=20under=20linux=20Red=20Hat=206.0?=

- --950650118-143302914-950650118=:28279
Content-Type: TEXT/PLAIN; Charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hello!

I=20have=20installed=20the=20distribution=20Red=20Hat=206.0=20of=20linux=20on=20my=20
personal=20computer=20,=20and=20I=20cannot=20use=20the=20gcc=20compiler=20.
When=20I=20launch=20the=20following=20command=20:
"gcc=20prog.c"
I=20obtain=20this=20error=20message:

BUG=20IN=20DYNAMIC=20LINKER=20ld.so:=20dynamic-link.h:=2057:=20
elf_get_dynamic_info:=20Assertion=20`!=20"bad=20dynamic=20tag"'=20failed!

Thank=20you=20to=20help=20me=20if=20you=20can=20.
=0A--=0AL'internet=20gratuit=20avec=20LibertySurf=20=20=0Ahttp://www.libertysurf.fr=0A
- --950650118-143302914-950650118=:28279--


------------------------------

From: Todd Warner <[EMAIL PROTECTED]>
Date: Wed, 16 Feb 2000 23:56:03 -0500
Subject: g++

Anyone know when namespaces will be implemented?

How about proper usage of such things as cin.getline()?

Hmmm... what else... stringstreams????

What's the status? Can anyone direct me where I can find out?


- -- 
Todd Warner (email: [EMAIL PROTECTED] || [EMAIL PROTECTED])
 - Computer geek at large - CS student at Wright State University
 - Staff Sergeant, US Army Tank Commander (M1 series MBTs)
 - GNU/Linux fanatic - GnuPG/PGP public key: http://pgp5.ai.mit.edu

------------------------------

From: Dominique Fober <[EMAIL PROTECTED]>
Date: Thu, 17 Feb 2000 11:14:40 +0100
Subject: gcc v2.95.2 behavior

I have a strange behavior at compile time for the same project with :
- - gcc v. pgcc 2.91.66 running on linux 2.2.9-19mdk : compile ok
- - gcc v. 2.95.2 running on linux 2.2.14-15mdk : cannot compile; results in a lot of 
errors

In fact, gcc v. 2.95.2 includes the following:
   /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/include/asm/posix_types.h
instead of 
   /usr/include/asm/posix_types.h
This special include seems to be intended to fix a bug in _FD_ZERO for glibc-1.x. 
However, it includes <features.h> which prevents many data types to be defined. 

To force these typedefs, I need to compile with -D_LOOSE_KERNEL_NAMES.
I'm compiling code for a kernel module and other options are :
- -DMODVERSIONS -DCONFIG_KERNELD -DMODULE -D__KERNEL__ -DLINUX  -D__NO_VERSION__

I would like to know whether it's a temporary problem related to this gcc version, or 
a conflict with my compiler options.

Thanks for your help,
Dominique Fober



------------------------------

From: "Shenderovich, Uri" <[EMAIL PROTECTED]>
Date: Thu, 17 Feb 2000 16:16:38 +0200
Subject: C++ executable linked with libm

Hi all,
Could somebody tell me, why all c++ executables linked with libm.
Even the simplest one of the form '#include<iostream> main() { cout <<
"hello" << endl;}' .
(Besides this , from the output of 'ldd' it's possible to see that the same
executable is linked with libc , but not with stdc++)
If I use C counterpart program like '#include<stdio.h> main() {
printf("hello\n");}' the libm is not linked with the executable.

I use gcc/g++ -2.95.2 and ldd-2.1.1
Thanks,
Uri

BTW I have try to do the same with pgcc-2.95.2 , and eventhough it still
links the executable with libc and libm , but it links 
the libstdc++ as well , contrary to gcc-2.95.2 


------------------------------

From: "Gabor Z. Papp" <[EMAIL PROTECTED]>
Date: Thu, 17 Feb 2000 14:48:57 GMT
Subject: Re: gcc 2.95.2 wrong install?

| | > /usr/lib/gcc-lib/i486-pc-linux-gnu/2.95.2/include/stddef.h:118: declaration does 
|not declare anything

What mean this?


------------------------------

From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 17 Feb 2000 22:06:09 -0800
Subject: glibc 2.1.3pre4

Hi,

I've uploaded the fourth (and hopefully last) test release for glibc 2.1.3
to

        ftp://sourceware.cygnus.com/pub/glibc/snapshots

You can find the files

        glibc-2.1.3pre4.tar.bz2         (also .gz)
and
        glibc-linuxthreads-2.1.3pre4.tar.gz

(All my alternative sites are not reachable or changed.  So use
sourceware and its mirror sites.)


The crypt add-on hasn't changed.  (And I have not yet a word from a
legal people whether I can include the code in the main sources.)


Since pre3 we added quite a lot of bug fixes and we now feel very
strongly that the sources are very stable, more stable than anything
before.  Especially people doing heavy thread work should try it.

If no major problems are reported I'll make an official release soon.
Please send feedback (nagative *and* positive to
[EMAIL PROTECTED]).

- -- 
- ---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

------------------------------

From: Wolfram Gloger <[EMAIL PROTECTED]>
Date: Fri, 18 Feb 2000 08:47:34 +0100 ("MET)
Subject: Re: C++ executable linked with libm

Hello,

> Could somebody tell me, why all c++ executables linked with libm.

Not all, but most C++ programs are linked with libstdc++.  The shared
libstdc++.so library unconditionally depends on libm.so (because a few
functions within it require math functions), so what you see is
normal.

It may be possible to link parts of libstdc++ _statically_ into a
program _without_ bringing in libm, but with dynamic linking libm will
always be required.

Regards,
Wolfram.

------------------------------

From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Fri, 18 Feb 2000 23:13:13 +0100
Subject: Re: g++

> Anyone know when namespaces will be implemented?

They are implemented since egcs 1.1.0 (released September 3, 1998),
and are also part of gcc 2.95.

> How about proper usage of such things as cin.getline()?

What is the problem? It works for me.

> Hmmm... what else... stringstreams????

You may want to try the version in
http://gcc.gnu.org/ml/gcc/2000-02/msg00448/sstream,

or you can try libstdc++ v3.

> What's the status? Can anyone direct me where I can find out?

gcc.gnu.org, sourceware.cygnus.com.

Regards,
Martin

------------------------------

From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Fri, 18 Feb 2000 23:15:42 +0100
Subject: Re: gcc 2.95.2 wrong install?

> | | > /usr/lib/gcc-lib/i486-pc-linux-gnu/2.95.2/include/stddef.h:118: declaration 
>does not declare anything
> 
> What mean this?

In C and C++, declarations are used to introduce variables, functions
and the like. Every declaration has a name. For example,

  int x;

declares a variable, and gives it a name (x). If you just write

  int;

you get such an error: the declaration does not declare anything.

Regards,
Martin

------------------------------

From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Sun, 20 Feb 2000 01:19:14 +0100
Subject: Re: g++

> >> Anyone know when namespaces will be implemented?
> >
> > They are implemented since egcs 1.1.0 (released September 3, 1998),
> > and are also part of gcc 2.95.
> 
> A work-around has been implemented. Not an implementation to standard.

Pardon me? Why is the namespace implementation in g++ not according to
the standard? Give examples.

If you are referring to the treatment of 'namespace std': This is an
extension, which can be turned of with -fhonor-std. On all other
namespaces, g++ behaves conforming.

> >> How about proper usage of such things as cin.getline()?
> >
> > What is the problem? It works for me.
> 
> Yes, cin.getline() works... but not to ANSI standard.

Again, don't make such claims without foundations. Examples?

Also, it is primarily an ISO standard, not an ANSI one.

> I'll check it out... but what about #include <stringstream> ?

What about it? There is no such header in standard C++.

> Checked out the website... thanks... I know people are working on
> these things.  I just wanted to vent my frustration and let people
> know that the people coding out here are trying to use these
> standard features... and we are afraid that competitors may be
> moving ahead of GCC...

I'm not afraid of that. When it comes to the compiler proper, I know
of no competition that is closer to the standard than g++ (EDG
compilers are on a similar level, though).

For the library, libstdc++ v3 should be much better than the current
one.

If all you wanted is to vent your frustration, I feel sorry that I
wasted my time responding to you.

Regards,
Martin

------------------------------

From: Todd Warner <[EMAIL PROTECTED]>
Date: Sat, 19 Feb 2000 22:16:52 -0500 (EST)
Subject: Re: g++

To all readers on the list: 
  If you don't know it already, Stroustrup's book, though wonderful, is flawed. I am 
referring to "The C++ Programming Language". Make sure you get the errata before you 
waste someone's precious time. Sorry Martin... :(

On Sun, 20 Feb 2000 01:19:14 +0100, "Martin v. Loewis" 
<[EMAIL PROTECTED]> wrote:
>
>> >> Anyone know when namespaces will be implemented?
>> >
>> > They are implemented since egcs 1.1.0 (released September 3, 1998),
>> > and are also part of gcc 2.95.
>> 
>> A work-around has been implemented. Not an implementation to standard.
>
> Pardon me? Why is the namespace implementation in g++ not according to
> the standard? Give examples.
>
> If you are referring to the treatment of 'namespace std': This is an
> extension, which can be turned of with -fhonor-std. On all other
> namespaces, g++ behaves conforming.

YOU ARE RIGHT! My mistake... I investigated further... sorry about that.
I *did* upgrade GCC fairly recently (a month), so maybe my problems with
that was pre-egcs 1.1.*. Sorry about that... Hey... this is how I learn! :)

>> >> How about proper usage of such things as cin.getline()?
>> >
>> > What is the problem? It works for me.
>> 
>> Yes, cin.getline() works... but not to ANSI standard.
> Again, don't make such claims without foundations. Examples?

I am going by Stroustrup.... I finally checked out his various errata! He made
a number of mistakes, including this one. egcs is correct! If interested
the error is on page .... 51. And makes perfect sense in retrospect.

> Also, it is primarily an ISO standard, not an ANSI one.
>
>> I'll check it out... but what about #include <stringstream> ?
>
> What about it? There is no such header in standard C++.

Again, you are right! Stroustrup typo-ed again! Page 119, 1st paragraph! Now, this 
BOOK is frustrating me a bit.

>> Checked out the website... thanks... I know people are working on
>> these things.  I just wanted to vent my frustration and let people
>> know that the people coding out here are trying to use these
>> standard features... and we are afraid that competitors may be
>> moving ahead of GCC...
>
> I'm not afraid of that. When it comes to the compiler proper, I know
> of no competition that is closer to the standard than g++ (EDG
> compilers are on a similar level, though).

> For the library, libstdc++ v3 should be much better than the current
> one.
Great!

> If all you wanted is to vent your frustration, I feel sorry that I
> wasted my time responding to you.

I am sorry you did waste your time! I should have looked at the errata for Stroustrup 
sooner, and should have tried out namespaces again after the upgrade. No, I didn't 
*just* want to vent. I did really want to get to the bottom of some of these issues. 
And I still would love to see a implemented/
not implemented features list. 

I appreciate your time. You have educated me, and I value that. To me it was not a 
waste of time, but I am sure you see it otherwise. I appologize. We are not all gurus, 
you know... not yet anyway. :)

> Regards,
> Martin

- -- 
Todd Warner (email: [EMAIL PROTECTED] || [EMAIL PROTECTED])
 - Computer geek at large - CS student at Wright State University
 - Staff Sergeant, US Army Tank Commander (M1 series MBTs)
 - GNU/Linux fanatic - GnuPG/PGP public key: http://pgp5.ai.mit.edu



------------------------------

From: "nitc" <[EMAIL PROTECTED]>
Date: Sun, 20 Feb 2000 02:05:51 -0800
Subject: Prombles regarding gcc 

This is a multi-part message in MIME format.

- ------=_NextPart_000_0004_01BF7B47.0392A5A0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear sir ;
              I am new to linux and have linux-2.2.5  installed in my =
computer
I am facing few problems as described below
1. gcc -g sample.c
error:/usr/i386-linux/bin/ld :can't open crt1.o

2 I have to compile the program separately(using option -c , -S ) and =
linking done manually
 /lib/ld.so =3D> a.out dynamic linker/loader (libc-2.1.so)
/lib/ld-linux.so.1 -> /lib/ld-linux.so.1.9.9 ELF library
/lib/ld-linux.so.2
/lib/libc.so.6 (shared library)
creating a.out  but from command line /. a.out does not run
althouh ../../ ls -F shows a.out*(executible)
           ../../ ls -l
           rwxr-xr-x (executabe)a.out
3.gcc -v   reading from space /usr/lib/gcc-lib/egcs/..
  not  gcc-2.7.1

LOOKING FOR YOURS EARLIEST REPLY=20
                                                                 =
THANKING YOU IN ANTICIPATION
                                                                   =
SANJAY TIWARI(INDIA)
                                               E-MAIL    [EMAIL PROTECTED]
                                                              =
[EMAIL PROTECTED]

     =20

- ------=_NextPart_000_0004_01BF7B47.0392A5A0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Dear sir ;</FONT></DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
I am new to linux and have linux-2.2.5&nbsp; installed in my=20
computer</FONT></DIV>
<DIV><FONT size=3D2>I am facing few problems as described =
below</FONT></DIV>
<DIV><FONT size=3D2>1. gcc -g sample.c</FONT></DIV>
<DIV><FONT size=3D2>error:/usr/i386-linux/bin/ld :can't open =
crt1.o</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>2 I have to compile the program separately(using =
option -c ,=20
- -S ) and linking done manually</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;/lib/ld.so =3D&gt; a.out dynamic linker/loader =

(libc-2.1.so)</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2>/lib/ld-linux.so.1 -&gt;=20
/lib/ld-linux.so.1.9.9 ELF library</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2></FONT><FONT =
color=3D#000000=20
size=3D2>/lib/ld-linux.so.2</FONT></DIV>
<DIV><FONT size=3D2>/lib/libc.so.6 (shared library)</FONT></DIV>
<DIV><FONT size=3D2>creating a.out&nbsp; but from command line /. a.out =
does not=20
run</FONT></DIV>
<DIV><FONT size=3D2>althouh ../../ ls -F shows =
a.out*(executible)</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
../../ ls -l</FONT></DIV>
<DIV><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
rwxr-xr-x (executabe)a.out</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT size=3D2>3.gcc -v&nbsp;&nbsp; reading =
from space=20
/usr/lib/gcc-lib/egcs/..</FONT></DIV>
<DIV><FONT size=3D2>&nbsp; not&nbsp;</FONT><FONT size=3D2> =
gcc-2.7.1</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>LOOKING FOR YOURS EARLIEST REPLY </FONT></DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
THANKING YOU IN ANTICIPATION</FONT></DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SANJAY TIWARI(INDIA)</FONT></DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
E-MAIL&nbsp;&nbsp;&nbsp; <A=20
href=3D"mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</A></FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A =
href=3D"mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></DIV></BODY></HTML>

- ------=_NextPart_000_0004_01BF7B47.0392A5A0--


------------------------------

From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Sun, 20 Feb 2000 11:24:36 +0100
Subject: Re: Prombles regarding gcc

> I am new to linux and have linux-2.2.5 installed in my computer I am
> facing few problems as described below 1. gcc -g sample.c
> error:/usr/i386-linux/bin/ld :can't open crt1.o

You didn't say what Linux distribution (redhat, debian, suse) you are
using. It looks like an error that /usr/i386-linux/bin/ld is invoked -
why does it not invoke /usr/bin/ld. Also, crt1.o should be found in
/usr/lib/crt1.o.

Most likely, you forgot to install essential files on your system. On
a redhat system, crt1.o is part of the glibc-devel package;
/usr/bin/ld is part of the binutils package. Make sure these packages
are installed on your system.

Regards,
Martin


------------------------------

From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Sun, 20 Feb 2000 11:31:59 +0100
Subject: Re: warning stuff

> He wanted gcc to issue warning about unused functions of a program.
> Is it possible at all?

If the functions are static, gcc will warn if they are not used. So
making 'potentially unused' functions static will allow a better
diagnosis.

If you want to know which extern functions are unused, the compiler
cannot decide it on its own - you have to wait until you see the
linker line to know what is used and what is not.

To omit unused functions during linking, one approach is to pass
- -ffunction-sections to the compiler, and --gc-sections to the
linker. That only works for -static linking.

With this approach, it is also possible to find out functions removed
during linking: Invoke nm on the resulting executable, and on each
input object file. Comparing the symbol lists gives you the unused
functions.

Regards,
Martin


------------------------------

From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 24 Feb 2000 19:45:42 -0800
Subject: glibc 2.1.3

I've uploaded the 2.1.3 release of glibc to

        ftp://sourceware.cygnus.com/pub/glibc/releases

There you can find the files

        glibc-2.1.3.tar.bz2     (also .gz)
        glibc-2.1.2-2.1.3.diff.gz
        glibc-linuxthreads-2.1.3.tar.gz

There is no new crypt add-on since it hasn't changed.

This release fixes many bugs in all parts of the library and everybody
is encouraged to update.  Preferably through your distribution
provider since compiling glibc yourself means taking a risk unless you
know exactly what you are doing.

This release should be fully compatible (both directions) with glibc
2.1.2.  The only part which changed is the format of the files
containing the locale data.  This can be easily fixed by running the
`localedef' program for the locales which get used on the system (or
by running `make localedata/install-locales' to update all of them).

- -- 
- ---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

------------------------------

From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Thu, 24 Feb 2000 22:12:32 -0800
Subject: Re: glibc 2.1.3

Ugh...

- --- locale/C-ctype.c.~1~      Thu Feb 24 14:48:02 2000
+++ locale/C-ctype.c    Thu Feb 24 22:16:42 2000
@@ -376,7 +376,7 @@
     { string: NULL },
     { string: (const char *) (_nl_C_LC_CTYPE_tolower + 128) }
 #if BYTE_ORDER == BIG_ENDIAN
- -    { string: NULL },
+    , { string: NULL },
 #endif
   }
 };

------------------------------

End of linux-gcc-digest V1 #403
*******************************

To subscribe to linux-gcc-digest, send the command:

        subscribe linux-gcc-digest

in the body of a message to "[EMAIL PROTECTED]".  If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-gcc":

        subscribe linux-gcc-digest [EMAIL PROTECTED]

A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-gcc-digest"
in the commands above with "linux-gcc".

Reply via email to