linux-gcc-digest Thursday, 21 January 1999 Volume 01 : Number 358
In this issue:
vfork specs
Re: vfork specs
A new set of patches for egcs 1.1.1/linux
Re: glibc 2.0.110
Re: glibc 2.0.110
Re: glibc 2.0.110
Re: glibc 2.0.110
Re: vfork specs
Re: glibc 2.0.110
Re: glibc 2.0.110
Re: glibc 2.0.110
gcc&g++(egcs1.1.1) how to find its head files and lib?
A question about the version number of glib-c?
Re: A question about the version number of glib-c?
Re: vfork specs
Re: vfork specs
gcc path question!
Re: vfork specs
Re: gcc path question!
Re: gcc path question!
Re: glibc 2.0.110
Re: gcc&g++(egcs1.1.1) how to find its head files and lib?
Problem compiling glibc-2.0.110
Re: Problem compiling glibc-2.0.110
Re: A question about the version number of glib-c?
Re: A question about the version number of glib-c?
Help needed on pop3 client
LinuxThreads stack layout is not good
Re: LinuxThreads stack layout is not good
Re: LinuxThreads stack layout is not good
Re: LinuxThreads stack layout is not good
Re: LinuxThreads stack layout is not good
Re: LinuxThreads stack layout is not good
Re: LinuxThreads stack layout is not good
Please try egcs 1.1.1 19990115/Linux.
dynamic linker problem
Re: dynamic linker problem
Re: A question about the version number of glib-c?
ldd bug
RE: dynamic linker problem
C++ Destructor Question
Re: C++ Destructor Question
Re: C++ Destructor Question
Re: C++ Destructor Question
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 15 Jan 1999 09:56:28 -0800
Subject: vfork specs
Implementing the vfork syscall wrapper in the libc apparently provides
some problems. To find a solution it's necessary to get a
specification of vfork, or at least make one up for Linux.
The problem is this: the vfork'ed process using the same VM as the
initial process. Assume the following code for now:
void
bar ()
{
if ((pid = vfork ()) == 0)
foo (0);
else if (pid == -1)
...error...
When calling the vfork wrapper we have the following stack layout:
...something...
return address bar after vfork call
Now the child returns from the vfork call and calls `foo' with the
resulting layout:
...something...
0
return address bar after foo call
May `foo' then exit and so the parent process starts and it sees the
return address 0 (zero) which was pushed as a parameter for `foo'.
This certainly is a situation we have to deal with and make sure that
the return address from the `vfork' syscall stays valid. But this is
only have of the story. It gets complicated if the use of the vfork
is not restricted. Assume this:
void
bar ()
{
pid_t p = baz ();
if (p == 0)
foo (0);
}
pid_t
baz ()
{
return vfork ();
}
Now the stack layout when reachine the syscall wrapper is
...something...
return address bar after baz call
return address baz after vfork call
At the time the function foo is called the stack layout is
...something...
0
return address bar after foo call
I.e., we are again f*cked. This can of course be repeated for
arbitrary depths of function calls.
So the question is: does the vfork interface on other platforms
restricts the use of vfork to situations like the first example and
disallows the second one (or even deeper nestings)? I think this is
what the Solaris man page says.
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Roland McGrath <[EMAIL PROTECTED]>
Date: Fri, 15 Jan 1999 15:22:29 -0500
Subject: Re: vfork specs
All true vfork implementations in all systems have had these restrictions,
whether cleared stated by their documentation or not. If you think about
it, the issue is inherent in the memory sharing behavior vfork is specified
to have.
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Fri, 15 Jan 1999 12:55:58 -0800 (PST)
Subject: A new set of patches for egcs 1.1.1/linux
Hi,
A new set of patches for egcs 1.1.1/linux is at
ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/
Files are
egcs-1.1.1-arm-diff-990113.gz egcs-1.1.1.diff.16.gz
egcs-1.1.1-mips.diff.gz egcs-1.1.1.diff.17.gz
egcs-1.1.1-sparc.patch.gz egcs-1.1.1.diff.18.gz
egcs-1.1.1.diff.1.gz egcs-1.1.1.diff.19.gz
egcs-1.1.1.diff.10.gz egcs-1.1.1.diff.20.gz
egcs-1.1.1.diff.11.gz egcs-1.1.1.diff.3.gz
egcs-1.1.1.diff.13.gz egcs-1.1.1.diff.4.gz
egcs-1.1.1.diff.14.gz egcs-1.1.1.diff.5.gz
egcs-1.1.1.diff.15.gz
Please give it a try.
Thanks.
H.J.
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 13:03:08 -0800 (PST)
Subject: Re: glibc 2.0.110
Dear all,
I compiled glibc 2.0.110 with no error messages.
When I installed it, it told me:
make -C manual subdir_install make[2]: Entering directory
`/linux2/people/mao/ftp/glibc-2.0.110/manual'
make[2]: *** No rule to make target `../crypt/genpass.c.texi', needed
by `chapters.texi'. Stop.
make[2]: Leaving directory `/linux2/people/mao/ftp/glibc-2.0.110/manual'
make[1]: *** [manual/subdir_install] Error 2
make[1]: Leaving directory `/linux2/people/mao/ftp/glibc-2.0.110'
make: *** [install] Error 2
After that, my egcs can not used.
At first, it told me no lib "/usr/local/lib/libc.so.6"
When I linked libc.2.0.7.so to /usr/local/lib/libc.so.6
It told me no /usr/local/include/stubs.h which included ny feature.h.
Can anyone help me to make my egcs can work!
Thank you very much!
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 15 Jan 1999 21:06:52 -0800
Subject: Re: glibc 2.0.110
Fenglou Mao <[EMAIL PROTECTED]> writes:
> make -C manual subdir_install make[2]: Entering directory
> `/linux2/people/mao/ftp/glibc-2.0.110/manual'
> make[2]: *** No rule to make target `../crypt/genpass.c.texi', needed
> by `chapters.texi'. Stop.
The announcement clearly said you have to get the most recent crypt
add-on. Why do I bother writing any documentation at all?
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 13:30:47 -0800 (PST)
Subject: Re: glibc 2.0.110
Hi,
The most recent crypt I can found is glibc-crypt-2.0.108.
Is it right?
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Peking University
BeiJing
P.R.China
Tel:86-10-62751490
Fax:86-10-62751725
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Fri, 15 Jan 1999 22:38:02 -0700
Subject: Re: glibc 2.0.110
Unnamed sources report that Ulrich Drepper said:
> Fenglou Mao <[EMAIL PROTECTED]> writes:
>
> > make -C manual subdir_install make[2]: Entering directory
> > `/linux2/people/mao/ftp/glibc-2.0.110/manual'
> > make[2]: *** No rule to make target `../crypt/genpass.c.texi', needed
> > by `chapters.texi'. Stop.
>
> The announcement clearly said you have to get the most recent crypt
> add-on. Why do I bother writing any documentation at all?
Because some of us do RTFM and appreciate the information.
- --
Kurt Wall
Informix on Linux FAQ - http://www.xmission.com/~kwall/iolfaq.html
Spanish Translation - http://www.xmission.com/~kwall/iolfaqsp.html
------------------------------
From: Geoff Keating <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 17:35:10 +1100
Subject: Re: vfork specs
> Date: Fri, 15 Jan 1999 15:22:29 -0500
> From: Roland McGrath <[EMAIL PROTECTED]>
> Cc: GNU libc testers <[EMAIL PROTECTED]>,
> VGER gcc list <[EMAIL PROTECTED]>,
> VGER kernel list <[EMAIL PROTECTED]>
> X-Windows: some voids are better left unfilled.
>
> All true vfork implementations in all systems have had these restrictions,
> whether cleared stated by their documentation or not. If you think about
> it, the issue is inherent in the memory sharing behavior vfork is specified
> to have.
The Solaris manual page says:
NOTES
The use of vfork() for any purpose except as a prelude to an
immediate call to a function from the exec family, or to
_exit(), is not advised.
vfork() is unsafe in multi-thread applications.
This function will be eliminated in a future release. The
memory sharing semantics of vfork() can be obtained through
other mechanisms.
To avoid a possible deadlock situation, processes that are
children in the middle of a vfork() are never sent SIGTTOU
or SIGTTIN signals; rather, output or ioctls are allowed and
input attempts result in an EOF indication.
On some systems, the implementation of vfork() causes the
parent to inherit register values from the child. This can
create problems for certain optimizing compilers if
<unistd.h> is not included in the source calling vfork().
The Solaris vfork() does not permit the child's computation to be
interleaved with the parent's; after vfork(), the parent cannot run
until the child exits or calls exec. Except in multi-threaded
applications, when only the calling thread of control is suspended,
see the second paragraph from the manual page.
- --
Geoffrey Keating <[EMAIL PROTECTED]>
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 15 Jan 1999 22:45:00 -0800
Subject: Re: glibc 2.0.110
Fenglou Mao <[EMAIL PROTECTED]> writes:
> The most recent crypt I can found is glibc-crypt-2.0.108.
> Is it right?
No. The announcement also said it is 2.0.109 and it also said where
to get it.
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Geoff Keating <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 17:48:00 +1100
Subject: Re: glibc 2.0.110
> Date: Sat, 16 Jan 1999 13:03:08 -0800 (PST)
> From: Fenglou Mao <[EMAIL PROTECTED]>
> Cc: GNU libc testers <[EMAIL PROTECTED]>,
> VGER gcc list <[EMAIL PROTECTED]>
>
> Dear all,
> I compiled glibc 2.0.110 with no error messages.
> When I installed it, it told me:
>
> make -C manual subdir_install make[2]: Entering directory
> `/linux2/people/mao/ftp/glibc-2.0.110/manual'
> make[2]: *** No rule to make target `../crypt/genpass.c.texi', needed
> by `chapters.texi'. Stop.
> make[2]: Leaving directory `/linux2/people/mao/ftp/glibc-2.0.110/manual'
> make[1]: *** [manual/subdir_install] Error 2
> make[1]: Leaving directory `/linux2/people/mao/ftp/glibc-2.0.110'
> make: *** [install] Error 2
Hmmm. That's this change, probably:
* manual/Makefile (examples): Filter out the example code from
add-ons.
I liked it the way it was before. Can we go back?
It's particularly difficult because manual/Makefile doesn't include
the sysdep makefiles, as far as I can see, so there's no way to insert
rules to make the examples in the crypt makefile.
> After that, my egcs can not used.
> At first, it told me no lib "/usr/local/lib/libc.so.6"
> When I linked libc.2.0.7.so to /usr/local/lib/libc.so.6
> It told me no /usr/local/include/stubs.h which included ny feature.h.
>
> Can anyone help me to make my egcs can work!
Well, you need to get a working libc and/or egcs from your backup
tapes or distribution CD-ROM.
I will add `make info' to the automated tester.
- --
Geoffrey Keating <[EMAIL PROTECTED]>
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 15 Jan 1999 22:57:29 -0800
Subject: Re: glibc 2.0.110
Geoff Keating <[EMAIL PROTECTED]> writes:
> Hmmm. That's this change, probably:
It is this change.
> I liked it the way it was before. Can we go back?
I haven't changed it without a reason. `make dist' didn't worked.
> It's particularly difficult because manual/Makefile doesn't include
> the sysdep makefiles, as far as I can see, so there's no way to insert
> rules to make the examples in the crypt makefile.
Maybe all add-on Makefile can get a rule to create manual examples and
manual/Makefile uses these first.
Or: we simply say add-on must not have separate examples. I don't
think this is unreasonable.
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 15:35:27 -0800 (PST)
Subject: gcc&g++(egcs1.1.1) how to find its head files and lib?
As title.
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Peking University
BeiJing
P.R.China
Tel:86-10-62751490
Fax:86-10-62751725
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 15:46:25 -0800 (PST)
Subject: A question about the version number of glib-c?
Dear all,
I saw glibc-2.0.1, glibc-2.0.2, ..., glibc-2.0.5...
But Ulrich Drepper released the newest version of glibc-2.0.110.
I am confused, which one is the newest?
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Peking University
BeiJing
P.R.China
Tel:86-10-62751490
Fax:86-10-62751725
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 16 Jan 1999 09:20:08 +0100
Subject: Re: A question about the version number of glib-c?
>>>>> Fenglou Mao writes:
> Dear all,
> I saw glibc-2.0.1, glibc-2.0.2, ..., glibc-2.0.5...
> But Ulrich Drepper released the newest version of glibc-2.0.110.
> I am confused, which one is the newest?
What is possible to misunderstand in the following sentence by Ulrich?
UD> The next and hopefully one of the very last test releases for glibc
UD> 2.1 is available at...
glibc 2.0.6 is the last officially released version, glibc 2.0.110 is
a test release of the upcoming glibc 2.1.
Andreas
- --
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Roland McGrath <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 03:44:22 -0500
Subject: Re: vfork specs
> The Solaris vfork() does not permit the child's computation to be
> interleaved with the parent's; after vfork(), the parent cannot run
> until the child exits or calls exec. Except in multi-threaded
> applications, when only the calling thread of control is suspended,
> see the second paragraph from the manual page.
Well, exactly. It would be incomprehensibly inane to attempt to have a
vfork that did not behave that way, because of exactly this problem. It
had not before now entered my mind that Linux might have such a thing as a
vfork where both processes ran simultaneously in the same address space.
The restrictions I referred to are those on the child process not to unwind
stack frames because when the parent resumes later (after the child has
exec'd or exited), its stack pointer will be the same as it was and it will
attempt to unwind into the stack frames the child has clobbered.
------------------------------
From: Stanislav Meduna <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 10:21:06 +0100 (CET)
Subject: Re: vfork specs
> Assume this:
>
> void
> bar ()
> {
> pid_t p = baz ();
> if (p == 0)
> foo (0);
> }
> pid_t
> baz ()
> {
> return vfork ();
> }
The Single Unix Specification says:
: The vfork() function has the same effect as fork(),
: except that the behaviour is undefined if the process
: created by vfork() either modifies any data other than
: a variable of type pid_t used to store the return value
: from vfork(), or returns from the function in which
: vfork() was called, or calls any other function before
: successfully calling _exit() or one of the exec family
: of functions.
So this one is (if I interpret it correctly)
definitly bad code.
Regards
- --
Stano
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 21:59:08 -0800 (PST)
Subject: gcc path question!
Dear Ulrich Drepper,
Can you tell me how gcc(egcs1.1.1) to find the include files and
lib files?
How the dynamic library is found?
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Peking University
BeiJing
P.R.China
Tel:86-10-62751490
Fax:86-10-62751725
------------------------------
From: "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]>
Date: Sat, 16 Jan 1999 09:19:39 -0500
Subject: Re: vfork specs
In message <[EMAIL PROTECTED]>, Stanislav Meduna
writes:
+-----
| > Assume this:
| >
| > pid_t
| > baz ()
| > {
| > return vfork ();
| > }
|
| The Single Unix Specification says:
|
| : The vfork() function has the same effect as fork(),
| : except that the behaviour is undefined if the process
| : created by vfork() either modifies any data other than
| : a variable of type pid_t used to store the return value
| : from vfork(), or returns from the function in which
| : vfork() was called, or calls any other function before
| : successfully calling _exit() or one of the exec family
| : of functions.
|
| So this one is (if I interpret it correctly)
| definitly bad code.
+--->8
Yes. Return in the child -> the parent's stack pointer is now left pointing
to unknown data, because the stack is shared but the stack pointers
(obviously) aren't. (Unless #define vfork fork.)
vfork() is a horrible kludge. This is why.
- --
brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED]
system administrator [WAY too many hats] [EMAIL PROTECTED]
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 16 Jan 1999 15:25:39 +0100
Subject: Re: gcc path question!
>>>>> Fenglou Mao writes:
> Dear Ulrich Drepper,
> Can you tell me how gcc(egcs1.1.1) to find the include files and
> lib files?
> How the dynamic library is found?
Did you read the manual of gcc? info gcc will tell you everything you
need to know. Did you try to call gcc with the --help parameter?
Andreas
- --
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Sun, 17 Jan 1999 11:52:40 -0800 (PST)
Subject: Re: gcc path question!
On 16 Jan 1999, Andreas Jaeger wrote:
> > Can you tell me how gcc(egcs1.1.1) to find the include files and
> > lib files?
> > How the dynamic library is found?
> Did you read the manual of gcc? info gcc will tell you everything you
> need to know. Did you try to call gcc with the --help parameter?
>
Perhaps you misunderstanded me, or I did not post it clearly.
What I want to know is:
The Default include path and lib path.
When I use old gcc.2.7.3, it worked. But when I use new egcs.1.1.1(I
compiled before), it told me some lib error. When I use old gcc.2.7.3
to compile egcs.1.1.1 again, the stage1 passed, but when
stage1/xgcc compile itself, it told me:
./gencheck: can't resolve symbol '_dl_global_scope_end'
./gencheck: can't resolve symbol '_dl_default_scope'
And another error:
stage1/xgcc -Bstage1/ -DIN_GCC -DUSE_GNULIBC_1 -O2 -g -O2
- -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c ../../gcc/c-parse.c
c-parse.y: In function `yyparse':
c-parse.y:279: invalid type argument of `->'
c-parse.y:280: invalid type argument of `->'
... ...
Perhaps the first error was somthing about the lib, but what's the reason
of the second error?
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Peking University
BeiJing
P.R.China
Tel:86-10-62751490
Fax:86-10-62751725
------------------------------
From: Lin Zhe Min <[EMAIL PROTECTED]>
Date: Sun, 17 Jan 1999 08:13:11 +0000 (GMT)
Subject: Re: glibc 2.0.110
On Sat, 16 Jan 1999, Fenglou Mao wrote:
> The most recent crypt I can found is glibc-crypt-2.0.108.
> Is it right?
No. You can get 2.0.109 in http://www.ozemail.com.au/~geoffk/pgp/.
Why don't you read Ulrich's release-notes?
.e'osai ko sarji la lojban. ==> �����y���C
co'o mi'e lindjy,min. ==> �A���A�ڬO�L�����C
Fingerprint20 = CE32 D237 02C0 FE31 FEA9 B858 DE8F AE2D D810 F2D9
------------------------------
From: Lin Zhe Min <[EMAIL PROTECTED]>
Date: Sun, 17 Jan 1999 08:21:29 +0000 (GMT)
Subject: Re: gcc&g++(egcs1.1.1) how to find its head files and lib?
It depends on which part you need. Check
/usr/include
/usr/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/include/
(This may vary from different version)
or even
/usr/src/linux/include
to find what you need.
Try to read some documents, and run your `locate' (type `locate filename'
in shell prompt), ok?
.e'osai ko sarji la lojban. ==> �����y���C
co'o mi'e lindjy,min. ==> �A���A�ڬO�L�����C
Fingerprint20 = CE32 D237 02C0 FE31 FEA9 B858 DE8F AE2D D810 F2D9
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 17 Jan 1999 18:01:47 +0000 (GMT)
Subject: Problem compiling glibc-2.0.110
get the following errors when compiling glibc-2.0.110 with egcs-1.1.1,
binutils2.9.1.0.19a, kernel 2.2pre7ac4, glibc-2.0.109, latest linuxthreads
and crypt
egcs wcfuncs.c -c -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g
-I../include -I.
-I/usr/src/redhat/rawhide/BUILD/glibc-2.0.110/build-i386-linux/wctype -I..
-I../libio -I/usr/src/redhat/rawhide/BUILD/glibc-2.0.110/build-i386-linux
-I../sysdeps/i386/elf -I../crypt/sysdeps/unix
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/i386 -I../linuxthreads/sysdeps/pthread/no-cmpxchg
-I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv
-I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/i386/fpu -I../sysdeps/libm-i387 -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754 -I../sysdeps/libm-ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem
/usr/lib/gcc-lib/i3!
86-redhat-linux/egcs-2.91.60/include -isystem
/usr/src/redhat/rawhide/BUILD/glibc-2.0.110/linux/include -D_LIBC_REENTRANT
-include ../include/libc-symbols.h -o
/usr/src/redhat/rawhide/BUILD/glibc-2.0.110/build-i386-linux/wctype/wcfuncs.o
wcfuncs.c: In function `__iswalnum':
wcfuncs.c:42: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:42: (Each undeclared identifier is reported only once
wcfuncs.c:42: for each function it appears in.)
wcfuncs.c:42: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswalpha':
wcfuncs.c:44: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:44: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswcntrl':
wcfuncs.c:46: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:46: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswdigit':
wcfuncs.c:48: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:48: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswlower':
wcfuncs.c:50: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:50: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswgraph':
wcfuncs.c:52: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:52: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswprint':
wcfuncs.c:54: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:54: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswpunct':
wcfuncs.c:56: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:56: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswspace':
wcfuncs.c:58: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:58: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswupper':
wcfuncs.c:60: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:60: warning: control reaches end of non-void function
wcfuncs.c: In function `__iswxdigit':
wcfuncs.c:62: `__ctype32_b' undeclared (first use in this function)
wcfuncs.c:62: warning: control reaches end of non-void function
make[2]: ***
[/usr/src/redhat/rawhide/BUILD/glibc-2.0.110/build-i386-linux/wctype/wcfuncs.o]
Error 1
make[2]: Leaving directory
`/usr/src/redhat/rawhide/BUILD/glibc-2.0.110/wctype'
make[1]: *** [wctype/subdir_lib] Error 2
make[1]: Leaving directory `/usr/src/redhat/rawhide/BUILD/glibc-2.0.110'
make: *** [all] Error 2
Bad exit status from /var/tmp/rpm-tmp.58428 (%build)
I would be grateful for any help/advice. I have looked in the documentation
Peter Dyer
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 17 Jan 1999 10:13:11 -0800
Subject: Re: Problem compiling glibc-2.0.110
[EMAIL PROTECTED] writes:
> get the following errors when compiling glibc-2.0.110 with egcs-1.1.1,
binutils2.9.1.0.19a, kernel 2.2pre7ac4, glibc-2.0.109, latest linuxthreads
and crypt
Compile with optiization.
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Todd Roy <[EMAIL PROTECTED]>
Date: Mon, 18 Jan 1999 09:08:51 -0500 (EST)
Subject: Re: A question about the version number of glib-c?
**********************************************************************
This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**********************************************************************
------------------------------
From: Todd Roy <[EMAIL PROTECTED]>
Date: Mon, 18 Jan 1999 09:13:49 -0500 (EST)
Subject: Re: A question about the version number of glib-c?
> Date: Sat, 16 Jan 1999 15:46:25 -0800 (PST)
> From: Fenglou Mao <[EMAIL PROTECTED]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Sender: [EMAIL PROTECTED]
> Precedence: bulk
> X-Loop: [EMAIL PROTECTED]
> X-Orcpt: rfc822;linux-gcc-outgoing-dig
>
> Dear all,
> I saw glibc-2.0.1, glibc-2.0.2, ..., glibc-2.0.5...
> But Ulrich Drepper released the newest version of glibc-2.0.110.
> I am confused, which one is the newest?
>
> Sincerely Yours,
>
> FengLou Mao
> *******************************
> ADD:Mr. FengLou Mao
> Peking University
> BeiJing
> P.R.China
> Tel:86-10-62751490
> Fax:86-10-62751725
>
>
>
>
>
Sir,
What you are seeing is two different development trees.
One is for glibc 2.0, the other for glibc 2.1
Generally, if you see something like glibc-XXXX-2.0.Y, where Y is
a single digit, that is a release for glibc 2.0. If you see something
like glibc-XXXX-2.0.YYY where YYY is two or three digits, that is a test
release for glibc 2.1.
Also note, 2.0 has been released. I believe that the current version is
2.0.6, which can be found at ftp.gnu.org. There are development releases
in the form glibc-2.0.YpreN at alpha.gnu.org.
2.1 has not been released yet, though I can attest it is getting very close.
You can find development copies at alpha.gnu.org.
I apoligize for sending a blank message a few minutes ago. Slip of the
fingers.
- -- todd --
**********************************************************************
This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**********************************************************************
------------------------------
From: Socrate <[EMAIL PROTECTED]>
Date: Mon, 18 Jan 1999 17:46:44 +0200 (EET)
Subject: Help needed on pop3 client
Hello!
A part from a larger project that I have require to me to write a very
simple C program that connect through port 110 to a pop3 server and to
download all messages in a single file. The syntax should be:
$ program user host
and then the program should prompt for password. Then he has to get all
messages into a single local file.
I read RFCs 821 and 822 and I take a look on some examples of others
program but I didn't really approach of the goal. So, please, if anybody
can to help me with the source code of such a simple programm. Some extra
line of comment should be just perfect.
Thx a lot in advance!
Ave,
Socrate
------------------------------
From: [EMAIL PROTECTED] (Patrick J. LoPresti)
Date: 18 Jan 1999 14:47:43 -0500
Subject: LinuxThreads stack layout is not good
The appended program, when run on a stock Red Hat 5.2 system, produces
incorrect output after allocating approximately 6 megs of stack space.
Output appears after the program. (Don't forget "-lpthread" if you
compile it yourself.)
The problem is that the LinuxThreads library sets its internal notion
of STACK_SIZE to a constant 2M. It subtracts twice STACK_SIZE from
the initial value of the stack pointer and rounds down to a multiple
of STACK_SIZE to figure out a nominal "bottom-of-stack" value
for the initial thread.
It uses this bottom-of-stack value for two things.
First, it uses it to figure out which thread is calling into the
library (e.g., for thread_self() and for thread specific data); this
is the problem illustrated by the test case below. Once esp goes
below the bottom-of-stack value, the library no longer knows that the
calling thread is the initial thread. (A stock Red Hat system has a
stack size rlimit of 8M.)
Second, it uses the initial thread bottom-of-stack as the top of an
array of contiguously allocated STACK_SIZE chunks, which serve as the
stacks for additional threads. That is, the second, third,
etc. threads will have stacks which are contiguously allocated below
the nominal bottom-of-stack of the initial thread. If the stack size
rlimit is greater than 2M, this means each thread will have a stack
overlapping that of some other thread.
This is a Bad Thing. Not only does it limit each thread's stack usage
to a compiled-in constant of 2M (a value neither detectable nor
settable through getrlimit/setrlimit), it also prevents the kernel
from generating a signal on stack overflow for most threads. And
while that may be fine for C, it creates a royal pain for people (like
us) who are trying to implement a safe language on top of
LinuxThreads.
I think two things need to happen to fix these problems.
First, STACK_SIZE in LinuxThreads needs to default to a value greater
than the kernel-determined hard rlimit (under Linux, I believe this is
8M). I realize this will reduce the number of threads you can create,
so perhaps STACK_SIZE should be settable at run-time as part of an
advanced LinuxThreads-specific interface. Either way, having some
lower value hard-wired in is truly irritating.
Second, LinuxThreads should leave some amount of unallocated,
inaccessible memory between the stacks of the various threads.
Whether that is 4K or 8M, I don't care; it just needs to be an
advertised value so that we can write proper stack probes when
allocating stack space. (Yes, in JIT-compiled code we could just test
the esp every time, but some of our code is written in C, and all we
can do there is place bounds on the local variable space used.)
Without these sentinels, it is a real pain to guarantee that a user
cannot violate the safety of the language.
Thanks for your time.
- Pat
======================================================================
#include <stdio.h>
#include <pthread.h>
void * volatile x;
int
main(int argc, char *argv[])
{
pthread_key_t k;
size_t s;
pthread_key_create(&k, 0);
pthread_setspecific(k, (void *)0x100);
for (s = 0; s < 80; s++)
{
printf("%ldK %p\n", s * 100L, pthread_getspecific(k));
x = alloca(100 * 1024);
}
return 0;
}
======================================================================
0K 0x100
100K 0x100
200K 0x100
300K 0x100
400K 0x100
500K 0x100
600K 0x100
700K 0x100
800K 0x100
900K 0x100
1000K 0x100
1100K 0x100
1200K 0x100
1300K 0x100
1400K 0x100
1500K 0x100
1600K 0x100
1700K 0x100
1800K 0x100
1900K 0x100
2000K 0x100
2100K 0x100
2200K 0x100
2300K 0x100
2400K 0x100
2500K 0x100
2600K 0x100
2700K 0x100
2800K 0x100
2900K 0x100
3000K 0x100
3100K 0x100
3200K 0x100
3300K 0x100
3400K 0x100
3500K 0x100
3600K 0x100
3700K 0x100
3800K 0x100
3900K 0x100
4000K 0x100
4100K 0x100
4200K 0x100
4300K 0x100
4400K 0x100
4500K 0x100
4600K 0x100
4700K 0x100
4800K 0x100
4900K 0x100
5000K 0x100
5100K 0x100
5200K 0x100
5300K 0x100
5400K 0x100
5500K 0x100
5600K 0x100
5700K 0x100
5800K 0x100
5900K 0x100
6000K 0x100
6100K 0x100
6200K (nil)
6300K (nil)
6400K (nil)
6500K (nil)
6600K (nil)
6700K (nil)
6800K (nil)
6900K (nil)
7000K (nil)
7100K (nil)
7200K (nil)
7300K (nil)
7400K (nil)
7500K (nil)
7600K (nil)
7700K (nil)
7800K (nil)
7900K (nil)
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 18 Jan 1999 12:33:56 -0800
Subject: Re: LinuxThreads stack layout is not good
[EMAIL PROTECTED] (Patrick J. LoPresti) writes:
> This is a Bad Thing. Not only does it limit each thread's stack usage
> to a compiled-in constant of 2M (a value neither detectable nor
> settable through getrlimit/setrlimit), it also prevents the kernel
> from generating a signal on stack overflow for most threads.
You should at least try to get some understanding on the current
situation before complaining loudly. None of your points is valid for
the LinuxThreads version which currently is released with the glibc
test releases.
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: [EMAIL PROTECTED] (Patrick J. LoPresti)
Date: 18 Jan 1999 15:48:49 -0500
Subject: Re: LinuxThreads stack layout is not good
drepper> You should at least try to get some understanding on the
drepper> current situation before complaining loudly. None of your
drepper> points is valid for the LinuxThreads version which currently
drepper> is released with the glibc test releases.
A simple "fixed in glibc 2.1" would have sufficed.
I do not have a test release of glibc. I neither know nor
particularly care where to get one. The "Reporting Bugs" section of
the Texinfo manual does not say, "please make sure your bug hasn't
been fixed in some test release", it says to indicate what version of
glibc you are using (which I did implicitly by indicating "stock Red
Hat Linux 5.2").
I sent my bug report to Xavier (as the LinuxThreads documentation says
to do), bug-glibc (as the glibc documentation says to do), and
linux-gcc (since it is a Linux-specific problem). Which of these
qualifies as "complaining loudly"?
If you expect some other procedure to be followed when reporting bugs,
you should document such, and not slam someone for following the
procedure you DID document.
I am glad to hear that the problems have been fixed; thanks.
- Pat
------------------------------
From: [EMAIL PROTECTED] (Patrick J. LoPresti)
Date: 18 Jan 1999 16:16:08 -0500
Subject: Re: LinuxThreads stack layout is not good
>>>>> "drepper" == Ulrich Drepper <[EMAIL PROTECTED]> writes:
drepper> You should at least try to get some understanding on the
drepper> current situation before complaining loudly. None of your
drepper> points is valid for the LinuxThreads version which currently
drepper> is released with the glibc test releases.
I am now looking at glibc-linuxthreads-2.0.110 (I hope that is current
enough), and the only relevant differences I see are:
1) The library calls "setrlimit" to set the current stack size limit
to a little under 2 meg.
2) There is a "__pthread_nonstandard_stacks" variable which appears
to allow, in principle, different threads to have different-sized
stacks.
It seems to me that (1) does not solve the problem, because any user
program that (completely legitimately) calls "setrlimit" itself will
break the library. This could be fixed by defining STACK_SIZE to be
larger than (or equal to) the kernel-enforced hard limit.
As for (2), the support isn't really there; the variable
__pthread_nonstandard_stacks is initialized to zero and never
modified. This appears to be the start of a not-yet-finished
interface.
Since "none of my points is valid for the LinuxThreads version which
currently is released with the glibc test releases", I assume I am
missing something. What is it?
- Pat
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 18 Jan 1999 13:20:21 -0800
Subject: Re: LinuxThreads stack layout is not good
[EMAIL PROTECTED] (Patrick J. LoPresti) writes:
> Since "none of my points is valid for the LinuxThreads version which
> currently is released with the glibc test releases", I assume I am
> missing something. What is it?
int __pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize)
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: [EMAIL PROTECTED] (Patrick J. LoPresti)
Date: 18 Jan 1999 16:46:49 -0500
Subject: Re: LinuxThreads stack layout is not good
>>>>> "drepper" == Ulrich Drepper <[EMAIL PROTECTED]> writes:
drepper> int __pthread_attr_setstacksize(pthread_attr_t *attr, size_t
drepper> stacksize)
OK, thanks. I still think I see two problems:
First, manager.c:pthread_allocate_stack() needs to set
__pthread_nonstandard_stacks to 1 if the user provided a stack.
Otherwise, if the user provides a stack which is not aligned to a
multiple of 2M the default thread_self() implementation will not
correctly find the thread data. I am pretty sure this is an outright
bug (though easy to fix). Actually, you only need set it if the value
provided by the user is not aligned to a STACK_SIZE boundary, I think.
Second, the value passed to pthread_attr_setstacksize is limited to 2M
(see manager.c line 263). In other words, each thread (including the
first) is still limited to a stack size of 2M, despite the usual
kernel limit of 8M. There should be some way to get stack sizes of 8M
with sentinels. I would even argue that this should be the default,
and that users who need many many threads can write something special
to notify the library. But even if it is not the default, there
should be *some* way to get the effect.
Yes, I can use pthread_attr_setstackaddr, but what if I need
sentinels? Do I need to play mmap() games (and if so, how exactly
should I play them)? It would be nice to have an interface for this,
even a Linux-specific one.
- Pat
------------------------------
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Mon, 18 Jan 1999 19:29:07 -0800
Subject: Re: LinuxThreads stack layout is not good
From: [EMAIL PROTECTED] (Patrick J. LoPresti)
Date: 18 Jan 1999 14:47:43 -0500
it also prevents the kernel from generating a signal on stack
overflow for most threads.
This is what signal stacks are for, use them.
Later,
David S. Miller
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Mon, 18 Jan 1999 20:08:49 -0800 (PST)
Subject: Please try egcs 1.1.1 19990115/Linux.
Please try out egcs 1.1.1 19990115/Linux. There are 3 files to test
ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1-19990115-linux.diff.gz
ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/release.egcs-1.1.1
ftp://ftp.yggdrasil.com/private/hjl/egcs/1.1.1/egcs-1.1.1.spec
Please check them out. I'd like to know the results for egcs-1.1.1.spec,
Linux/ARM and Linux/MIPS before I make them public.
Thanks.
H.J.
- ----
This is the Linux/x86/alpha binary release of egcs 1.1.1 19990115/Linux.
egcs is an integrated GNU compiler system. It is derived from gcc with
many enhancements. The current egcs contains C, C++, Object C and f77
compilers plus their runtime libraries. It is highly recommended on
Linux as the default C/C++ compiler system. For details about egcs
and its source code, please consult its web page at
http://egcs.cygnus.com
The egcs 1.1.1 linux/x86 binary release can be found at
ftp://ftp.kernel.org/pub/linux/devel/gcc
ftp://tsx-11.mit.edu/pub/linux/packages/GCC
ftp://sunsite.unc.edu/pub/Linux/GCC
The bzip2 linux/x86 binaries are provided for libc 5 and glibc 2. They
are bzip2-libc5.gz and bzip2-glibc.gz in the same ftp directory.
The file list
1. egcs-1.1.1-glibc.x86.tar.bz2
In ELF/x86 and generate ELF binaries for glibc 2. gcc, cpp, cc1,
cc1plus, cc1objc, g77, version dependent header files, libstdc++,
libg++ and libg2c.a. Object C, protoize and unprotoize are untested.
To install
# cd /
# bzip2 -dc egcs-1.1.1-glibc.x86.tar.bz2 | tar xvvf -
You need glibc 2.0.7 or above to use it.
2. egcs-1.1.1-alpha.tar.bz2
In ELF/alpha and generate ELF binaries for glibc 2. gcc, cpp, cc1,
cc1plus, cc1objc, g77, version dependent header files, libstdc++,
libg++ and libg2c.a. Object C, protoize and unprotoize are untested.
To install
# cd /
# bzip2 -dc egcs-1.1.1-alpha.tar.bz2 | tar xvvf -
You need glibc 2.0.7 or above to use it.
3. egcs-1.1.1-libc5.x86.tar.bz2
In ELF/x86 and generate ELF binaries for libc 5. gcc, cpp, cc1,
cc1plus, cc1objc, g77, version dependent header files, libstdc++,
libg++ and libg2c.a. Object C, protoize and unprotoize are untested.
To install
# cd /
# bzip2 -dc egcs-1.1.1-libc5.x86.tar.bz2 | tar xvvf -
You need libc 5.4.44 or above to use it.
4. egcs-1.1.1-doc.tar.bz2
Man pages and info files for egcs and libg++. To install
# cd /
# bzip2 -dc egcs-1.1.1-doc.tar.bz2 | tar xvvf -
5. egcs-1.1.1-19990115-linux.diff.gz
A patch file which brings egcs 1.1.1 to egcs 1.1.1 19990115/Linux.
6. egcs-1.1.1.spec
A RPM spec file. You can use it to build egcs 1.1.1 19990115/Linux
if you have a good network connection. For example,
# rpm -ba egcs-1.1.1.spec
should get source and patch via ftp, then source rpm and binary rpm.
Please fix the file/directory permissions after unpacking the package
if necessary.
Please report any missing/corrupted files to [EMAIL PROTECTED]
H.J.
[EMAIL PROTECTED]
01/19/99
------------------------------
From: "Neil Youngman" <[EMAIL PROTECTED]>
Date: Tue, 19 Jan 1999 09:27:13 -0000
Subject: dynamic linker problem
We have a system, which uses dlopen() to load some libraries.
On Solaris and SCO system V we create a library with a line like:
cc -fpic a.o b.o -ly -o libx.so
then when we load libx with dlopen() it also loads liby.so.
On Linux we have been unable to get this to work. There are
possible workarounds, but we would like to stick with the
same solution that we already use on our other systems.
Does anyone if this can be made to work on Linux?
Neil
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 19 Jan 1999 17:45:04 +0100
Subject: Re: dynamic linker problem
>>>>> Neil Youngman writes:
> We have a system, which uses dlopen() to load some libraries.
> On Solaris and SCO system V we create a library with a line like:
> cc -fpic a.o b.o -ly -o libx.so
> then when we load libx with dlopen() it also loads liby.so.
> On Linux we have been unable to get this to work. There are
> possible workarounds, but we would like to stick with the
> same solution that we already use on our other systems.
> Does anyone if this can be made to work on Linux?
Which libc are you using?
The following should work with glibc2:
cc -fpic a.o b.o -shared -ly -o libx.so
If this doesn't work with glibc2, please supply a short test (just two
or three simple files) showing the problem.
Andreas
- --
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: holotko <[EMAIL PROTECTED]>
Date: Wed, 20 Jan 1999 08:14:48 +0000
Subject: Re: A question about the version number of glib-c?
Todd Roy wrote:
>
> **********************************************************************
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> **********************************************************************
??? Huh??? What???
- --
email: [EMAIL PROTECTED]
Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
He was not at all afraid for to be mashed into a pulp, or to have his
eyes gouged out and his elbows broken.
------------------------------
From: Robert Roebling <[EMAIL PROTECTED]>
Date: Wed, 20 Jan 1999 14:27:28 +0000
Subject: ldd bug
Hi,
Im using an unmodified SuSE 6.0 distribution
that comes with glibc 2.0.7 (which SuSE 6.0
modified to make it work with both libc 5
and glibc 2, I think). "ldd --version" just
says "2.0.7" and "ld --version" says "2.9.1"
if that matters.
My problem is that I'm using the iODBC library,
which is a bit special as it defines a number
of functions (namely those defined by the ODBC
standard) and loads a library for a specific
data base connection. This specific library also
has to defines all the functions of the ODBC
standard (and it couldn't work otherwise). If
I link my program statically with iODBC, I have
no problems, but when I link it dynamically, the
Linux linker gets it wrong, because the specific
ODBC driver (PostgreSQL ODBC to be precise, but
it could be any) also happen to call a few of
the ODBC functions internally and it aims to call
the ODBC functions defined in the driver, not
in iODBC, but ldd sends the calls to iODBC and
my program to heaven.
I post this to both linux-gcc and SuSE as I don't
know where the bug was introduced (guessing on
SuSE).
I'd be thankful for a reply (sent to me, I'm not
subscribed to this list).
Robert Roebling
------------------------------
From: "Neil Youngman" <[EMAIL PROTECTED]>
Date: Wed, 20 Jan 1999 17:05:28 -0000
Subject: RE: dynamic linker problem
> The following should work with glibc2:
> cc -fpic a.o b.o -shared -ly -o libx.so
>
> If this doesn't work with glibc2, please supply a short test (just two
> or three simple files) showing the problem.
Oops. I was missing the obvious. Due to an error in the makefile it wasn't
looking it in the right area for the libraries and I misinterpreted the
linker errors.
Thanks for your help
Neil
------------------------------
From: holotko <[EMAIL PROTECTED]>
Date: Thu, 21 Jan 1999 03:33:15 +0000
Subject: C++ Destructor Question
Being spoiled by Java's garbage collector leads me to this quick
question again concerning constructors in C++.
If I allocate memory via "new" using a constructor
i.e.
class Foo
{
Foo()
{ word = new char[LENGTH + 1]; }
~Foo()
{ delete word; }
...
}
When I create an object of class Foo memory will be allocated for the
char buffer "word". Now when the object is no longer needed must I
make an explicit call to the destructor ~Foo() to destroy the object
and subsequently call "delete", or, is the destructor somehow called
automatically when the object is no longer needed,i.e. outside of
it's scope?
Even in Java there are times when it is up to you to destroy an object
and/or free memory used for that object, depending on how the object
is/was created and an method equivalent of a destructor is required...
The garbage collector is not always adequate.
Thanks...
Sincerely,
/John <[EMAIL PROTECTED]>
- --
email: [EMAIL PROTECTED]
Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
There is a great alternative to war, it's called Peace.
------------------------------
From: Suresh <[EMAIL PROTECTED]>
Date: Thu, 21 Jan 99 12:02:58 IST
Subject: Re: C++ Destructor Question
Hi,
The destructor is automatically called when the
object in question is no longer needed. Such as
an object is created inside a function locally and
when the function returns the object gets killed with
the destructor executed. Hence we dont call the
destructor explicitly.
And in java I feel the garbage collection concept is
implemented quite strong and rarely do we use explicit
deallocation.
Cheers,
Suresh
Wipro-Nortel Networks
Bangalore
>
>
>Being spoiled by Java's garbage collector leads me to this quick
>question again concerning constructors in C++.
>
>If I allocate memory via "new" using a constructor
>
>i.e.
>
> class Foo
> {
> Foo()
> { word = new char[LENGTH + 1]; }
>
> ~Foo()
> { delete word; }
>
> ...
> }
>
>When I create an object of class Foo memory will be allocated for the
>char buffer "word". Now when the object is no longer needed must I
>make an explicit call to the destructor ~Foo() to destroy the object
>and subsequently call "delete", or, is the destructor somehow called
>automatically when the object is no longer needed,i.e. outside of
>it's scope?
>
>Even in Java there are times when it is up to you to destroy an object
>and/or free memory used for that object, depending on how the object
>is/was created and an method equivalent of a destructor is required...
>The garbage collector is not always adequate.
>
>Thanks...
>
>Sincerely,
>
>/John <[EMAIL PROTECTED]>
>
>
>--
>email: [EMAIL PROTECTED]
>Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
>
>There is a great alternative to war, it's called Peace.
>
- --
------------------------------
From: Joseph Keen <[EMAIL PROTECTED]>
Date: Thu, 21 Jan 1999 07:25:49 -0500 (EST)
Subject: Re: C++ Destructor Question
In C++ you must always specifically call the destructor before the
variable goes out of scope. When it goes out of scope the variable name
and the memory it points to become unlinked and there is no way for you to
go back and free that memory. That's how you get memory leaks :)
> i.e.
>
> class Foo
> {
> Foo()
> { word = new char[LENGTH + 1]; }
>
> ~Foo()
> { delete word; }
>
> ...
> }
>
> When I create an object of class Foo memory will be allocated for the
> char buffer "word". Now when the object is no longer needed must I
> make an explicit call to the destructor ~Foo() to destroy the object
> and subsequently call "delete", or, is the destructor somehow called
> automatically when the object is no longer needed,i.e. outside of
> it's scope?
------------------------------
From: Jakob Andreas Baerentzen <[EMAIL PROTECTED]>
Date: Thu, 21 Jan 1999 13:55:11 +0100 (MET)
Subject: Re: C++ Destructor Question
> In C++ you must always specifically call the destructor before the
> variable goes out of scope. When it goes out of scope the variable name
> and the memory it points to become unlinked and there is no way for you to
> go back and free that memory. That's how you get memory leaks :)
I think the above is a bit confusing. THe question was about calling the
destructor and then something about scope.
But talking about scope is confusing, since what you are talking about is
the pointers scope ... not the dynamically allocated object (would that
even make sense ... i.e. can you talk about the scope of a dynamic object
?)
Certainly memory leaks if an only pointer to some object goes out of scope
... but in many cases this doesn't matter since some other pointer will be
passed the address of the object in question.
Anyway, as Suresh pointed out, when a dynamic object is deleted it's
destructor is implicitly called.
To sum up the ways objects are destroyed:
1 When a dynamic object is deleted, the destructor is called IMPLICITLY
2 An automatic object (on the stack AFAIK) or static object will be
destroyed automatically, when it goes out of scope - i.e. at the end of a
block or at program termination, and then the destructor is called
IMPLICITLY.
The example below should serve as illustration. Three objects are created
in different ways. All are destroyed, but none explicitly. Actually, you
only rarely call the destructor EXPLICITLY, but take a look at:
http://www.cerfnet.com/~mpcline/C++-FAQs-Lite/
- -------------------------
#include <iostream.h>
class foo
{
int x;
public:
foo(int _x):x(_x) {}
~foo() { cout << "I am destroyed: " << x <<endl; }
};
foo z(1);
main()
{
foo * x = new foo(2);
delete x;
foo y(3);
}
-------
I am destroyed: 2
I am destroyed: 3
I am destroyed: 1
------------------------------
End of linux-gcc-digest V1 #358
*******************************
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".
