linux-gcc-digest Friday, July 28 2000 Volume 01 : Number 408
In this issue:
Re: glibc 2.1.91 (first test release for 2.2)
Re: glibc 2.1.91 (first test release for 2.2)
Re: Position independent code
Re: Position independent code
Re: More Position Independent Code
Re: More Position Independent Code
ANSI Colors in a C program under Linux...
ANSI Colors in a C program under Linux...
Re: ANSI Colors in a C program under Linux...
Re: ANSI Colors in a C program under Linux...
Re: Position independent code
Re: ANSI Colors in a C program under Linux...
Re: More Position Independent Code
binutils 2.10.0.12 is released.
binutils 2.10.0.18 is released.
Query on linking libraries
RE: Query on linking libraries
Re: Query on linking libraries
Re: Query on linking libraries
Query on malloc
Re: Query on malloc
linux/gcc newbie...
Re: linux/gcc newbie...
configuring g++
Query on Pthread_cond_timedwait
RE: configuring g++
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: Mark Kettenis <[EMAIL PROTECTED]>
Date: Sat, 1 Jul 2000 13:09:04 +0200
Subject: Re: glibc 2.1.91 (first test release for 2.2)
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 01 Jul 2000 01:02:13 -0700
* the utmpd daemon is also gone. It was only necessary for the transition
from glibc 2.0 to 2.1
A minor correction: The utmpd daemon was supposed to ease the
transition from libc5 to libc6. It probably never served that
purpose.
Mark
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Sat, 1 Jul 2000 14:31:30 -0700
Subject: Re: glibc 2.1.91 (first test release for 2.2)
On Sat, Jul 01, 2000 at 01:02:13AM -0700, Ulrich Drepper wrote:
> I've just uploaded to
>
> ftp://sourceware.cygnus.com/pub/glibc/releases
>
> the files
>
> glibc-2.1.91.tar.bz2 (also glibc-2.1.91.tar.gz)
> and
> glibc-linuxthreads-2.1.91.tar.gz
>
> which contain the first test release for glibc 2.2. A *lot* has
> changed and therefore no diff again 2.1.3 is available. If the
> sourceware machine is not accessible due to overload please visit one
> of the mirrors. There is *no* crypt add-on anymore. Due to the
> change in the export restrictions we can now provide the crappy code in
> the glibc sources. Do not use an old add-on.
>
With the fresh build from CVS today, the parallel "make check" failed
/bin/sh -e sort-test.sh /home/work/build/gnu/bin/glibc/ de_DE.ISO-8859-1
en_US.ISO-8859-1
/bin/sh -e tst-locale.sh /home/work/build/gnu/bin/glibc/
/bin/sh -e tst-trans.sh /home/work/build/gnu/bin/glibc/
/bin/sh -e tst-mbswcs.sh /home/work/build/gnu/bin/glibc/
/bin/sh -e tst-fmon.sh /home/work/build/gnu/bin/glibc/ tst-fmon.data
/bin/sh -e tst-ctype.sh /home/work/build/gnu/bin/glibc/
tst-fmon.sh: line 42: 29761 Segmentation fault I18NPATH=.
GCONV_PATH=${common_objpfx}/iconvdata ${common_objpfx}elf/ld.so --library-path
$common_objpfx ${common_objpfx}locale/localedef --quiet -i $cn -f $fn
${common_objpfx}localedata/$cns
make[2]: *** [do-tst-fmon] Error 139
make[2]: *** Waiting for unfinished jobs....
tst-locale.sh: line 8: 29786 Segmentation fault I18NPATH=.
GCONV_PATH=${common_objpfx}/iconvdata ${common_objpfx}elf/ld.so --library-path
$common_objpfx ${common_objpfx}locale/localedef --quiet -c -f $charmap -i
$input ${rep} ${common_objpfx}localedata/$out
make[2]: *** [do-tst-locale] Error 139
make[2]: Leaving directory `/work/gnu/src/glibc/localedata'
make[1]: *** [localedata/tests] Error 2
make[1]: Leaving directory `/work/gnu/src/glibc'
H.J.
------------------------------
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: 1 Jul 2000 15:20:20 -0700
Subject: Re: Position independent code
Followup to: <[EMAIL PROTECTED]>
By author: "Mark H. Wood" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.gcc
>
> On Thu, 29 Jun 2000, Martin v. Loewis wrote:
> [snip]
> > > On the i386 platform relative jumps are limited to an 8 bit signed
> > > offset. In order to jump further than this the jumps must be threaded (I
> > > may be wrong about this, in truth it has been a while since I did any
> > > assembly on the Intels).
> >
> > No. On the i386 platform, *all* jumps are PC-relative (except for the
> > indirect ones), so you can jump relatively to about any location you
> > want.
>
> My Intel Software Developer's Manual: Instruction Set Reference seems to
> be saying that things are more complex than that. Conditional jumps can
> be relative to CS (near jump) or relative to CS:EIP (short jump).
> Unconditional jumps can be relative to CS, relative to CS:EIP, or relative
> to a new value that the jump will load into CS (far jump). Only short
> jumps take any notice of the current EIP value. So all jumps are
> *segment*-relative, but not all are PC-relative.
>
Uh, no.
Only far jumps are absolute. Near jumps, may they be 8- (short), 16-
or 32-bit, are always PC-relative. Far jumps (those that include a
CS) are always absolute.
-hpa
- --
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Sun, 2 Jul 2000 00:30:25 +0200
Subject: Re: Position independent code
> > No. On the i386 platform, *all* jumps are PC-relative (except for the
> > indirect ones), so you can jump relatively to about any location you
> > want.
>
> My Intel Software Developer's Manual: Instruction Set Reference seems to
> be saying that things are more complex than that.
Sorry for the confusion. For PIC code, it is not that much the jmp
instructions that matter (unless there are very large functions); it
is the call instructions, invoking procedures in a different
translation units. These were the ones I was talking about; I believe
there are only relative calls (except for the ones having a target
segment as well - gcc never emits those).
Regards,
Martin
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Sun, 2 Jul 2000 00:29:36 +0200
Subject: Re: More Position Independent Code
> The purpose of PIC is really to allow position-independent data access,
> not for jump fixes.
No, not only for data access. PIC also deals with function calls; just
compile
void foo();
void bar()
{foo();}
> This call-then-pop to get EIP makes me grimace. Intel is forcing us to
> make TWO MEMORY ACCESSES just to get the value of the program counter.
> Does anyone know if Intel had a justification for this?
Sure. Compatibility to the 8086, which was in turn like the 8008/Z80
processors...
> It seems like all shared libraries and shared objects on Intel take
> a serious penalty every time they access non-auto storage.
The performance loss comes from not being able to use ebx, not because
of the overhead of loading the register. I guess a modern process does
not even touch main memory for that...
> Is GCC smart enough to figure this out in most cases, and cache the
> value of these expensive variables during long stretches of computation,
> then save the result into the real location at the end of a function
> call or basic block?
GCC will only load the PIC register only once. It will not
specifically optimize access to global variables, instead, that will
be done as part of the normal data flow analysis.
> The important point of this example is that the inline function is
> complex enough to exhaust the general-purpose registers. This means that
> expensive_var cannot be stored indefinitely in any one register. In this
> case, I think it would be Good for GCC to create an invisible automatic
> variable to store the value of expensive_var during the execution of
> crunch_numbers().
>
> Does GCC indeed do something like this?
I think it won't. Instead, it will try to clear as many registers as
possible inside the loop, and leave the variable's value in a register
- - unless the address of the variable was taken, in which case every
store will go into the variable.
Regards,
Martin
------------------------------
From: Florian Weimer <[EMAIL PROTECTED]>
Date: 02 Jul 2000 09:34:20 +0200
Subject: Re: More Position Independent Code
Scott Long <[EMAIL PROTECTED]> writes:
> This call-then-pop to get EIP makes me grimace.
Note that call-then-pop is a major performance penalty on many modern
processors (because call is not paried by ret). A local-call-move-ret
scheme is a bit more efficient.
> It seems like all shared libraries and shared objects on Intel take
> a serious penalty every time they access non-auto storage.
s/non-auto storage/global variables/
Global variables are a pain in the neck anyway, so this is just
another serious penalty. I wouldn't care about that too much.
------------------------------
From: Hendrix <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2000 02:38:28 -0230
Subject: ANSI Colors in a C program under Linux...
Hi folks,
I recently noticed that the command line 'linuxconf' program has
text-based colors in its interface... How would it be possible for me
to utilize these colors in my own C, or C++, program? I remember doing
this with ANSI colors back when I used to run my own PCBoard from
DOS... I was also experienced in using the QuickBASIC color statement
to print ANSI colors on SCREEN 0 (text mode)... Whenever I ask
questions about color and graphics in "comp.lang.c" they send me
elsewhere and say that it is compiler specific...??? I do not agree
with this!!! I think that a C program can be written with ANSI escape
characters in order to colorize a screen, and I believe that this would
be included in the ANSI Standard of the C language... It isn't graphics
functions, it just uses the ANSI escape sequences to print...
I don't know, I may very well be wrong, but if I'm not, could someone
please help me figure this out... If it is possible to present ANSI
colors in a C program (and still complie to the ANSI C Standard) then
could someone show me a "Hello World" kind of program that has a blue
background with yellow writing (much like the 'linuxconf' console
program)... Thanks a bunch for reading my ramblings...*s*
Later,
- --
Trevor Penney,
A+, Network+ Certified
- ----------------------
"That's alright, I still got my guitar"...
- -James Marshall Hendrix (11/27/1942-09/18/1970)
------------------------------
From: Hendrix <[EMAIL PROTECTED]>
Date: Tue, 04 Jul 2000 02:38:28 -0230
Subject: ANSI Colors in a C program under Linux...
Hi folks,
I recently noticed that the command line 'linuxconf' program has
text-based colors in its interface... How would it be possible for me
to utilize these colors in my own C, or C++, program? I remember doing
this with ANSI colors back when I used to run my own PCBoard from
DOS... I was also experienced in using the QuickBASIC color statement
to print ANSI colors on SCREEN 0 (text mode)... Whenever I ask
questions about color and graphics in "comp.lang.c" they send me
elsewhere and say that it is compiler specific...??? I do not agree
with this!!! I think that a C program can be written with ANSI escape
characters in order to colorize a screen, and I believe that this would
be included in the ANSI Standard of the C language... It isn't graphics
functions, it just uses the ANSI escape sequences to print...
I don't know, I may very well be wrong, but if I'm not, could someone
please help me figure this out... If it is possible to present ANSI
colors in a C program (and still complie to the ANSI C Standard) then
could someone show me a "Hello World" kind of program that has a blue
background with yellow writing (much like the 'linuxconf' console
program)... Thanks a bunch for reading my ramblings...*s*
Later,
- --
Trevor Penney,
A+, Network+ Certified
- ----------------------
"That's alright, I still got my guitar"...
- -James Marshall Hendrix (11/27/1942-09/18/1970)
------------------------------
From: Mark Gray <[EMAIL PROTECTED]>
Date: 04 Jul 2000 01:52:16 -0400
Subject: Re: ANSI Colors in a C program under Linux...
Hendrix <[EMAIL PROTECTED]> writes:
> Hi folks,
>
> I recently noticed that the command line 'linuxconf' program has
> text-based colors in its interface... How would it be possible for me
> to utilize these colors in my own C, or C++, program?
linuxconf uses ncurses for this, you could also use the slang library.
(See man ncurses and the code)
[snip]
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 04 Jul 2000 01:57:25 EDT
Subject: Re: ANSI Colors in a C program under Linux...
Have a read of man console_codes. It ain't ANSII, but ANSII don't care
what you put in a string variable or printf("..") as long as the %'s
align. Also man ncurses.
On Tue, 4 Jul 2000, Hendrix wrote:
> Hi folks,
>
> I recently noticed that the command line 'linuxconf' program has
> text-based colors in its interface... How would it be possible for me
> to utilize these colors in my own C, or C++, program? I remember doing
> this with ANSI colors back when I used to run my own PCBoard from
> DOS... I was also experienced in using the QuickBASIC color statement
> to print ANSI colors on SCREEN 0 (text mode)... Whenever I ask
> questions about color and graphics in "comp.lang.c" they send me
> elsewhere and say that it is compiler specific...??? I do not agree
> with this!!! I think that a C program can be written with ANSI escape
> characters in order to colorize a screen, and I believe that this would
> be included in the ANSI Standard of the C language... It isn't
graphics
> functions, it just uses the ANSI escape sequences to print...
>
> I don't know, I may very well be wrong, but if I'm not, could someone
> please help me figure this out... If it is possible to present ANSI
> colors in a C program (and still complie to the ANSI C Standard) then
> could someone show me a "Hello World" kind of program that has a blue
> background with yellow writing (much like the 'linuxconf' console
> program)... Thanks a bunch for reading my ramblings...*s*
>
> Later,
> --
> Trevor Penney,
> A+, Network+ Certified
> ----------------------
> "That's alright, I still got my guitar"...
> -James Marshall Hendrix (11/27/1942-09/18/1970)
>
Lawson
> We apologize if this message has reached you in error.
> Save the Planet, Save the Trees! Advertise via E mail.
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
------------------------------
From: "Mark H. Wood" <[EMAIL PROTECTED]>
Date: Wed, 5 Jul 2000 09:08:15 -0500 (EST)
Subject: Re: Position independent code
On 1 Jul 2000, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author: "Mark H. Wood" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.gcc
> >
> > On Thu, 29 Jun 2000, Martin v. Loewis wrote:
> > [snip]
> > > > On the i386 platform relative jumps are limited to an 8 bit signed
> > > > offset. In order to jump further than this the jumps must be threaded (I
> > > > may be wrong about this, in truth it has been a while since I did any
> > > > assembly on the Intels).
> > >
> > > No. On the i386 platform, *all* jumps are PC-relative (except for the
> > > indirect ones), so you can jump relatively to about any location you
[I read right over the exception. Oops.]
> > > want.
> >
> > My Intel Software Developer's Manual: Instruction Set Reference seems to
> > be saying that things are more complex than that. Conditional jumps can
> > be relative to CS (near jump) or relative to CS:EIP (short jump).
> > Unconditional jumps can be relative to CS, relative to CS:EIP, or relative
> > to a new value that the jump will load into CS (far jump). Only short
> > jumps take any notice of the current EIP value. So all jumps are
> > *segment*-relative, but not all are PC-relative.
> >
>
> Uh, no.
>
> Only far jumps are absolute. Near jumps, may they be 8- (short), 16-
> or 32-bit, are always PC-relative. Far jumps (those that include a
> CS) are always absolute.
I reread the material and found that I was being confused by the way the
various modes are being presented. There are indeed PC-relative near
jumps. But either I'm still confused, or there is still more complexity:
opcode E9 is a PC-relative near jump, but FF/4 (also near) seems to be
what Intel calls "absolute". The text (page 3-245 of the 1997 edition),
under the heading "Near and Short Jumps", discusses "absolute offsets",
and the opcode table on that page calls FF/4 "Jump near, absolute
indirect,..."
Regardless of my earlier error, the situation is more complex than what
was presented by either of the postings I quoted. It is not true that
relative jumps are constrained by an 8-bit displacement; 16- and 32-bit
forms are provided by opcode E9. It is not true that all nonindirect jumps
are PC-relative; opcode EA is "absolute" but not indirect.
I'll try to shut up now. :-/
- --
Mark H. Wood, Lead System Programmer [EMAIL PROTECTED]
I'd like to find the person who coined "short jump" but forgot "medium
jump" and "long jump".
------------------------------
From: Bolan Meek <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2000 12:08:31 -0500
Subject: Re: ANSI Colors in a C program under Linux...
Hendrix wrote:
>
> Hi folks,
>
> ...
> text-based colors in its interface... How would it be possible for me
> to utilize these colors in my own C, or C++, program?...
Much the same way: have your output to stdout have an escape sequence.
The escape sequence has ESC[???m for attributes. End the string, or
follow up soon with ESC[0m to reset to normal, unless you want
_everything_
thereafter to have those attributes. The ESC is symbolized through
GCC with '\e'.
I used http://www.google.com/search?q=&num=100 to find "ansi escape
codes".
http://www.evergreen.edu/user/serv_res/research/bsi/people/dawn/program/ansi_esc.htm
seemed like a good page, and I used it to remind myself of the exact
contents of the sequences.
> Whenever I ask
> questions about color and graphics in "comp.lang.c" they send me
> elsewhere and say that it is compiler specific...??? I do not agree
> with this!!!
Well, I think that the ESC symbolization _is_ compiler specific. But
even _more_ to the point, the color changes are _terminal_ specific.
The escape sequences below would work, but without any color change,
on an xterm coming from an HP-UX/PA box. However, on an rxvt coming
from a Debian Linux/sparc box, the colors came out just fine.
> I think that a C program can be written with ANSI escape
> characters in order to colorize a screen, and I believe that this would
> be included in the ANSI Standard of the C language... It isn't graphics
> functions, it just uses the ANSI escape sequences to print...
Here you go:
int main()
{
printf("\e[31mHello\e[32m, \e[34mBlue \e[32mWorld\e[0m.\n");
}
>
> ...If it is possible to present ANSI
> colors in a C program (and still complie to the ANSI C Standard) then
> could someone show me a "Hello World" kind of program that has
> a blue background with yellow writing ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
My, aren't we picky?
OK, as you wish:
int main()
{
printf("\e[33,44mHello, Blue World\e[0m.\n");
}
- --
[EMAIL PROTECTED] 972-729-5387
[EMAIL PROTECTED] (home phone on request)
http://www.koyote.com/users/bolan
RE: xmailtool http://www.koyote.com/users/bolan/xmailtool/index.html
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public
License.
------------------------------
From: Scott Long <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2000 10:17:43 -0700
Subject: Re: More Position Independent Code
"Martin v. Loewis" wrote:
> > It seems like all shared libraries and shared objects on Intel take
> > a serious penalty every time they access non-auto storage.
>
> The performance loss comes from not being able to use ebx, not because
> of the overhead of loading the register. I guess a modern process does
> not even touch main memory for that...
Not if the stack resides in uncacheable pages, although I can't think of
a situation in which someone would WANT that.
At any rate, thank you to all who replied on this thread, it has been
most enlightening. As I'm sure has become clear I am not someone who has
ever touched a code generator/optimizer although I'll definitely be
studying it in more detail.
Thanks,
Scott
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Sun, 9 Jul 2000 17:19:07 -0700
Subject: binutils 2.10.0.12 is released.
This is the beta release of binutils 2.10.0.12 for Linux, which is
based on binutils 2000 0701 in CVS on sourecware.cygnus.com plus
various changes. It is purely for Linux, although it has been tested
on Solaris/Sparc and Solaris/x86 from time to time.
I am planning to make the public release soon. Please test it as much
as you can.
Please report any bugs related to binutils 2.10.0.12 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared}
%{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
-dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m
armelf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.10.0.9:
1. Update from binutils 2000 0701. Fix the parallel build in ld when PE
is enabled.
Changes from binutils 2.9.5.0.46:
1. Update from binutils 2000 0617. The demangler support for the new
g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF
relocatable object files under ELF with symbol versioning.
2. Support for linking PE relocatable object files under ia32/ELF.
Changes from binutils 2.9.5.0.42:
1. Update from binutils 2000 0604. The ELF visibility attribuite should
work correctly now.
2. The ia32 assembler has changed the way it assembles the "jmp"
instructions to the global symbols. The old assembler will optimize the
jump to the global symbol defined in the same source file so that no
relocation will be used. The new assembler will use relocation for
global jumps. It will mainly affect PIC asm code. The segment like
.globl __setjmp
__setjmp:
...
jmp __sigsetjmp
...
.globl __sigsetjmp
__sigsetjmp:
is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol
and relocation will be used. Instead, it can be changed to
.globl __setjmp
__setjmp:
...
jmp sigsetjmp
...
.globl __sigsetjmp
__sigsetjmp:
sigsetjmp:
so that "jmp sigsetjmp" jumps to a local symbol and the new assembler
will optimize out the relocation.
Changes from binutils 2.9.5.0.41:
1. Update from binutils 2000 0512.
2. Add testsuite for ELF visibility.
Changes from binutils 2.9.5.0.37:
1. Update from binutils 2000 0502.
2. Support STV_HIDDEN and STV_INTERNAL.
Changes from binutils 2.9.5.0.35:
1. Update from binutils 2000 0418.
2. Fix an ld demangle style option bug.
Changes from binutils 2.9.5.0.34:
1. Update from binutils 2000 0412. Fix a relocation bug which affects
the Linux kernel compilation.
2. An ELF/PPC linker script update.
Changes from binutils 2.9.5.0.33:
1. Update from binutils 2000 0404. Fix the bug report bug.
Changes from binutils 2.9.5.0.32:
1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug.
Changes from binutils 2.9.5.0.31:
1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug.
2. Fix a Debian assembler security bug.
Changes from binutils 2.9.5.0.29:
1. Update from binutils 2000 0319.
2. An ELF/alpha bug is fixed.
Changes from binutils 2.9.5.0.27:
1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.
Changes from binutils 2.9.5.0.24:
1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.
Changes from binutils 2.9.5.0.22:
1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.
Changes from binutils 2.9.5.0.21:
1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.
Changes from binutils 2.9.5.0.19:
1. Update from binutils 1999 1122. An ia32 gas bug is fixed.
Changes from binutils 2.9.5.0.16:
1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.
Changes from binutils 2.9.5.0.14:
1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".
Changes from binutils 2.9.5.0.13:
1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.
Changes from binutils 2.9.5.0.12:
1. Update from binutils 1999 0922.
2. i370 update.
Changes from binutils 2.9.5.0.11:
1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
and sparc introduced in the last release.
2. i370 update.
Changes from binutils 2.9.5.0.10:
1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
and sparc.
2. Remove elf/hppa since it is WIP.
Changes from binutils 2.9.5.0.8:
1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
in x86 FP register names.
Changes from binutils 2.9.5.0.7:
1. Update from binutils 1999 0821.
2. Some MIPS changes.
Changes from binutils 2.9.5.0.6:
1. Update from binutils 1999 0813.
2. i370 update.
Changes from binutils 2.9.5.0.5:
1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.
Changes from binutils 2.9.5.0.4:
1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.
Changes from binutils 2.9.5.0.3:
1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.
Changes from binutils 2.9.4.0.8:
1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.
Changes from binutils 2.9.4.0.7:
1. Update from binutils 1999 0710. A weak symbol bug
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html
is fixed.
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.10.0.12.tar.gz. Source code.
2. binutils-2.10.0.9-2.10.0.12.diff.gz. Patch against the previous
beta source code.
3. binutils-2.10.0.12-1.i386.rpm. IA-32 binary RPM for RedHat 6.2.
4. binutils-2.10.0.12-1.alpha.rpm. Alpha binary RPM for RedHat 6.2.
There is no separate source rpm. You can do
# rpm -ta binutils-2.10.0.12.tar.gz
to create both binary and source rpms.
The primary ftp sites for the beta Linux binutils are:
1. ftp://ftp.valinux.com/pub/support/hjl/binutils
Thanks.
H.J. Lu
[EMAIL PROTECTED]
07/09/2000
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Thu, 20 Jul 2000 21:51:35 -0700
Subject: binutils 2.10.0.18 is released.
There are some big Linux related changes from 2.10.0.12 to 2.10.0.18.
Please test it as much as you can under Linux.
Thanks.
H.J.
- ---
This is the beta release of binutils 2.10.0.18 for Linux, which is
based on binutils 2000 0720 in CVS on sourecware.cygnus.com plus
various changes. It is purely for Linux, although it has been tested
on Solaris/Sparc and Solaris/x86 from time to time.
I am planning to make the public release soon. Please test it as much
as you can.
Please report any bugs related to binutils 2.10.0.18 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared}
%{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
-dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m
armelf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.10.0.12:
1. Update from binutils 2000 0720.
2. Fix the DT_NEEDED link bug.
3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least
on libpthread.so.
Changes from binutils 2.10.0.9:
1. Update from binutils 2000 0701. Fix the parallel build in ld when PE
is enabled.
Changes from binutils 2.9.5.0.46:
1. Update from binutils 2000 0617. The demangler support for the new
g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF
relocatable object files under ELF with symbol versioning.
2. Support for linking PE relocatable object files under ia32/ELF.
Changes from binutils 2.9.5.0.42:
1. Update from binutils 2000 0604. The ELF visibility attribuite should
work correctly now.
2. The ia32 assembler has changed the way it assembles the "jmp"
instructions to the global symbols. The old assembler will optimize the
jump to the global symbol defined in the same source file so that no
relocation will be used. The new assembler will use relocation for
global jumps. It will mainly affect PIC asm code. The segment like
.globl __setjmp
__setjmp:
...
jmp __sigsetjmp
...
.globl __sigsetjmp
__sigsetjmp:
is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol
and relocation will be used. Instead, it can be changed to
.globl __setjmp
__setjmp:
...
jmp sigsetjmp
...
.globl __sigsetjmp
__sigsetjmp:
sigsetjmp:
so that "jmp sigsetjmp" jumps to a local symbol and the new assembler
will optimize out the relocation.
Changes from binutils 2.9.5.0.41:
1. Update from binutils 2000 0512.
2. Add testsuite for ELF visibility.
Changes from binutils 2.9.5.0.37:
1. Update from binutils 2000 0502.
2. Support STV_HIDDEN and STV_INTERNAL.
Changes from binutils 2.9.5.0.35:
1. Update from binutils 2000 0418.
2. Fix an ld demangle style option bug.
Changes from binutils 2.9.5.0.34:
1. Update from binutils 2000 0412. Fix a relocation bug which affects
the Linux kernel compilation.
2. An ELF/PPC linker script update.
Changes from binutils 2.9.5.0.33:
1. Update from binutils 2000 0404. Fix the bug report bug.
Changes from binutils 2.9.5.0.32:
1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug.
Changes from binutils 2.9.5.0.31:
1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug.
2. Fix a Debian assembler security bug.
Changes from binutils 2.9.5.0.29:
1. Update from binutils 2000 0319.
2. An ELF/alpha bug is fixed.
Changes from binutils 2.9.5.0.27:
1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.
Changes from binutils 2.9.5.0.24:
1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.
Changes from binutils 2.9.5.0.22:
1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.
Changes from binutils 2.9.5.0.21:
1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.
Changes from binutils 2.9.5.0.19:
1. Update from binutils 1999 1122. An ia32 gas bug is fixed.
Changes from binutils 2.9.5.0.16:
1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.
Changes from binutils 2.9.5.0.14:
1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".
Changes from binutils 2.9.5.0.13:
1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.
Changes from binutils 2.9.5.0.12:
1. Update from binutils 1999 0922.
2. i370 update.
Changes from binutils 2.9.5.0.11:
1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
and sparc introduced in the last release.
2. i370 update.
Changes from binutils 2.9.5.0.10:
1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
and sparc.
2. Remove elf/hppa since it is WIP.
Changes from binutils 2.9.5.0.8:
1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
in x86 FP register names.
Changes from binutils 2.9.5.0.7:
1. Update from binutils 1999 0821.
2. Some MIPS changes.
Changes from binutils 2.9.5.0.6:
1. Update from binutils 1999 0813.
2. i370 update.
Changes from binutils 2.9.5.0.5:
1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.
Changes from binutils 2.9.5.0.4:
1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.
Changes from binutils 2.9.5.0.3:
1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.
Changes from binutils 2.9.4.0.8:
1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.
Changes from binutils 2.9.4.0.7:
1. Update from binutils 1999 0710. A weak symbol bug
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html
is fixed.
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.10.0.18.tar.gz. Source code.
2. binutils-2.10.0.12-2.10.0.18.diff.gz. Patch against the previous
beta source code.
3. binutils-2.10.0.18-1.i386.rpm. IA-32 binary RPM for RedHat 6.2.
4. binutils-2.10.0.18-1.alpha.rpm. Alpha binary RPM for RedHat 6.2.
There is no separate source rpm. You can do
# rpm -ta binutils-2.10.0.18.tar.gz
to create both binary and source rpms.
The primary sites for the beta Linux binutils are:
1. http://ftp.valinux.com/pub/support/hjl/binutils
Thanks.
H.J. Lu
[EMAIL PROTECTED]
07/20/2000
------------------------------
From: "Venkata Rajesh Velamakanni" <[EMAIL PROTECTED]>
Date: Mon, 24 Jul 2000 19:09:17 +0530
Subject: Query on linking libraries
This is a multi-part message in MIME format.
- ------=_NextPart_000_0019_01BFF5A2.A9EDBC20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello All,
This is regarding a query on linking libraries.=20
I would like to know whether anyone has faced=20
this problem.
I have a application, in which I open a file(test1),
and then I am calling a function defined in My library.
Inside this function I am trying open someother file
(test2) and then closing the file. While closing this
file(test2).. it errors out saying "Segmentation fault".
But this problem was not simulatable if close=20
fist file ( test1) before calling the function=20
in the library.
My test programs are here:
- --------------------------
Application.c
void
main()
{
FILE *appfd;
appfd =3D fopen("test1","w");
library();
printf("Hello World\n");
}
Library.c
#include <stdio.h>
void=20
library() {
FILE *f;
f=3Dfopen("test2","r");
fclose(f);
}
I am doing following steps to build the library:
1. cc -c -o library.o library.c
2. ld -dn -G -Bstatic -o -libmylib.a library.o
3. cc -lmylib -o application application.c
4. ./application
Can any one tell me the root cause of this problem.
Or am I missing something.
Thanks in Advance,
Rajesh.
- ------=_NextPart_000_0019_01BFF5A2.A9EDBC20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>Hello =
All,</FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>This is regarding =
a query on=20
linking libraries. </FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>I would like=20
</FONT></FONT><FONT size=3D3><FONT face=3D"Courier New">to know whether =
anyone has=20
faced </FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>this=20
problem.</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>I have a =
application, in=20
which I open a file(test1),</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>and then I am =
calling a=20
function defined in My library.</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>Inside this =
function I am=20
trying open someother file</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>(test2) and then =
closing the=20
file. While closing this</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>file(test2).. it =
errors out=20
saying "Segmentation fault".</FONT></FONT><FONT size=3D3><FONT =
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>But this=20
problem was not simulatable if close =
</STRONG></FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>fist file=20
( test1) before calling the function </FONT></FONT></FONT><FONT =
size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG></FONT></FONT></FONT><FONT size=3D3><FONT =
face=3D"Courier New">in the=20
library.</FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D3><STRONG></STRONG></FONT> </DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>My test programs =
are=20
here:</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG>--------------------------</FONT></FONT><FONT =
size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG>Application.c</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG>void</FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG>main()<BR>{<BR>  =
; FILE=20
*appfd;<BR> appfd =3D=20
fopen("test1","w");<BR> =
=20
library();<BR> =
printf("Hello=20
World\n");<BR>}<BR></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>Library.c</FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>#include=20
<stdio.h></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>void =
</FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>library()=20
{</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG> <FONT color=3D#000000>FILE=20
*f;</FONT></FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT color=3D#000000><FONT color=3D#000000><FONT face=3D"Courier =
New"><FONT=20
size=3D3><STRONG></FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"> =20
f=3Dfopen("test2","r");</FONT></FONT></FONT><FONT =
size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG></FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"> =
fclose(f);</FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"><FONT=20
color=3D#000000>}</FONT></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>I am=20
doing following steps to build the library:</FONT></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG></FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>1. cc -c -o =
library.o=20
library.c</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>2. ld -dn -G =
- -Bstatic -o=20
- -libmylib.a library.o</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>3. cc -lmylib -o =
application=20
application.c</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>4.=20
./application</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG></FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>Can any=20
one tell me the root cause of this =
problem.</STRONG></FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>Or am I=20
missing something.</FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT color=3D#000000><FONT face=3D"Courier New"><FONT=20
size=3D3><STRONG></FONT></FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG> </DIV>
<DIV><FONT face=3D"Courier New" =
size=3D3><STRONG></STRONG></FONT> </DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D3><STRONG>Thanks in=20
Advance,</FONT></FONT><FONT size=3D3><FONT=20
face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New"><FONT =
size=3D3><STRONG>Rajesh.</FONT></FONT><FONT=20
size=3D3><FONT face=3D"Courier New"></FONT></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D"Courier =
New"></FONT></STRONG> </DIV></BODY></HTML>
- ------=_NextPart_000_0019_01BFF5A2.A9EDBC20--
------------------------------
From: =?iso-8859-1?Q?Thomas_B=E4tzler?= <[EMAIL PROTECTED]>
Date: Mon, 24 Jul 2000 16:23:18 +0200
Subject: RE: Query on linking libraries
Hi,
> Venkata Rajesh Velamakanni [SMTP:[EMAIL PROTECTED]] asked:
>
> This is regarding a query on linking libraries.
> I would like to know whether anyone has faced
> this problem.
>
> I have a application, in which I open a file(test1),
> and then I am calling a function defined in My library.
> Inside this function I am trying open someother file
> (test2) and then closing the file. While closing this
> file(test2).. it errors out saying "Segmentation fault".
>
[...]
>
>
Does test2 exist? You open it in read mode and close it
without testing that the open was successful. Try this:
>
> Library.c
>
> #include <stdio.h>
>
> void
> library() {
>
if( f=fopen("test2","r") ){
fclose(f);
} else {
printf("Open in library() failed!\n");
}
> }
>
HTH,
- --
Thomas B�tzler, System Administrator, Network Operations EMEA
Harbinger, e-Business Connectivity Group, a part of Peregrine
Steinh�userstra�e 22 phone: +49-721-98143-110
D-76135 Karlsruhe / Germany fax: +49-721-98143-196
------------------------------
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Tue, 25 Jul 2000 14:29:26 +0200
Subject: Re: Query on linking libraries
On Mon, Jul 24, 2000 at 07:09:17PM +0530, Venkata Rajesh Velamakanni wrote:
> #include <stdio.h>
> void
> library() {
>
> FILE *f;
> f=fopen("test2","r");
> fclose(f);
Bug: You don't verify if the fopen was successful.
> I am doing following steps to build the library:
>
> 1. cc -c -o library.o library.c
> 2. ld -dn -G -Bstatic -o -libmylib.a library.o
> 3. cc -lmylib -o application application.c
> 4. ./application
Don't call ld directly if you don't know exactly what you're doing. You
just missed linking a ton of other files. Do something like
``cc -shared -o library.so library.c''.
Ralf
------------------------------
From: "Venkata Rajesh Velamakanni" <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2000 09:36:34 +0530
Subject: Re: Query on linking libraries
Hi,
I observed that here fopen was successful. And I am able
to simulate this problem on only one machine.. it works
fine on other machines. I would like to know whether I am
missing any patches.
Thanks,
Rajesh.
- -----Original Message-----
From: Thomas B�tzler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: 'Venkata Rajesh Velamakanni' <[EMAIL PROTECTED]>
Date: Monday, July 24, 2000 7:51 PM
Subject: RE: Query on linking libraries
Hi,
> Venkata Rajesh Velamakanni [SMTP:[EMAIL PROTECTED]] asked:
>
> This is regarding a query on linking libraries.
> I would like to know whether anyone has faced
> this problem.
>
> I have a application, in which I open a file(test1),
> and then I am calling a function defined in My library.
> Inside this function I am trying open someother file
> (test2) and then closing the file. While closing this
> file(test2).. it errors out saying "Segmentation fault".
>
[...]
>
>
Does test2 exist? You open it in read mode and close it
without testing that the open was successful. Try this:
>
> Library.c
>
> #include <stdio.h>
>
> void
> library() {
>
if( f=fopen("test2","r") ){
fclose(f);
} else {
printf("Open in library() failed!\n");
}
> }
>
HTH,
- --
Thomas B�tzler, System Administrator, Network Operations EMEA
Harbinger, e-Business Connectivity Group, a part of Peregrine
Steinh�userstra�e 22 phone: +49-721-98143-110
D-76135 Karlsruhe / Germany fax: +49-721-98143-196
------------------------------
From: "Venkata Rajesh Velamakanni" <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2000 09:58:18 +0530
Subject: Query on malloc
This is a multi-part message in MIME format.
- ------=_NextPart_000_002A_01BFF6E8.0652D2C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello All,
This is regarding a query on malloc.
Can any one tell me from where I can get the source code
of malloc.c
I observed that malloc / calloc is giving Sigmentation fault.
I would like to know the situations in which this can happen.
Can any one help me by going through the following traces
from gdb.
Following are the back traces from gdb:
- --------------------------------------------
Breakpoint 2, H245_InternalClose (H245SessionPtr=3D0x8053fc0)
at h245Common.c:3342
3342 ptr =3D malloc(len);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x4015c4e1 in chunk_alloc (ar_ptr=3D0x401f1040, nb=3D16) at =
malloc.c:2699
2699 malloc.c: No such file or directory.
(gdb) bt
#0 0x4015c4e1 in chunk_alloc (ar_ptr=3D0x401f1040, nb=3D16) at =
malloc.c:2699
#1 0x4015c40a in __libc_malloc (bytes=3D12) at malloc.c:2643
#2 0x40088002 in H245_InternalClose (H245SessionPtr=3D0x8053fc0)
at h245Common.c:3342
#3 0x400a1ce5 in H245_ReceiveThread (h245session=3D0x8053fc0)
at h245Receive.c:1671
#4 0x400f7eca in pthread_start_thread (arg=3D0xbe7ffe60) at =
manager.c:213
(gdb)=20
Thanks,
Rajesh.
- ------=_NextPart_000_002A_01BFF6E8.0652D2C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello All,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>This is regarding a query on=20
malloc.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Can any one tell me from where I can =
get the=20
source code</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>of malloc.c</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I observed that malloc / calloc is =
giving=20
Sigmentation fault.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I would like to know the situations =
in which=20
this can happen.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>Can any one =
help me by going=20
through the following traces</FONT></DIV>
<DIV><FONT size=3D2>from gdb.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Following are the back traces from gdb:</FONT></DIV>
<DIV><FONT =
size=3D2>--------------------------------------------</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Breakpoint 2, H245_InternalClose=20
(H245SessionPtr=3D0x8053fc0)<BR> at=20
h245Common.c:3342<BR>3342 ptr =3D=20
malloc(len);<BR>(gdb) n</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Program received signal SIGSEGV, =
Segmentation=20
fault.<BR>0x4015c4e1 in chunk_alloc (ar_ptr=3D0x401f1040, nb=3D16) at=20
malloc.c:2699<BR>2699 malloc.c: No such file or=20
directory.<BR>(gdb) bt<BR>#0 0x4015c4e1 in chunk_alloc =
(ar_ptr=3D0x401f1040,=20
nb=3D16) at malloc.c:2699<BR>#1 0x4015c40a in __libc_malloc =
(bytes=3D12) at=20
malloc.c:2643<BR>#2 0x40088002 in H245_InternalClose=20
(H245SessionPtr=3D0x8053fc0)<BR> at=20
h245Common.c:3342<BR>#3 0x400a1ce5 in H245_ReceiveThread=20
(h245session=3D0x8053fc0)<BR> at =
h245Receive.c:1671<BR>#4 =20
0x400f7eca in pthread_start_thread (arg=3D0xbe7ffe60) at =
manager.c:213<BR>(gdb)=20
<BR></FONT></DIV>
<DIV>Thanks,</DIV>
<DIV>Rajesh.</DIV>
<DIV><FONT size=3D2></FONT> </DIV></BODY></HTML>
- ------=_NextPart_000_002A_01BFF6E8.0652D2C0--
------------------------------
From: Andre Majorel <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2000 11:33:40
Subject: Re: Query on malloc
At 09:58 2000.07.26 +0530, Venkata Rajesh Velamakanni wrote:
>Can any one tell me from where I can get the source code
>of malloc.c
>I observed that malloc / calloc is giving Sigmentation fault.
A segfault in malloc() or free() is almost certainly due to the
heap being corrupt. It means that, before the last call to
malloc(), you have written in free()'d memory or beyond the
bounds of malloc()'d memory.
You could try linking you program with Electric Fence
(-lefence). It would help you to find the place where it
clobbers the heap.
Andr� Majorel <[EMAIL PROTECTED]>
http://www.teaser.fr/~amajorel/
------------------------------
From: Ben Miller <[EMAIL PROTECTED]>
Date: Wed, 26 Jul 2000 10:48:58 +0100
Subject: linux/gcc newbie...
Hi all,
I'm new on this list and up until now I have been programming C++
exclusively on Windows platforms. Now, I find I want to learn how to
the same on Linux. My head is currently swimming with loads of
strange notions - I know next to nothing about UNIX but I'm slowly
picking it up. Can anyone recommend some good (on-line) texts that
cover migrating your programming skills from Windows to Linux? I'm
sure loads of people have been doing this!
I have the 2.8.1 distributuion of GCC (it was installed with Linux)
and I can't figure out how to tell the compiler what default
include/lib directories to use. I know how to provide, say, an
include directory using the -I flag, but I want to set some defaults.
For example, after copying the standard C++ library headers (such as
<string>) onto the machine, gcc cannot find them unless I specifically
use the -I flag. How does it know where to find the standard C header
files?
Is it okay to ask question this basic on this list?
Best regards,
Ben Miller
Mercia Software Ltd.
Mercia House
Ashted Lock
Aston Science Park
Birmingham B7 4AZ, UK
Registered Number: 1868855 (Cardiff)
Tel: 44 (0)121 359 5096
Fax: 44 (0)121 359 0375
Web Site: http://www.mercia.com
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 26 Jul 2000 11:52:28 EDT
Subject: Re: linux/gcc newbie...
Disclaimer: g++ has a cloven hoof. I don't touch it.
On Wed, 26 Jul 2000, Ben Miller wrote:
> Hi all,
>
> I'm new on this list and up until now I have been programming C++
> exclusively on Windows platforms. Now, I find I want to learn how to
> the same on Linux. My head is currently swimming with loads of
> strange notions - I know next to nothing about UNIX but I'm slowly
> picking it up. Can anyone recommend some good (on-line) texts that
> cover migrating your programming skills from Windows to Linux? I'm
> sure loads of people have been doing this!
>
info gcc
It should be online right on your local system. I like pinfo better
than info to read info files:
http://aptiva.caltech.edu/links/rpm/redhat-6.0/RPMS/i386/pinfo-0.5.9-1.i386.rpm
> I have the 2.8.1 distributuion of GCC (it was installed with Linux)
I think the current release of gcc (2.95.2 last I looked) will provide
better g++ support.
> and I can't figure out how to tell the compiler what default
> include/lib directories to use. I know how to provide, say, an
> include directory using the -I flag, but I want to set some defaults.
> For example, after copying the standard C++ library headers (such as
> <string>) onto the machine, gcc cannot find them unless I specifically
> use the -I flag. How does it know where to find the standard C header
> files?
Where did you get them, and where did you put them?
library headers are normally included with the library. libraries? I
think you need both libg++ and libstdc++ for c++. When you install[ed]
the libraries it should [have] put the headers where the compiler can
find them.
gcc will know better where to look if you invoke it as g++. Take a look
through info gcc and see if it doesn't answer your questions.
IOW, from the command line, type
info gcc
>
> Is it okay to ask question this basic on this list?
>
> Best regards,
> Ben Miller
> Mercia Software Ltd.
> Mercia House
> Ashted Lock
> Aston Science Park
> Birmingham B7 4AZ, UK
> Registered Number: 1868855 (Cardiff)
> Tel: 44 (0)121 359 5096
> Fax: 44 (0)121 359 0375
> Web Site: http://www.mercia.com
>
>
>
Happy reading.
Lawson
| We apologize if this message has reached you in error.
| Save the Planet, Save the Trees! Advertise via E mail.
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
------------------------------
From: Ben Miller <[EMAIL PROTECTED]>
Date: Thu, 27 Jul 2000 16:20:34 +0100
Subject: configuring g++
Hello again,
Thanks for the previous responses. Now, bearing in mind that I am
picking up Linux (and Unix) as I go along, can you help me with the
following...
I'm trying to build the 2.90.8 version of the GNU Standard C++
Library. I have the libstdc++-2.90.8.tar.gz which I have unzipped
into /root/usr. Now, I'm trying to 'configure' the library so that I
can 'make' it. I'm having problems with the configuration step. The
instructions I am following (from
http://theory.uwinnipeg.ca/localfiles/infofiles/gcc/gcc_Installation.h
tml) tells me to change to the directory where I unzipped the
libstdc++ files and then execute:
$ CXX=gcc ./configure
$ make
$ make install
My problems are:
1. Why can I not just type "CXX=gcc configure" (i.e. without the "./"
bit)? (I'm too used to MS-DOS, I think!)
2. When I execute the first line (with the "./" bit included) I get
the error message: "configure: error: can not run ../config.sub". I
have this file in the "/usr/share/automake/" directory, but it seems
to be trying to get it from the "../" directory. How can I tell it
where to look for this file?
3. How does the next line ("make") know what it is I'm trying to
make!?
4. Is the last line trying to run "make" and create a target called
"install"?
Sorry if these are fairly basic questions. I feel that the way I am
learning Linus is the hard way - can anyone suggest a better
way/decent book?
Best regards,
Ben Miller.
Mercia Software Ltd.
Mercia House
Ashted Lock
Aston Science Park
Birmingham B7 4AZ, UK
Registered Number: 1868855 (Cardiff)
Tel: 44 (0)121 359 5096
Fax: 44 (0)121 359 0375
Web Site: http://www.mercia.com
------------------------------
From: "Venkata Rajesh Velamakanni" <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2000 11:04:22 +0530
Subject: Query on Pthread_cond_timedwait
This is a multi-part message in MIME format.
- ------=_NextPart_000_0064_01BFF883.95990160
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello all,
This is regarding a query on pthead_cond_timedwait..
I have received SIGSEGV from pthread_cond_timedwait.
It seems that libc has sent this signal. I would like to know
has any one faced this problem?or am I missing something.
Can any one tell me the situations where this can happen.
Following are the back traces from gdb
- ------------------------------------------------
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0 0x401977f1 in __libc_nanosleep () from /lib/libc.so.6
(gdb) bt
#0 0x401977f1 in __libc_nanosleep () from /lib/libc.so.6
#1 0x400fa429 in pthread_cond_timedwait (cond=3D0x8051d20, =
mutex=3D0x8051d08,=20
abstime=3D0xbefffbb0) at condvar.c:94
#2 0x400d3772 in OS_GetTimerSignal (signalParam=3D0xbefffd00)
at osSpecific.c:1290
#3 0x400b6e19 in timerThread (info=3D0x400ee018) at timerThread.c:93
#4 0x400faeca in pthread_start_thread (arg=3D0xbefffe60) at =
manager.c:213
(gdb)=20
Thanks,
Rajesh.
- ------=_NextPart_000_0064_01BFF883.95990160
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello all,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>This is regarding a query on=20
pthead_cond_timedwait..</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I have received SIGSEGV from=20
pthread_cond_timedwait.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>It seems that =
libc has sent=20
this signal. I would like to know</FONT></DIV>
<DIV><FONT size=3D2>has any one faced this problem?or am I missing=20
something.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Can any one tell me the situations =
where this=20
can happen.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Following are the back traces from=20
gdb</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>------------------------------------------------</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Reading symbols from=20
/lib/libpthread.so.0...done.<BR>Reading symbols from=20
/lib/libc.so.6...done.<BR>Reading symbols from=20
/lib/ld-linux.so.2...done.<BR>Reading symbols from=20
/lib/libnss_files.so.2...done.<BR>#0 0x401977f1 in =
__libc_nanosleep ()=20
from /lib/libc.so.6<BR>(gdb) bt<BR>#0 0x401977f1 in =
__libc_nanosleep ()=20
from /lib/libc.so.6<BR>#1 0x400fa429 in pthread_cond_timedwait=20
(cond=3D0x8051d20, mutex=3D0x8051d08, <BR> =
abstime=3D0xbefffbb0) at=20
condvar.c:94<BR>#2 0x400d3772 in OS_GetTimerSignal=20
(signalParam=3D0xbefffd00)<BR> at =
osSpecific.c:1290<BR>#3 =20
0x400b6e19 in timerThread (info=3D0x400ee018) at =
timerThread.c:93<BR>#4 =20
0x400faeca in pthread_start_thread (arg=3D0xbefffe60) at =
manager.c:213<BR>(gdb)=20
<BR></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Rajesh.</FONT></DIV></BODY></HTML>
- ------=_NextPart_000_0064_01BFF883.95990160--
------------------------------
From: Ben Miller <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2000 10:24:53 +0100
Subject: RE: configuring g++
Thanks for all the help everyone. I think I have a fairly good
understanding of what's going on now. My main problems now are:
1. I don't seem to have all the stuff I needed in the
libstdc++-2.90.8.tr.gz. Specifically I'm missing the config.sub file?
2. One more question: if the "make install" command copies relevant
files into system directories (assuming this is the header and lib
files for the standard C++ library) can I then remove the top
directory that I unzipped the archive into?
Thanks again everyone,
Ben.
> -----Original Message-----
> From: Andre Majorel [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, July 28, 2000 3:20 AM
> To: Ben Miller
> Subject: Re: configuring g++
>
> At 16:20 2000.07.27 +0100, Ben Miller wrote:
>
> >I'm trying to build the 2.90.8 version of the GNU Standard C++
> >Library. I have the libstdc++-2.90.8.tar.gz which I have unzipped
> >into /root/usr. Now, I'm trying to 'configure' the library so that
> I
> >can 'make' it. I'm having problems with the configuration step.
> The
> >instructions I am following (from
> >http://theory.uwinnipeg.ca/localfiles/infofiles/gcc/gcc_Installatio
> n.h
> >tml) tells me to change to the directory where I unzipped the
> >libstdc++ files and then execute:
> >
> >$ CXX=gcc ./configure
>
> They really told you to do that CXX=gcc thing ? That's unusual.
> It amounts to requiring that C++ be compiled with a C compiler.
> Oh well, they probably know what they're doing.
>
> >$ make
> >$ make install
> >
> >My problems are:
> >
> >1. Why can I not just type "CXX=gcc configure" (i.e. without the
> "./"
> >bit)? (I'm too used to MS-DOS, I think!)
>
> Depends on the configuration of your system. If the PATH
> environment variable includes "." (the current directory),
> AND the directories that come before "." in the PATH do not
> happen to contain a command named "configure", then you
> can use just "configure". Otherwise, you have to specify
> "./configure".
>
> "./configure" is best because it works in all cases and
> always does the right thing, even if you have other
> "configure" commands lying around in the path.
>
> One of the differences between DOS and Unix is that, with
> the latter, "." is not special w.r.t. to the command path ;
> like any other directory, it's searched for executables *only*
> if it's explicitly listed in PATH.
>
> [Security note: You might be tempted to change your PATH to
> something like PATH=.:/usr/local/bin:/usr/bin to get a more
> DOS-like behaviour but that would not be a good idea security
> wise. Putting ./ or other non-system directories first makes
> you more vulnerable to trojans.]
>
> >2. When I execute the first line (with the "./" bit included) I
> get
> >the error message: "configure: error: can not run ../config.sub".
> I
> >have this file in the "/usr/share/automake/" directory, but it
> seems
> >to be trying to get it from the "../" directory. How can I tell it
> >where to look for this file?
>
> Mmm... config.sub should be included in the archive. ./configure
> should look for it in the current directory, not in ../ or
> /usr/share/automake/ or whatever. I don't understand. :-(
>
> >3. How does the next line ("make") know what it is I'm trying to
> >make!?
>
> A makefile contains the rules for a number of targets. Typing
> "make foo" causes make to try to build target "foo". If you omit
> the target, make tries to build the *first* target defined in
> the makefile. Traditionally, that target is called "all" and the
> writer of the makefile has arranged so that when you try to
> build it, the program (or library) is built.
>
> >4. Is the last line trying to run "make" and create a target
> called
> >"install"?
>
> "install" is, like "all", a pseudo target. When you try to
> build it, the program (that you just compiled) is installed.
> Because "make install" generally copies file into system
> directories (/usr/bin, /usr/local/bin, etc.), you usually
> need to be root to run it.
>
> Here is a simplified typical makefile :
>
> --------------------------------------
> all: foo
>
> # Link foo
> foo: module1.o module2.o
> cc module1.o module2.o -o foo
>
> # Compile module1.c and module2.c
> module1.o: module1.c
> cc -c module1.c
>
> module2.o: module2.c
> cc -c module2.c
>
> # Install
> install:
> cp foo /usr/local/bin
> --------------------------------------
>
> "make" will run
>
> cc -c module1.c
> cc -c module2.c
> cc module1.o module2.o -o foo
>
> "make install" will run
>
> cp foo /usr/local/bin
>
> HTH. Good luck with your first steps in the Unix world. :-)
>
>
> Andr� Majorel <[EMAIL PROTECTED]>
> http://www.teaser.fr/~amajorel/
Mercia Software Ltd.
Mercia House
Ashted Lock
Aston Science Park
Birmingham B7 4AZ, UK
Registered Number: 1868855 (Cardiff)
Tel: 44 (0)121 359 5096
Fax: 44 (0)121 359 0375
Web Site: http://www.mercia.com
------------------------------
End of linux-gcc-digest V1 #408
*******************************
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".
