linux-gcc-digest Thursday, 8 April 1999 Volume 01 : Number 391
In this issue:
Writing password in /etc/passwd
Re: Writing password in /etc/passwd
Re: linux-gcc-digest V1 #390
Find Out What The Future Holds For You?
Find Out What The Future Holds For You?
Linking libraries
Re: Linking libraries
Re: Linking libraries
Re: Linking libraries
Problem with __eh_pc symbol
Opening 5000 file descriptors in linux??
readline question
Re: Opening 5000 file descriptors in linux??
Re: Opening 5000 file descriptors in linux??
Re: Opening 5000 file descriptors in linux??
pointers to template functions?
binutils 2.9.1.0.23 is released.
Type casting with malloc()
Re: Type casting with malloc()
register_frame_info
Re: Type casting with malloc()
Re: register_frame_info
Re: Type casting with malloc()
Re: Type casting with malloc()
Re: Type casting with malloc()
Re: Type casting with malloc()
Mail Filtering Source Code
problem with installing gcc-2.8.1
Re: problem with installing gcc-2.8.1
Re: problem with installing gcc-2.8.1
Re: problem with installing gcc-2.8.1
Re: problem with installing gcc-2.8.1
problem compiling gcc-2.8.1 PART III
Re: register_frame_info
Re: register_frame_info
I'm confused -- segmentation fault
Re: I'm confused -- segmentation fault
Re: I'm confused -- segmentation fault
Re: I'm confused -- segmentation fault
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: Hanbing Yan <[EMAIL PROTECTED]>
Date: Sun, 21 Mar 1999 00:06:23 -0500
Subject: Writing password in /etc/passwd
Hi,
Does anyone know how to write a program which can automatically write or
change password in the /etc/passwd?
Thanks
------------------------------
From: Vern Hoxie <[EMAIL PROTECTED]>
Date: Sun, 21 Mar 1999 00:59:38 -0700
Subject: Re: Writing password in /etc/passwd
On Sun, 21 Mar 1999, Hanbing Yan wrote:
> Does anyone know how to write a program which can automatically
> write or change password in the /etc/passwd?
1. Not a gcc problem.
2. Use /usr/bin/passwd.
vern
- --
Vernon C. Hoxie [EMAIL PROTECTED]
3975 W. 29th Ave. uucp: 303-455-2670
Denver, Colo., 80212 voice: 303-477-1780
The trouble with talking too fast is that you
may say something you haven't thought of yet.
------------------------------
From: [EMAIL PROTECTED] (Hans-Peter Jansen)
Date: Sat, 20 Mar 1999 22:30:49 +0100
Subject: Re: linux-gcc-digest V1 #390
Justin Knotzke <[EMAIL PROTECTED]> wrote:
>
> Ted Maciag wrote:
> >
> > Whose the A-hole that puts a 10 mile long PGP key in something like this?
>
> Well dude, I hate to say it but you aren't much better since you
> included it in your reply.
>
Sorry for correcting you, but he isn't _any_ better, though.
Stupidity has killed more people, than all diseases and nature
disaster together.
The only difference between them: one was intentionally stupid,
the other unconsciously.
Warning: brain damage kills!
Hans-Peter
P.S.: Justin, would you mind to translate the above to proper
english, and mail it to me (for future use).
> Justin Knotzke.
>
> - --
> Justin F. Knotzke
> [EMAIL PROTECTED]
> www.shampoo.ca
> pgp pubkey: finger -l [EMAIL PROTECTED] | pgp
>
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 21 Mar 99 20:17:31 Pacific Standard Time
Subject: Find Out What The Future Holds For You?
LIVE PERSONAL PSYCHIC! (as seen on T.V.)
LEARN TODAY WHAT YOUR FUTURE HOLDS
FOR LOVE, FAMILY, AND MONEY.
ASTROLOGY CLAIRVOYANCY
NUMBEROLOGY TAROT
ALL QUESTIONS ANSWERED IMMEDIATELY!
REALIZE YOUR DESTINY! CALL RIGHT NOW!
1-900-226-4140 or 1-800-372-3384 for VISA, MC
(These are not sex lines!)
This message is intended for Psychic Readers, Psychic Users and people who are
involved in the $1 Billion Dollar a year Psychic Industry. If this his message has
reached you in error, please disregard it and accept our apoligies. To be removed from
this list, please respond with the subject "remove". Thank You.
Stop Unsolicited Commercial Email - join CAUCE
(http://www.cauce.org)
Support HR 1748, the anti-spam bill.
LIVE PERSONAL PSYCHIC! (as seen on T.V.)
LEARN TODAY WHAT YOUR FUTURE HOLDS
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 21 Mar 99 20:17:31 Pacific Standard Time
Subject: Find Out What The Future Holds For You?
LIVE PERSONAL PSYCHIC! (as seen on T.V.)
LEARN TODAY WHAT YOUR FUTURE HOLDS
FOR LOVE, FAMILY, AND MONEY.
ASTROLOGY CLAIRVOYANCY
NUMBEROLOGY TAROT
ALL QUESTIONS ANSWERED IMMEDIATELY!
REALIZE YOUR DESTINY! CALL RIGHT NOW!
1-900-226-4140 or 1-800-372-3384 for VISA, MC
(These are not sex lines!)
This message is intended for Psychic Readers, Psychic Users and people who are
involved in the $1 Billion Dollar a year Psychic Industry. If this his message has
reached you in error, please disregard it and accept our apoligies. To be removed from
this list, please respond with the subject "remove". Thank You.
Stop Unsolicited Commercial Email - join CAUCE
(http://www.cauce.org)
Support HR 1748, the anti-spam bill.
LIVE PERSONAL PSYCHIC! (as seen on T.V.)
------------------------------
From: Iztok Polanic <[EMAIL PROTECTED]>
Date: Wed, 24 Mar 1999 21:55:24 +0100 (CET)
Subject: Linking libraries
Hello !!!
i'm having difficulties linking a header files and source files. When I
want to compile a program I type this:
#g++ 11.3.cpp Person.h -o bla
g++: Compilation of header file requested
# ls -lsaF bla
ls: bla: No such file or directory
How come that there's no executable? Here are my header and source files.
#############
Person.h
#############
#ifndef PERSON_H
#define PARSON_H
#include <iostream.h>
using namespace std;
struct Name
{
char firstname[80];
char surname[80];
void show()
{
cout << firstname << " " << surname;
}
};
struct Date
{
int day;
int month;
int year;
void show()
{
cout << month << "/" << day << "/" << year;
}
};
struct Phone
{
int areacode;
int number;
void show()
{
cout << areacode << " " << number;
}
};
struct Person
{
Name name;
Date birthdate;
Phone number;
void show()
{
cout << endl;
name.show();
cout << endl;
cout << "Born: ";
birthdate.show();
cout << endl;
cout << "Telephone: ";
number.show();
cout << endl;
}
int age(Date& date)
{
if(date.year <= birthdate.year)
return 0;
int years = date.year - birthdate.year;
if((date.month > birthdate.month) || (date.month ==
birthdate.m
return years;
else
return --years;
}
};
#endif
#############
11.3.cpp
#############
#include <iostream.h>
using namespace std;
#include "Person.h"
int main()
{
Person her = {
{ "Letitia", "Gruntfuttock" },
{ 1, 4, 1965 },
{ 212, 5551234 }
};
Person actress;
actress = her;
her.show();
Date today = { 24, 3, 1999 };
cout << endl << "Today is ";
today.show();
cout << endl;
cout << "Today " << actress.name.firstname << " is "
<< actress.age(today) << " years old."
<< endl;
return 0;
}
Bye.
//////
( o o )
/------------oOO-----O-----OOo------------\
| From: Iztok Polanic |
| E-mail: [EMAIL PROTECTED] |
| WWW: http://come.to/kotzi |
\-----------------------------------------/
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 24 Mar 1999 19:25:23 Ame
Subject: Re: Linking libraries
On Wed, 24 Mar 1999, Iztok Polanic wrote:
> Hello !!!
>
> i'm having difficulties linking a header files and source files. When I
> want to compile a program I type this:
>
> #g++ 11.3.cpp Person.h -o bla
> g++: Compilation of header file requested
>
> # ls -lsaF bla
> ls: bla: No such file or directory
>
> How come that there's no executable? Here are my header and source
> files.
Because the compile failed. Take Person.h out of the compile command
(11.3.cpp #includes it anyway, so the compiler will see it) and you will
get some nice errors you can fix. Once you fix those, you will get an
executable that says something like this when run:
Letitia Gruntfuttock
Born: 4/1/1965
Telephone: 212 5551234
Today is 3/24/1999
Today Letitia is 33 years old.
Oh, by the way, the compiler won't catch this, but you usually want to
spell the variable in the #ifndef the same way as the one in the
#define. Normally that construction is used to protect against defining
the same thing more than once. I don't know c++, and I have no
desire to learn it, but a compiler is a compiler. Want the source back
with the errors fixed?
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: Iztok Polanic <[EMAIL PROTECTED]>
Date: Thu, 25 Mar 1999 20:12:07 +0100 (CET)
Subject: Re: Linking libraries
Hello !!!
I had no errors while compiling.
TNX!
Bye.
On Wed, 24 Mar 1999 [EMAIL PROTECTED] wrote:
>
>
> Oh, by the way, the compiler won't catch this, but you usually want to
> spell the variable in the #ifndef the same way as the one in the
> #define. Normally that construction is used to protect against defining
> the same thing more than once. I don't know c++, and I have no
> desire to learn it, but a compiler is a compiler. Want the source back
> with the errors fixed?
>
> Lawson
> >< Microsoft free environment
>
> This mail client runs on Wine. Your mileage may vary.
>
>
>
>
>
> ___________________________________________________________________
> You don't need to buy Internet access to use free Internet e-mail.
> Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
> or call Juno at (800) 654-JUNO [654-5866]
>
//////
( o o )
/------------oOO-----O-----OOo------------\
| From: Iztok Polanic |
| E-mail: [EMAIL PROTECTED] |
| WWW: http://come.to/kotzi |
\-----------------------------------------/
------------------------------
From: [EMAIL PROTECTED]
Date: Thu, 25 Mar 1999 16:52:49 Ame
Subject: Re: Linking libraries
Interesting.. The errors I fixed could all have been caused by
truncation or folding, now that I look again. :-). I guess I shouldn't
have sniped at you like that. Well, it's no harm meant nor done, I
hope.
Lawson
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: Bill Metzenthen <[EMAIL PROTECTED]>
Date: Sat, 27 Mar 1999 23:56:28 +1100 (EST)
Subject: Problem with __eh_pc symbol
I've come across a problem which I think is due to an unfortunate
change in egcs.
I downloaded binaries of Netscape 4.51 for glibc and linux-2.x. The
binary won't run because a symbol __eh_pc can't be found. It appears
that the binary is probably expecting to find this symbol in
libstd++.so.2.8. After looking at versions of this library which I
have, I found an old version which actually has this symbol. This was
strange because I couldn't find the symbol anywhere in the libstd++-2.8
sources. However, it appears that the symbol used to be in the egcs
sources (the latest version of the egcs sources which I have has notes
that it was removed at some stage).
It seems to be that older versions of egcs caused this symbol to be
placed in the libstd++*.so libraries (it appears that newer versions
are probably doing the same thing with a differently named symbol).
Hence my problem, the Netscape people have linked against a library
which has been generated by an older egcs (or perhaps gcc) but the
corresponding library which I would like to use has been generated
with a more recent egcs.
Has anyone any comments on this? Is my analysis correct?
I tried to solve the problem by replacing my libstd++.so.2.8 with one
which has the __eh_pc symbol. The netscape binary now crashes with
a "Bus error" while loading.
- --
- -----------------------------------------------------------------------------
Bill Metzenthen | See http://www.linuxsupportline.com/~billm/ for info
[EMAIL PROTECTED] | on an 80x87 FPU emulator, using floating point, and
Melbourne, Australia | code for manipulating the floating point environment on
| 80x86 Linux.
- -----------------------------------------------------------------------------
------------------------------
From: Lokesh Setia <[EMAIL PROTECTED]>
Date: Sun, 28 Mar 1999 12:40:14 +0530 (IST)
Subject: Opening 5000 file descriptors in linux??
[ please cc: a copy of the reply to [EMAIL PROTECTED] as i am not
a member of this mailing list ].
Hi,
I am writing a program (somewhat similar to irc server) that would
simultaneously open ~5000 sockets and talk to all these clients. As far as
i know a process can open only about 50-60 sockets (file descriptors).
Will i have to open multiple processes with some form of IPC or shared
memory, or can i configure a kernel to let a process open any amount of
file descriptors. If yes, where in the kernel code should i change.
Can a 200MHz pentium take the load of a process with 5000 open file
descriptors, or will it just crash. Also which of the above 2 approaches
(single process or multiple process) will result in better utiliziation
and better stability.
What if the number of sockets is 20000 instead of 5000? ;-)
Thanx,
Lokesh.
------------------------------
From: Przemek Borys <[EMAIL PROTECTED]>
Date: Sun, 28 Mar 1999 12:32:34 +0200
Subject: readline question
EHLO!
How to call gnu readline function from within a ncurses program?
(to keep control over colors, and such). For now I close the curses
interface before calling readline, but this is probably not the most
elegant solution :(
- --
____\___\___
(_(\|,|_|,|_ Gassho! [http://dione.ids.pl/~pborys][mr MUA home]
| | |. [teksty o zen,programowaniu,moje sf,xfaq_pl, inne]
------------------------------
From: [EMAIL PROTECTED] (Alan Cox)
Date: Sun, 28 Mar 1999 20:36:51 +0100 (BST)
Subject: Re: Opening 5000 file descriptors in linux??
> simultaneously open ~5000 sockets and talk to all these clients. As far as
> i know a process can open only about 50-60 sockets (file descriptors).
256 in 2.0, 1024 in 2.2
There is a patch to take 2.0 to 3000. The -ac releases (and eventually I
hope 2.2 proper) have support for 2.2 handling very large numbers of file
handles
> Can a 200MHz pentium take the load of a process with 5000 open file
> descriptors, or will it just crash. Also which of the above 2 approaches
It wont just crash. Once you are talking 5000+ handles though it suggests
you need to look at your communication model. It may be 5000 handles is
the right answer, it may be that if you have little state and don't need
to do complex flow control you should use UDP - there are reasons ICQ
uses UDP for example
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 28 Mar 1999 14:34:48 -0600 (CST)
Subject: Re: Opening 5000 file descriptors in linux??
It's been rumoured that Lokesh Setia said:
>
>
> [ please cc: a copy of the reply to [EMAIL PROTECTED] as i am not
> a member of this mailing list ].
>
> Hi,
>
> Can a 200MHz pentium take the load of a process with 5000 open file
> descriptors, or will it just crash. Also which of the above 2 approaches
I don't know the answer to your question, but one traditional problem with
using tcpip sockets is that each one takes up space in kernel memory, and
so memory usage can get very large very quick. This is one reason why
UDP is frequently used for chat-liek things instead of TCP.
- --linas
------------------------------
From: "Craig Munday" <[EMAIL PROTECTED]>
Date: Tue, 30 Mar 1999 07:29:36 +1000
Subject: Re: Opening 5000 file descriptors in linux??
Lokesh,
I think you might find it problematic opening so many file descriptors.
You should consider the activity of the client, my guess is not all clients
will be active at the same time. Therefore you could have a pool of say
100 sockets (can be any number) that you share amongst the 5000 or
20000 clients. In this case each client has a type of virtual connection
in the sense that the client may not actually have an open socket but it
looks and acts as if it did.
Obviously when either the server or the client needs to send anything you
must re-establish the socket connection.
Alternatively, you might be able to define a protocol that sends packets of
data between the client and server. In this way, the socket is only open
while the packet is being sent. This might get around your problem of
having so many sockets open at once, but the process of opening and
closing so many socket connection might be over whelming.
Hope this helps.
Cheers
Craig.
- ----------
> From: Lokesh Setia <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Opening 5000 file descriptors in linux??
> Date: Sunday, March 28, 1999 5:10 PM
>
>
> [ please cc: a copy of the reply to [EMAIL PROTECTED] as i am
not
> a member of this mailing list ].
>
> Hi,
>
> I am writing a program (somewhat similar to irc server) that would
> simultaneously open ~5000 sockets and talk to all these clients. As far
as
> i know a process can open only about 50-60 sockets (file descriptors).
>
> Will i have to open multiple processes with some form of IPC or shared
> memory, or can i configure a kernel to let a process open any amount of
> file descriptors. If yes, where in the kernel code should i change.
>
> Can a 200MHz pentium take the load of a process with 5000 open file
> descriptors, or will it just crash. Also which of the above 2 approaches
> (single process or multiple process) will result in better utiliziation
> and better stability.
>
> What if the number of sockets is 20000 instead of 5000? ;-)
>
> Thanx,
>
> Lokesh.
>
------------------------------
From: Shishir Ramam <[EMAIL PROTECTED]>
Date: Tue, 30 Mar 1999 13:45:58 -0600 (CST)
Subject: pointers to template functions?
hi,
can anybody help with this ...
i have a class holding some statistics ....
class Stat{
int count1;
int count2;
}
i have two classes with class Stat embedded ..
class A{
Stat stats[10];
....
}
class B{
Stat stats[10];
....
}
both of these are encpsulated in another class ...
class C{
A x[n];
B y[m];
...
}
and now, for some k, i would like to be able to print the contents
for all j, of
x[k].stats[j, j=0..9].count1 // or count2
y[k].stats[j, j=0..9].count1 // or count2
one solution i came up with was to define template functions ....
template <class T>
printCount1(T& zz, int i){
for(int j=0;j<i;j++){
zz.stats[j].count1;
}
}
template <class T>
printCount2(T& zz, int i){
for(int j=0;j<i;j++){
zz.stats[j].count2;
}
}
obviously if i was a resonable guy, i would stop at this point and say
it was enough. but as you might have guessed, i am not. i want to
further abstract this into something like
monitor(char *msg, <pointer to template function>){
// so i can go
cout << msg;
call template function;
cout << endl;
}
i am out of my depth here, and would appreciate any help that can be
provided. thanks in advance.
- -shishir
Shishir Ramam
Graduate Student,
Computer Science and Telecommunications Program,
University of Missouri - Kansas City,
Kansas City Mo
e-mail : [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Thu, 1 Apr 1999 11:18:23 -0800 (PST)
Subject: binutils 2.9.1.0.23 is released.
Hi,
I'd like to release it to public this weekend. Please give it a try.
BTW, from now on, ftp.veresearch.com and ftp.kernel.org will be only
primary ftp sites for binutils.
Thanks.
- --
H.J. Lu ([EMAIL PROTECTED])
- --
This should be final release for binutils 2.9.1.0.x based on binutils
2.9.1. I am planning to release to public this weekend. Please test it
as much as you can. Thanks.
This is the beta release of binutils 2.9.1.0.23 for Linux, which is
based on binutils 2.9.1 plus Linux/ARM support, some x86 assembler
changes, some PPC bug fixes, some alpha bug fixes and an exception
frame optimization bug fix.
Due to the exception frame optimization bug fix, it is highly
recommended that you recompile all your C++ codes. Otherwise,
exception handling may not work right when an exception is thrown.
Since I no longer have machine running libc 5, starting from this
release, there will be no pre-compiled binaries for libc 5.
There was some problem on Linux/alpha. The binaries generated by the
new binituls may not run correctly on Linux/alpha. It turned out it was
a bug in the alpha dynamic linker in glibc 2.0.6. The current glibc 2.1
and glibc 2.0.7 should be ok.
This release should work on linux/x86/alpha. There are some ELF bug
fixes. But I don't know if it fixes all the bugs reported on
linux/sparc, Linux/MIPS and linux/PPC. I'd like to hear reports on them.
I'd like to release it to public soon. Please test it as much as you
can.
Please report any bugs related to binutils 2.9.1.0.23 to [EMAIL PROTECTED]
Changes from binutils 2.9.1.0.22:
1. Fix i386 disassembler for fwait.
2. Add "-j section" for objcopy.
3. Bug fix for linker. It should work for Linux/PPC now.
4. Add armlinux_vec for ARM/ELF.
5. Update gas documation for i386.
6. Bug fixes for Sparc/ELF.
7. Bug fixes for IBM 370.
8. Added gas documation for IBM 370.
Changes from binutils 2.9.1.0.21:
1. Add Pentium III support.
2. Add IBM 370 suppport.
3. Fix the weak undefined symbol handling.
Changes from binutils 2.9.1.0.20:
1. Ada demangle support.
2. Don't merge weak undefined symols with definitions from a shared
object when building shared object. Only for ELF.
3. Fix a 16bit x86 gas bug.
Changes from binutils 2.9.1.0.19a:
1. Enable ld for Solaris/x86.
2. Fix an ELF/i386 bfd/linker bug.
3. Fix a BFD bug.
4. Fix the ELF aligment.
5. Fix an AMD 3DNow! bug.
6. Fix ELF/x86 8/16-bit relocation bug.
7. Add --redefine-sym=old_form=new_form to objcopy.
8. Update cplus-dem.c from the egcs snapshot.
9. Support new Pentium II instructions.
10. Add --demangle/--no-demangle to ld.
Changes from binutils 2.9.1.0.21:
1. A PPC DWARF2 EH patch for gas.
Changes from binutils 2.9.1.0.19:
1. Allow '.' in the middle of a symbol name for the versioning script.
Changes from binutils 2.9.1.0.17:
1. An ELF bug fix.
Changes from binutils 2.9.1.0.16:
1. Some Linux/Sparc64 patches.
2. A shared library linking patch.
3. Update cplus-dem.c from egcs 1.1.1 release.
Changes from binutils 2.9.1.0.15:
1. Update cplus-dem.c from egcs 1.1.1 prerelease.
2. Fix ARM bugs.
3. Fix MIPS/ELF bugs.
4. Fix an objdump bug.
Changes from binutils 2.9.1.0.14:
1. Update the program header handling bug fix from the binutils
snapshot.
2. Added AMD 3DNow! support to disassembler.
Changes from binutils 2.9.1.0.13:
1. An ELF bug fix for program header handling.
2. Added AMD 3DNow! support.
3. Add some vxworks suppport.
4. Fix ld on none-linux platforms.
Changes from binutils 2.9.1.0.12:
1. An ELF/alpha bug fix for creating large shared libraries.
2. An ELF/PPC bug fix.
Changes from binutils 2.9.1.0.11:
1. Use the real fix from Ian for the exception frame optimization bug.
Changes from binutils 2.9.1.0.10:
1. Fix an exception frame optimization bug.
Changes from binutils 2.9.1.0.9:
1. Fix another -Bsymbolic bug for Linux/alpha.
Changes from binutils 2.9.1.0.7:
1. Fix -Bsymbolic for Linux/alpha.
2. Fix a 16bit x86 gas bug.
Changes from binutils 2.9.1.0.6:
1. Fix various ARM bugs.
Changes from binutils 2.9.1.0.5:
1. A MIPS assembler ".align" bug is fixed.
2. bfd.h, bfd.h and bfdlink.h are included in the binary package.
Changes from binutils 2.9.1.0.4:
1. 2 x86 16bit mode assembler bugs, "ret" and "movb $35,0x4(%di)", are
fixed.
IMPORTANT:
The .plt format that the Alpha was using was not thread safe. So I
changed it. The new format is *not* binary compatible with the old,
thus you must use glibc 2.0.4 to get an ld.so that can understand it.
Note that the new ld.so knows how to deal with the old .plt format, so
old libraries will still work, but they should be relinked eventually
for performance reasons.
The file list:
1. binutils-2.9.1.0.23.tar.gz. Source code.
2. binutils-2.9.1.0.22b-2.9.1.0.23.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.1.0.23-glibc.x86.tar.gz. Precompiled Linux/x86 binaries
for libc 6 (glibc 2.0.7 1998-12-11 or above).
4. binutils-2.9.1.0.23-alpha.tar.gz. Precompiled Linux/alpha binaries
for glibc 2.0.7 1998-12-11 or above.
5. binutils.spec. A RPM spec file for RedHat 5.2.
The primary ftp sites for the Linux binutils are:
1. ftp://ftp.varesearch.com/pub/support/hjl/binutils
2. ftp://ftp.kernel.org/pub/linux/devel/gcc
The beta directory is in private/tofu under the GCC directory.
To install the binary package, please follow the procedure very closely.
Please backup/save all the files you are instructed to delete and you
should do
gzip -dc binutils-2.9.1.0.23-glibc.x86.tar.gz | tar tvvf -
or
gzip -dc binutils-2.9.1.0.23-alpha.tar.gz | tar tvvf -
to see what is in there.
Please do back up before you remove things.
To install for libc 6 (glibc 2.0.5c or above), PLEASE DO
1. su root
2. cd /
3. rm -f /usr/bin/encaps /usr/bin/nm
4. gzip -dc binutils-2.9.1.0.23-glibc.x86.tar.gz | tar xvvf -
5. ldconfig
Now you have the new gas/binutils under /usr/bin and
/usr/ix86-linuxaout/bin. You have to use
/usr/ix86-linuxaout/bin/as
and
/usr/ix86-linuxaout/bin/ld -m i386linux
if you want to use a.out as and ld directly.
To install for alpha, PLEASE DO
1. su root
2. cd /
3. gzip -dc binutils-2.9.1.0.23-alpha.tar.gz | tar xvvf -
4. ldconfig
I have changed the target names for Linux/x86 and Linux/x86 (a.out)
to ix86-linux and ix86-linuxaout respectively. The precompiled
binaries are installed under /usr/ix86-linux and /usr/ix86-linuxaout.
You should make appropriate symbolic links if you have a different
name for the Linux/x86 target, like i586-unknown-linux.
The target name for Linux/alpha is alpha-linux. The precompiled alpha
binaries are installed under /usr/alpha-linux. You should make
appropriate symbolic links if you have a different name for the
Linux/alpha target, like alpha-redhat-linux.
If you have an old linux library in the a.out format and you cannot
obtain the newer version in the ELF format for whatever reason, you
can try "objcopy --remove-leading-char" on the a.out library and see
if it can link with your code in ELF.
Thanks.
H.J. Lu
[EMAIL PROTECTED]
03/31/99
------------------------------
From: holotko <[EMAIL PROTECTED]>
Date: Thu, 01 Apr 1999 19:34:57 +0000
Subject: Type casting with malloc()
This is a multi-part message in MIME format.
- --------------A0051A77E322F66FEDF70194
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Let's say I want to dynamically allocate some memory to an object that
I am creating using malloc(). Traditionally I do the following:
ObjectType *objectpointer; /* Decl. of pointer to object */
objectpointer = (ObjectType *)malloc(sizeof(ObjectType));
My question. Do I really need to add the type cast (ObjectType *)
before the call to malloc() ?
Traditionally I have always been taught to include the cast. However,
some references say that a cast was ONLY required in earlier versions
of C prior to standard ANSI C. Nonetheless I always type cast as that
is how I have done it for years and years. Do I really need the cast?
More precisely, do I really need the cast using gcc?
/John <[EMAIL PROTECTED]>
- --
email: [EMAIL PROTECTED]
Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
- --------------A0051A77E322F66FEDF70194
Content-Type: text/x-vcard; charset=us-ascii;
name="micros50.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for holotko
Content-Disposition: attachment;
filename="micros50.vcf"
begin:vcard
n:Holotko;John
x-mozilla-html:FALSE
org:MicroService Co.
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Programmer
note;quoted-printable:Unix, Systems Programming, Applications, =0D=0ASoftware
Develpment, Sytems Administration, =0D=0AWeb Development/Programming.
x-mozilla-cpt:;-2400
fn:John Holotko
end:vcard
- --------------A0051A77E322F66FEDF70194--
------------------------------
From: Adam Wiggins <[EMAIL PROTECTED]>
Date: Thu, 1 Apr 1999 12:13:28 -0800 (PST)
Subject: Re: Type casting with malloc()
> Let's say I want to dynamically allocate some memory to an object that
> I am creating using malloc(). Traditionally I do the following:
>
> ObjectType *objectpointer; /* Decl. of pointer to object */
>
> objectpointer = (ObjectType *)malloc(sizeof(ObjectType));
>
> My question. Do I really need to add the type cast (ObjectType *)
> before the call to malloc() ?
>
> Traditionally I have always been taught to include the cast. However,
> some references say that a cast was ONLY required in earlier versions
> of C prior to standard ANSI C. Nonetheless I always type cast as that
> is how I have done it for years and years. Do I really need the cast?
> More precisely, do I really need the cast using gcc?
You don't *need* the cast, but it will produce a warning, since malloc
returns a void pointer. I would get in the habbit of using the cast.
------------------------------
From: [EMAIL PROTECTED] (Chuck Lever)
Date: Thu, 01 Apr 1999 17:27:26 -0500
Subject: register_frame_info
whenever i (re)build a program after installing egcs 1.1.1, the
load fails with:
progname: error in loading shared libraries
: undefined symbol: __register_frame_info
i saw some discussion about this a while back, but i can't find
any resolution to the problem.
------------------------------
From: Jason Riedy <[EMAIL PROTECTED]>
Date: Thu, 01 Apr 1999 18:29:40 -0500
Subject: Re: Type casting with malloc()
And holotko writes:
- objectpointer = (ObjectType *)malloc(sizeof(ObjectType));
-
- My question. Do I really need to add the type cast (ObjectType *)
- before the call to malloc() ?
ISO C++ requires the cast. See 4.10 (p60) and C.1.2.6 (p689) of
the standard. If someone wants to compile this in C++ (for some
unknown reason), the compiler should refuse to accept it without
the cast. For justification, consider what would happen in
overloading and template parameter matching.
Jason
------------------------------
From: [EMAIL PROTECTED]
Date: Thu, 01 Apr 1999 21:15:13 Ame
Subject: Re: register_frame_info
I have lost track of why I think this, but I _think_ you need to put a
libgcc.so (should be part of egcs) in /lib, /usr/lib. or one of the
directories in /etc/ld.so.conf and rerun ldconfig. I would be
interested to know if this works. :-)
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
On Thu, 1 Apr 1999, Chuck Lever wrote:
> whenever i (re)build a program after installing egcs 1.1.1, the
> load fails with:
>
> progname: error in loading shared libraries
> : undefined symbol: __register_frame_info
>
> i saw some discussion about this a while back, but i can't find
> any resolution to the problem.
>
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: Andre Majorel <[EMAIL PROTECTED]>
Date: Fri, 02 Apr 1999 08:01:54
Subject: Re: Type casting with malloc()
At 19:34 1999.04.01 +0000, holotko wrote:
>Let's say I want to dynamically allocate some memory to an object that
>I am creating using malloc(). Traditionally I do the following:
>
> ObjectType *objectpointer; /* Decl. of pointer to object */
>
> objectpointer = (ObjectType *)malloc(sizeof(ObjectType));
>
>My question. Do I really need to add the type cast (ObjectType *)
>before the call to malloc() ?
>
>Traditionally I have always been taught to include the cast. However,
>some references say that a cast was ONLY required in earlier versions
>of C prior to standard ANSI C. Nonetheless I always type cast as that
>is how I have done it for years and years. Do I really need the cast?
>More precisely, do I really need the cast using gcc?
As far as I know, the theory is :
- - KNR C: explicit cast needed
- - ANSI C: no explicit cast
- - C++: explicit cast needed
In KNR C, malloc() used to return (char *). So the explicit cast was
necessary (to avoid warnings).
In ANSI, malloc() returns (void *) and the rule is that (void *) can be
implicitly cast to (anything *) without a warning. So an explicit cast
is useless.
In C++, the rule is that you cannot cast (void *) to (anything *)
implicitly so you have to cast explicitly (in fact, you're not
supposed to use malloc() at all).
Although, in ANSI C, an explicit cast does no harm, it's useless. I
think it's best to leave it off if only because if you change the
type of the recipient pointer from (foo *) to (bar *), you don't want
to have to change all occurrences of = (foo *) malloc() by
= (bar *) malloc().
That habit of writing (type *) malloc () is just a leftover from
pre-ANSI days. Nowadays, it makes about as much sense as writing
int n = (int) 42;
#include <warning/iamnotanexpert.h>
PS: It would be even better to use
objectpointer = malloc (sizeof *objectpointer);
Andr� Majorel <[EMAIL PROTECTED]>
http://www.teaser.fr/~amajorel/
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Thu, 1 Apr 1999 19:26:38 -0700
Subject: Re: Type casting with malloc()
On Thu, Apr 01, 1999 at 07:34:57PM +0000, holotko wrote:
> Let's say I want to dynamically allocate some memory to an object that
> I am creating using malloc(). Traditionally I do the following:
>
> ObjectType *objectpointer; /* Decl. of pointer to object */
>
> objectpointer = (ObjectType *)malloc(sizeof(ObjectType));
>
> My question. Do I really need to add the type cast (ObjectType *)
> before the call to malloc() ?
No. malloc() returns a void * which is automatically converted to the
correct type upon assignment. In general, you can assign to and from
void pointers without loss of information.
> Traditionally I have always been taught to include the cast. However,
> some references say that a cast was ONLY required in earlier versions
> of C prior to standard ANSI C. Nonetheless I always type cast as that
The cast was required in pre-ANSI days.
Kurt
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Thu, 1 Apr 1999 19:28:07 -0700
Subject: Re: Type casting with malloc()
On Thu, Apr 01, 1999 at 12:13:28PM -0800, Adam Wiggins wrote:
> > Let's say I want to dynamically allocate some memory to an object that
> > I am creating using malloc(). Traditionally I do the following:
> >
> > ObjectType *objectpointer; /* Decl. of pointer to object */
> >
> > objectpointer = (ObjectType *)malloc(sizeof(ObjectType));
> >
> > My question. Do I really need to add the type cast (ObjectType *)
> > before the call to malloc() ?
> >
> > Traditionally I have always been taught to include the cast. However,
> > some references say that a cast was ONLY required in earlier versions
> > of C prior to standard ANSI C. Nonetheless I always type cast as that
> > is how I have done it for years and years. Do I really need the cast?
> > More precisely, do I really need the cast using gcc?
>
> You don't *need* the cast, but it will produce a warning, since malloc
> returns a void pointer. I would get in the habbit of using the cast.
Only if you don't include <stdlib.h>. The cast hides the fact that you
haven't included <stdlib.h>.
Kurt
------------------------------
From: Amol Mohite <[EMAIL PROTECTED]>
Date: Fri, 2 Apr 1999 03:40:07 -0500 (EST)
Subject: Re: Type casting with malloc()
dont use malloc with objects.
It does not call the constructor.
use new and delete.
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 5 Apr 1999 12:20:29 +0800
Subject: Mail Filtering Source Code
Hi All linux expert,
I setup a sendmail (8.8.7) as MTA and connected to another PC run
windows95. my intention is to build a filtering sendmail MTA. I know
that current sendmail.cf be able to do some of the filtering feature,
but feature like filtering out or drop the packets that with IP address
or user name and domain that we want to set will not available in
sendmail.cf file, am I right? I do not know whether this be able to do
it using procmail? Do you have that kind of source code in c++ that can
share with me?
The feature is :-
1) be able to look through the packet IP adress, user name or domain,
and drop the packet if failed the condition we set.
2) look for attachment file that are MIME or Java script and drop the
mail.
Thanks in advance. I hope I can steal a bit of your time.
Best regards CS Law
------------------------------
From: Matt Adams <[EMAIL PROTECTED]>
Date: Mon, 05 Apr 1999 00:31:16 +0000
Subject: problem with installing gcc-2.8.1
Hey all,
Perhaps this is slightly off topic, and if so, my apologies. I've run into
a bit of a problem trying to compile gcc v2.8.1
I'm currently using v2.7.2.3 After I dl'ed 2.8.1 I ran the configure
for my host with the options:
--prefix=/usr
--build=i586-linux-gnu
--with-gnu-ld
--with-gnu-as
--with-elf
--enable-c-cpplib
--enable-threads=posix
AFAIK this info is correct. I then proceeded to [make LANGUAGES=c];
however, the output always cops out with the following:
gcc -b -DIN_GCC -DUSE_GNULIBC_1 -g -DHAVE_CONFIG_H -I. -I. -I./config
\
-DGCC_INCLUDE_DIR=\"/usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/include\" \
-DGPLUSPLUS_INCLUDE_DIR=\"/usr/include/g++\" \
-DOLD_GPLUSPLUS_INCLUDE_DIR=\"/usr/lib/g++-include\" \
-DLOCAL_INCLUDE_DIR=\"/usr/local/include\" \
- -DCROSS_INCLUDE_DIR=\"/usr/lib/gcc-lib/i586-pc-linux-gnulibc1/2.8.1/sys-include\"
\
-DTOOL_INCLUDE_DIR=\"/usr/i586-pc-linux-gnulibc1/include\" \
-c `echo ./cccp.c | sed 's,^\./,,'`
gcc -b -DIN_GCC -DUSE_GNULIBC_1 -g -DHAVE_CONFIG_H -I. -I. -I./config -c
./cexp.c
gcc -b -c -DIN_GCC -DUSE_GNULIBC_1 -g -DHAVE_CONFIG_H -I. -I. -I./config
version.c
ld: cannot open -lgcc: No such file or directory
make: *** [version.o] Error 1
For whatever reason I *cannot* seem to make the compiler recognize the gcc
libraries. I can't even find
a def for the [-lgcc] in the Makefile. How might I go about correcting this
problem?
Any comments or suggestions are greatly appreciated.
Thanks. Matt
- --
[EMAIL PROTECTED]
"i am a .sig virus, please \
put me in your .sig file"
------------------------------
From: [EMAIL PROTECTED]
Date: Mon, 05 Apr 1999 03:14:13 ric
Subject: Re: problem with installing gcc-2.8.1
On Mon, 5 Apr 1999, Matt Adams wrote:
> Hey all,
>
> Perhaps this is slightly off topic, and if so, my apologies. I've
run into
> a bit of a problem trying to compile gcc v2.8.1
How could a problem compiling gcc with gcc be off-topic in linux-gcc?
Are you trying to do it on solaris? :-).
>
> I'm currently using v2.7.2.3 After I dl'ed 2.8.1 I ran the
configure
> for my host with the options:
>
> --prefix=/usr
> --build=i586-linux-gnu
> --with-gnu-ld
> --with-gnu-as
> --with-elf
> --enable-c-cpplib
> --enable-threads=posix
>
> AFAIK this info is correct. I then proceeded to [make
LANGUAGES=c];
> however, the output always cops out with the following:
> gcc -b -c -DIN_GCC -DUSE_GNULIBC_1 -g -DHAVE_CONFIG_H -I. -I.
- -I./config
> version.c
> ld: cannot open -lgcc: No such file or directory
> make: *** [version.o] Error 1
>
> For whatever reason I *cannot* seem to make the compiler recognize
the gcc
> libraries. I can't even find
> a def for the [-lgcc] in the Makefile. How might I go about
correcting this
> problem?
You won't find -lgcc in the Makefile. It is implicit. You can suppress
it with -nodefaultlibs or -nostdlib, but I don't think you want to do
that. It is, as it were, the compiler's own library, it lives where the
compiler was built, and the compiler should know where to find it.
Hmmm. Are you trying to build gcc-2.8.1 in the same place gcc-2.7.2.3
lives? I don't think that will work. It wouldn't surprise me if
./configure deleted your libgcc.a..- but no, the last dir in the path
name is the gcc version number, so it shouldn't do that. Likewise for
the spec file...
Well, do gcc -v, and wherever it reads the specs from, in the same dir
there should be a libgcc.a. If it's there, I guess you could copy it to
/lib or so, or give the path with -L. If it's not, I don't know what to
tell you short of reinstall gcc-2.7.2.3.
I will probably try something like this soon. Do you know of a patch
file to get from gcc-2.7.2.3 to 2.8.x ?? :-)
Lawson
> Any comments or suggestions are greatly appreciated.
>
>
> Thanks. Matt
>
>
> --
> [EMAIL PROTECTED]
> "i am a .sig virus, please \
> put me in your .sig file"
>
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: Matt Adams <[EMAIL PROTECTED]>
Date: Mon, 05 Apr 1999 22:24:02 +0000
Subject: Re: problem with installing gcc-2.8.1
Thanks to Lawson for getting me on the right track <g>
However, it appears that the saga continues grumble, grumble....
Here is what I receive when I attempt to compile:
gcc -b -c -DIN_GCC -DUSE_CPPLIB=1 -DUSE_GNULIBC_1 -g -DHAVE_CONFIG_H -I.
- -I. -I./config version.c
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x5a): undefined reference to `main'
make: *** [version.o] Error 1
Ack! I've just begun to learn c so this is above me. (MASTER
OF THE OBVIOUS) Anyhow, suggestions are appreciated (as always)
Thanks -- Matt
- --
[EMAIL PROTECTED]
"i am a .sig virus, please \
put me in your .sig file"
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 06 Apr 1999 01:54:46 ric
Subject: Re: problem with installing gcc-2.8.1
What right track are you on, and what steps hav you taken on it? :-)
I am sorry, I didn't notice the -DUSE_GNULIBC_1 before. It should tell
you in README or INSTALL or so if this is true, but it is my impression
that gcc-2.8.1 wants to be linked with glibc-2 AKA libc-6. crt1.o is a
standard startfile, that is the entry point when you make an executable
(and the startfiles for libc-5 and -6 are not compatible) but I don't
know where it came from. You didn't ask it to make an executable. you
asked it (-c) to take version.c and make version.o. Also, I don't know
where -b came from. That is normally used to specify a target for a
cross-compile, and I have never seen it used without an argument.
I just assumed you had glibc-2. If you do, I would get the
gcc-2.7.2.3-glibc.bin.tar.gz from metalab.unc.edu/pub/Linux/GCC. That
is what I did when Wine-990131 broke the gcc-2.7.2.3 I had compiled and
linked with libc-5.0.9 (it was all I had at the time) and it has worked
fine ever since. If you don't.. well, the README or INSTALL should tell
you if you need it, but sometimes those things _do_ go on. :-)
Interesting. I just made a program baz.c: int baz(){} and compiled it
with gcc -c baz.c. No diagnostics. gcc -b -c baz.c gave me
gcc: installation problem, cannot exec `cc1': No such file or directory
gcc -o my baz.c gave
/usr/lib/crt1.o(.text+0x36): undefined reference to `main'
Something is wrong, but I am not on site, and not really all that far
beyond the "hello World" level myself. H.J??
I hope this is some use to you.
Lawson
On Mon, 5 Apr 1999, Matt Adams wrote:
> Thanks to Lawson for getting me on the right track <g>
>
> However, it appears that the saga continues grumble, grumble....
> Here is what I receive when I attempt to compile:
>
> gcc -b -c -DIN_GCC -DUSE_CPPLIB=1 -DUSE_GNULIBC_1 -g
- -DHAVE_CONFIG_H -I.
> -I. -I./config version.c
> /usr/lib/crt1.o: In function `_start':
> /usr/lib/crt1.o(.text+0x5a): undefined reference to `main'
> make: *** [version.o] Error 1
>
> Ack! I've just begun to learn c so this is above me. (MASTER
> OF THE OBVIOUS) Anyhow, suggestions are appreciated (as always)
>
> Thanks --
Matt
>
> --
> [EMAIL PROTECTED]
> "i am a .sig virus, please \
> put me in your .sig file"
>
>
>
>
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 06 Apr 1999 08:37:34 +0200
Subject: Re: problem with installing gcc-2.8.1
>>>>> Matt Adams writes:
> Hey all,
> Perhaps this is slightly off topic, and if so, my apologies. I've run into
> a bit of a problem trying to compile gcc v2.8.1
> I'm currently using v2.7.2.3 After I dl'ed 2.8.1 I ran the configure
> for my host with the options:
> --prefix=/usr
> --build=i586-linux-gnu
> --with-gnu-ld
> --with-gnu-as
> --with-elf
> --enable-c-cpplib
> --enable-threads=posix
Are you using libc5? In that case, you've give the wrong build
system. i586-linux-gnu means build for glibc2. Just remove the
- --build option and let config.guess find out the name of your system
(it will report something like i586-linux-gnulibc1).
Andreas
- --
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Matt Adams <[EMAIL PROTECTED]>
Date: Tue, 06 Apr 1999 15:09:31 +0000
Subject: problem compiling gcc-2.8.1 PART III
Part III of the saga....
cpplib.o: In function `cpp_start_read':
/root/newdl/gcc-2.8.1/cpplib.c:5983: undefined reference to `update_path'
make: *** [cc1] Error 1
GCC v2.8.1 (thanks to the help of this mailing list!!) compiles (finally
- --whew!)
Unfortunately it cops out with the above error! Any suggestions?
Thanks -- Matt
- --
[EMAIL PROTECTED]
"i am a .sig virus, please \
put me in your .sig file"
------------------------------
From: [EMAIL PROTECTED] (Chuck Lever)
Date: Wed, 07 Apr 1999 16:11:05 -0400
Subject: Re: register_frame_info
thanks lawson-
i found libgcc.a and libgcc2.a, but libgcc.so doesn't seem to appear
anywhere in the distribution i have.
egcs is useless for anything but a kernel build until i can solve this.
[EMAIL PROTECTED] wrote:
>
> I have lost track of why I think this, but I _think_ you need to put a
> libgcc.so (should be part of egcs) in /lib, /usr/lib. or one of the
> directories in /etc/ld.so.conf and rerun ldconfig. I would be
> interested to know if this works. :-)
>
> Lawson
> >< Microsoft free environment
>
> This mail client runs on Wine. Your mileage may vary.
>
> On Thu, 1 Apr 1999, Chuck Lever wrote:
>
> > whenever i (re)build a program after installing egcs 1.1.1, the
> > load fails with:
> >
> > progname: error in loading shared libraries
> > : undefined symbol: __register_frame_info
> >
> > i saw some discussion about this a while back, but i can't find
> > any resolution to the problem.
> >
>
> ___________________________________________________________________
> You don't need to buy Internet access to use free Internet e-mail.
> Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
> or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 07 Apr 1999 20:18:02 ric
Subject: Re: register_frame_info
On Wed, 7 Apr 1999, Chuck Lever wrote:
> thanks lawson-
>
> i found libgcc.a and libgcc2.a, but libgcc.so doesn't seem to appear
> anywhere in the distribution i have.
>
> egcs is useless for anything but a kernel build until i can solve this.
>
I think libgcc2.so is what I was trying to remember. You said "the load
fails with:" - did you mean during the build, or when you try to run the
program? If the latter, it has resolved the symbol when it linked it,
but can't at run time: there is some discrepancy between the paths it
feeds to ld, and to ld.so: Possibly LD_LIBRARY_PATH or -rpath-link is
more inclusive than /etc/ld.so.conf/ LD_RUN_PATH/ -rpath/ -L? Running
the build with --verbose might give you a clue...Hang on! I have been
barking up the wrong tree. I have binutils-2.9.1.0.23, which should be
about what is in egcs.. and __register_frame_info is undefined in ld,
and in libbfd-2.9.1.0.23. But it works fine for me, for all I only have
glibc-2.0.6, and the notes said I needed 2.0.7. ldd /usr/bin/ld just
lists libc.so.6 and ld-linux.so.2, but I can't find that symbol in any
library.
I tried to use libdl on libbfd, but it fails with undefined symbol
_hex_value. I dummied that, but dlsym just gives undefined symbol for
__register_frame_info. Cheers! I am now as stumped as you, if not
more. Perhaps we need glibc-2.0.7? Know where I can find a
glibc-2.0.6-2.0.7.diff.gz? I have mail only access, and it would take a
month to get the whole tarball, and I have 2.0.6. :-).
Lawson
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
------------------------------
From: Przemek Borys <[EMAIL PROTECTED]>
Date: Thu, 8 Apr 1999 16:51:26 +0200
Subject: I'm confused -- segmentation fault
EHLO!
What can cause a segmentation fault? Things, which I'm aware of, are
checked, and they are
- -incorrect malloc/realloc/free operations
- -bad hardware
- -a bug in libc
To make clear of what I'm talking about:
I wrote a program (info viewer -- pinfo), and in two functions I get
segmentation faults. I've checked it on few machines, running
different operating systems, and the result was always the same.
I also run the program compiled with -lefence, and after that I also
tried with -lccmalloc. The result was that the segmentation faults
didn't occur at all.
I've also created wrappers for malloc/realloc/free, which logged what
they werre doing. And nothing. The program sigsegv'ed on realloc() when
reallocating block of (re)allocated previously memory (of certain size).
Gdb said that all those faults came from libc_free...
So? I'm really confused, I think I'll become grey because of this ;)
And on my side, I'll take a closer look at the free() sources...
- --
____\___\___
(_(\|,|_|,|_ Gassho! [http://dione.ids.pl/~pborys][mr MUA home]
| | |. [teksty o zen,programowaniu,moje sf,xfaq_pl, inne]
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Thu, 8 Apr 1999 04:09:10 -0600
Subject: Re: I'm confused -- segmentation fault
On Thu, Apr 08, 1999 at 04:51:26PM +0200, Przemek Borys wrote:
> EHLO!
>
> What can cause a segmentation fault? Things, which I'm aware of, are
> checked, and they are
> -incorrect malloc/realloc/free operations
> -bad hardware
> -a bug in libc
>
> To make clear of what I'm talking about:
> I wrote a program (info viewer -- pinfo), and in two functions I get
> segmentation faults. I've checked it on few machines, running
> different operating systems, and the result was always the same.
> I also run the program compiled with -lefence, and after that I also
> tried with -lccmalloc. The result was that the segmentation faults
> didn't occur at all.
I don't know how ccmalloc works, but Electric Fence uses the
processor hardware to detect illegal memory accesses. By default,
its memory allocations are page aligned, so, small overruns are
not detected. Try setting EF_ALIGNMENT=0 in the shell and see
if you can detect the clobber. EF_PROTECT_BELOW=1 will catch
buffer underruns.
> I've also created wrappers for malloc/realloc/free, which logged what
> they werre doing. And nothing. The program sigsegv'ed on realloc() when
> reallocating block of (re)allocated previously memory (of certain size).
> Gdb said that all those faults came from libc_free...
Are you compiling with "-ggdb"?
Kurt
- --
lisp, v.:
To call a spade a thpade.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 08 Apr 1999 17:42:05 +0200
Subject: Re: I'm confused -- segmentation fault
>>>>> Przemek Borys writes:
> EHLO!
> What can cause a segmentation fault? Things, which I'm aware of, are
> checked, and they are
> -incorrect malloc/realloc/free operations
This includes:
- - Writing before or behind a malloced structure
- - accessing a malloced area after free has been called
> -bad hardware
> -a bug in libc
> To make clear of what I'm talking about:
> I wrote a program (info viewer -- pinfo), and in two functions I get
> segmentation faults. I've checked it on few machines, running
> different operating systems, and the result was always the same.
> I also run the program compiled with -lefence, and after that I also
> tried with -lccmalloc. The result was that the segmentation faults
> didn't occur at all.
> I've also created wrappers for malloc/realloc/free, which logged what
> they werre doing. And nothing. The program sigsegv'ed on realloc() when
> reallocating block of (re)allocated previously memory (of certain size).
> Gdb said that all those faults came from libc_free...
Looks really like a malloc problem. Run your application with
MALLOC_CHECK_=1 or 2 in the environment to call some malloc self
checks (this works with glibc2 and AFAIK also with later libc5
versions).
> So? I'm really confused, I think I'll become grey because of this ;)
> And on my side, I'll take a closer look at the free() sources...
Better check your code first, the malloc source should be ok.
Andreas
P.S. From the glibc2 manual:
Another possibility to check for and guard against bugs in the use of
@code{malloc}, @code{realloc} and @code{free} is to set the environment
variable @code{MALLOC_CHECK_}. When @code{MALLOC_CHECK_} is set, a
special (less efficient) implementation is used which is designed to be
tolerant against simple errors, such as double calls of @code{free} with
the same argument, or overruns of a single byte (off-by-one bugs). Not
all such errors can be proteced against, however, and memory leaks can
result. If @code{MALLOC_CHECK_} is set to @code{0}, any detected heap
corruption is silently ignored; if set to @code{1}, a diagnostic is
printed on @code{stderr}; if set to @code{2}, @code{abort} is called
immediately. This can be useful because otherwise a crash may happen
much later, and the true cause for the problem is then very hard to
track down.
- --
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Przemek Borys <[EMAIL PROTECTED]>
Date: Thu, 8 Apr 1999 20:41:32 +0200
Subject: Re: I'm confused -- segmentation fault
EHLO Andreas!
> > -incorrect malloc/realloc/free operations
> This includes:
> - Writing before or behind a malloced structure
> - accessing a malloced area after free has been called
Yes. The problem was in freeing, so i suppose it could be sth from this
area. but, I'll give you my wrapper's report:
[pborys@p-soft pinfo-0.4.6]$ ./pinfo bison 2>bison.log
[pborys@p-soft pinfo-0.4.6]$ tail bison.log
reallocating 134738928 to 134738928, with size 40
reallocating 134739000 to 134739000, with size 40
reallocating 134695024 to 134695024, with size 40
reallocating 134695096 to 134695096, with size 40
Allocated 134736768
Allocated 134739056
freeing 134721248
freeing 134734608
reallocating 134738928 to catched signal 11
pinfo: crash with: No such file or directory
[pborys@p-soft pinfo-0.4.6]$
(now a trace of use of the suspected memory block)
[pborys@p-soft pinfo-0.4.6]$ grep "134738928" bison.log
reallocating 134695024 to 134738928, with size 64
reallocating 134738928 to 134738928, with size 60
reallocating 134738928 to 134738928, with size 56
reallocating 134738928 to 134738928, with size 60
reallocating 134738928 to 134738928, with size 56
reallocating 134738928 to 134738928, with size 52
reallocating 134738928 to 134738928, with size 56
reallocating 134738928 to 134738928, with size 52
reallocating 134738928 to 134738928, with size 48
reallocating 134738928 to 134738928, with size 52
reallocating 134738928 to 134738928, with size 48
reallocating 134738928 to 134738928, with size 44
reallocating 134738928 to 134738928, with size 48
reallocating 134738928 to 134738928, with size 44
reallocating 134738928 to 134738928, with size 40
reallocating 134738928 to 134738928, with size 44
reallocating 134738928 to 134738928, with size 40
reallocating 134738928 to catched signal 11
[pborys@p-soft pinfo-0.4.6]$
> Looks really like a malloc problem. Run your application with
> MALLOC_CHECK_=1 or 2 in the environment to call some malloc self
> checks (this works with glibc2 and AFAIK also with later libc5
> versions).
With libc it didn't work, but I run it on a machine running glibc2, and
nothing was detected. :(
> > So? I'm really confused, I think I'll become grey because of this
> > And on my side, I'll take a closer look at the free() sources...
> Better check your code first, the malloc source should be ok.
I meant to find other possible points, which could cause a crash :)
> P.S. From the glibc2 manual:
[...]
Where do you have it from? Looks a bit better than the libc.info...
- --
____\___\___
(_(\|,|_|,|_ Gassho! [http://dione.ids.pl/~pborys][mr MUA home]
| | |. [teksty o zen,programowaniu,moje sf,xfaq_pl, inne]
------------------------------
End of linux-gcc-digest V1 #391
*******************************
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".
