linux-gcc-digest Saturday, July 1 2000 Volume 01 : Number 407
In this issue:
Re: Do me a favor!!
Re: Problem With fdopen
Re: Problem With fdopen
how to realease memory in STL?
Binutils 2.9.5.0.46 is released.
RS6000?
Re: RS6000?
how system calls implemented in glibc?
Re: how system calls implemented in glibc?
Re: how system calls implemented in glibc?
Re: how system calls implemented in glibc?
Re: RS6000?
Re: RS6000?
Re: RS6000?
Re: RS6000?
Shared libraries
Re: Shared libraries
Re: RS6000?
Re: RS6000?
problem with math.h
problem with math.h
Re: problem with math.h
Re: problem with math.h
binutils 2.10.0.9 is released.
Re: binutils 2.10.0.9 is released.
Re-directing a BSS symbol to another segment
Re: RS6000?
Position independent code
Re: Position independent code
Re: Position independent code
Re: Position independent code
More Position Independent Code
Re: More Position Independent Code
glibc 2.1.91 (first test release for 2.2)
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: Elias Athanasopoulos <[EMAIL PROTECTED]>
Date: Wed, 31 May 2000 11:05:43 +0300
Subject: Re: Do me a favor!!
Hi,
> > > The error message is the "bash : file : command not found".
> > > Why????
> >
> > Because it didn't find it where it looks for commands.
>
> Actually, because it found /usr/bin/file instead, and you failed to
> provide an argument. 'file' is a unix command.
If you execute file(1) without an argument you will get a
"usage" msg (at least in my system RH 6.2), and not a "command not
found" error _from_ bash. So, I think the problem is that "./" is
not in his path.
Regards,
Elias
- --
Elias Athanasopoulos
H.E.P & Apps. Lab.
http://www.uoa.gr/~eatha
I bet the human brain is a kludge. Marvin Minsky
------------------------------
From: Andre Majorel <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 20:01:45
Subject: Re: Problem With fdopen
At 07:23 2000.05.19 -0600, Kurt Wall wrote:
>$ gcc -ansi -Wall foo.c
>foo.c: In function `main':
>foo.c:18: warning: implicit declaration of function `fdopen'
>foo.c:18: warning: assignment makes pointer from integer without a cast
>
>I'm a touch stumped: fdopen is declared in <stdio.h> and most certainly
>returns FILE *. If I don't use `-ansi', I get no warnings, so I'm
>guessing the issue is that fdopen is POSIX.1 compliant, but not ANSI
>compliant.
SUS2 indeed says fdopen() is declared in stdio.h. But fdopen()
is not part of ISO C (at least it doesn't appear in any of the
draft standards that I have).
If -ansi is used, GCC defines __STRICT_ANSI__. Now try grepping
for that macro in /usr/include/*.h...
Andr� Majorel <[EMAIL PROTECTED]>
http://www.teaser.fr/~amajorel/
------------------------------
From: [EMAIL PROTECTED] (Aaron M. Ucko)
Date: 30 May 2000 16:04:17 -0400
Subject: Re: Problem With fdopen
Kurt Wall <[EMAIL PROTECTED]> writes:
> I'm a touch stumped: fdopen is declared in <stdio.h> and most certainly
> returns FILE *. If I don't use `-ansi', I get no warnings, so I'm
> guessing the issue is that fdopen is POSIX.1 compliant, but not ANSI
> compliant.
Correct; ANSI C needs to support systems which don't have Unix-style
file descriptors, so fopen() is the only function it provides to open
a file.
- --
Aaron M. Ucko, KB1CJC <[EMAIL PROTECTED]> (finger [EMAIL PROTECTED])
------------------------------
From: Fenglou Mao <[EMAIL PROTECTED]>
Date: Thu, 1 Jun 2000 16:15:54 +0800 (CST)
Subject: how to realease memory in STL?
hi, all,
I used a data structure in my program like this:
vector<vector<vector<vector<set<double> > > > > x;
to store my data, but I have so many data in my program,
it used so much memory, so I want to write the datas into
disk, then release the memory, I use code below to do it,
i,j,k,l is long int for loop.
set<double>& data=s[i][j][k][l];
data.erase(data.begin(),data.end());
but when I run my program, it seemed it not release the memory,
who can help me?
Thank you very much.
Sincerely Yours,
FengLou Mao
*******************************
ADD:Mr. FengLou Mao
Institute of Physical Chemistry
Peking University
BeiJing
P.R.China
Tel:86-10-62756833
Fax:86-10-62751725
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Sun, 4 Jun 2000 10:06:13 -0700
Subject: Binutils 2.9.5.0.46 is released.
This is the beta release of binutils 2.9.5.0.46 for Linux, which is
based on binutils 2000 0604 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.
I am planning to make the public release soon. Please test it as much
as you can.
Please report any bugs related to binutils 2.9.5.0.46 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.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.9.5.0.46.tar.gz. Source code.
2. binutils-2.9.5.0.42-2.9.5.0.46.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.5.0.46-1.i386.rpm. IA-32 binary RPM for RedHat 6.2.
4. binutils-2.9.5.0.46-1.alpha.rpm. Alpha binary RPM for RedHat 6.2.
There is no separate source rpm. You can do
# rpm -ta binutils-2.9.5.0.46.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]
06/04/2000
------------------------------
From: Guido Macchi <[EMAIL PROTECTED]>
Date: Tue, 6 Jun 2000 01:31:57 -0300 (ART)
Subject: RS6000?
Hi.
Anybody knows if exists a Linux implementation for the IBM RS6000?
I think that the big problem is the MicroChannel bus.
Thanks in advance.
guido
........................................................................
"One of the symptoms of an approaching nervous breakdown is the belief
that one's work is terribly important."
- Bertrand Russell (1872-1970)
"If you assume that there's no hope, you guarantee that there will be no
hope. If you assume that there is an instinct for freedom, there are
opportunities to change things, there's a chance you may contribute to
making a better world. That's your choice"
- Noam Chomsky
........................................................................
------------------------------
From: [EMAIL PROTECTED]
Date: Tue, 6 Jun 2000 19:17:46 -0500 (CDT)
Subject: Re: RS6000?
It's been rumoured that Guido Macchi said:
>
> Hi.
>
> Anybody knows if exists a Linux implementation for the IBM RS6000?
I think that IBM sells & supports this. Or at least they were planing
to a few years ago.
- --linas
------------------------------
From: Junaid Iqbal <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 13:04:46 +0500
Subject: how system calls implemented in glibc?
hi all.
I m unable to undersatnd how system calls implemented in glibc (ver
2.1.3).
for example __libc_system function (defined in system.c) have these
lines
#include <errno.h>
#include <stdlib.h>
/* Execute LINE as a shell command. */
int
__libc_system (line)
const char *line;
{
if (line == NULL)
return 0; /* This indicates no command processor. */
__sys_errno (ENOSYS);
return -1;
}
weak_alias (__libc_system, system)
stub_warning (system)
#include <stub-tag.h>
can some one give me hand in understanding this?
thanks in advance.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 08 Jun 2000 11:13:27 +0200
Subject: Re: how system calls implemented in glibc?
>>>>> Junaid Iqbal writes:
> hi all.
> I m unable to undersatnd how system calls implemented in glibc (ver
> 2.1.3).
> for example __libc_system function (defined in system.c) have these
> lines
That's the fall back in sysdeps/generic/system.c, the function used on
Linux is in sysdeps/posix/system.c. Read the documentation about the
sysdeps directory and have also a look at syscalls.list.
> #include <errno.h>
> #include <stdlib.h>
> /* Execute LINE as a shell command. */
> int
> __libc_system (line)
> const char *line;
> {
> if (line == NULL)
> return 0; /* This indicates no command processor. */
> __sys_errno (ENOSYS);
> return -1;
> }
> weak_alias (__libc_system, system)
> stub_warning (system)
> #include <stub-tag.h>
> can some one give me hand in understanding this?
> thanks in advance.
- --
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: Junaid Iqbal <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 16:25:33 +0500
Subject: Re: how system calls implemented in glibc?
Thanks for ur reply.
got it. looking in wrong path. from where i can get docs on sysdeps dir
structure and some detail on its functions
One more problem. i m looking for File System functions like __unlink ,
__open etc.
they r defined in 2 places in the tree under sysdeps/mach/hurd/unlink.c
or in /sysdeps/generic/unlink.c
generic/unlink.c is same as generic/system.c.
sysdeps/mach/hurd/unlink.c looks like the main unlink code. but its using
some functions which i m unable to find.
like __dir_unlink.
Andreas Jaeger wrote:
> >>>>> Junaid Iqbal writes:
>
> > hi all.
> > I m unable to undersatnd how system calls implemented in glibc (ver
> > 2.1.3).
> > for example __libc_system function (defined in system.c) have these
> > lines
> That's the fall back in sysdeps/generic/system.c, the function used on
> Linux is in sysdeps/posix/system.c. Read the documentation about the
> sysdeps directory and have also a look at syscalls.list.
>
> > #include <errno.h>
> > #include <stdlib.h>
>
> > /* Execute LINE as a shell command. */
> > int
> > __libc_system (line)
> > const char *line;
> > {
> > if (line == NULL)
> > return 0; /* This indicates no command processor. */
>
> > __sys_errno (ENOSYS);
> > return -1;
> > }
> > weak_alias (__libc_system, system)
>
> > stub_warning (system)
> > #include <stub-tag.h>
>
> > can some one give me hand in understanding this?
> > thanks in advance.
>
> --
> Andreas Jaeger
> SuSE Labs [EMAIL PROTECTED]
> private [EMAIL PROTECTED]
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 08 Jun 2000 14:02:08 +0200
Subject: Re: how system calls implemented in glibc?
>>>>> Junaid Iqbal writes:
> Thanks for ur reply.
> got it. looking in wrong path. from where i can get docs on sysdeps dir
> structure and some detail on its functions
Read the manual (under "Hierarchy Conventions").
> One more problem. i m looking for File System functions like __unlink ,
> __open etc.
> they r defined in 2 places in the tree under sysdeps/mach/hurd/unlink.c
> or in /sysdeps/generic/unlink.c
> generic/unlink.c is same as generic/system.c.
> sysdeps/mach/hurd/unlink.c looks like the main unlink code. but its using
> some functions which i m unable to find.
> like __dir_unlink.
Did you read my reply at all? A last hint: sysdeps/unix/syscalls.list.
Andreas
> Andreas Jaeger wrote:
>> >>>>> Junaid Iqbal writes:
>>
>> > hi all.
>> > I m unable to undersatnd how system calls implemented in glibc (ver
>> > 2.1.3).
>> > for example __libc_system function (defined in system.c) have these
>> > lines
>> That's the fall back in sysdeps/generic/system.c, the function used on
>> Linux is in sysdeps/posix/system.c. Read the documentation about the
>> sysdeps directory and have also a look at syscalls.list.
>>
>> > #include <errno.h>
>> > #include <stdlib.h>
>>
>> > /* Execute LINE as a shell command. */
>> > int
>> > __libc_system (line)
>> > const char *line;
>> > {
>> > if (line == NULL)
>> > return 0; /* This indicates no command processor. */
>>
>> > __sys_errno (ENOSYS);
>> > return -1;
>> > }
>> > weak_alias (__libc_system, system)
>>
>> > stub_warning (system)
>> > #include <stub-tag.h>
>>
>> > can some one give me hand in understanding this?
>> > thanks in advance.
>>
>> --
>> Andreas Jaeger
>> SuSE Labs [EMAIL PROTECTED]
>> private [EMAIL PROTECTED]
- --
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 10 Jun 2000 13:14:28 -0500 (CDT)
Subject: Re: RS6000?
If you read the article carefully, you will see that it says absolutely
zero about running linux on rs/6000's or sp/2's
The article only states that they support linux beowulf clusters running
on intel (netfinity) platforms.
fwiw linux should run on f50's and h50's,
but I don't know if its 'officially supported'.
- -- linas
It's been rumoured that Shourya Sarcar said:
>
> This link should prove useful for settling all doubts ;-)
like none of them? ;-)
>
> http://www.zdnet.com.au/linux/stories/au0003286.html
>
> Regards
> Shourya Sarcar
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: Guido Macchi <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 07, 2000 5:47 AM
> Subject: Re: RS6000?
>
>
> > It's been rumoured that Guido Macchi said:
> > >
> > > Hi.
> > >
> > > Anybody knows if exists a Linux implementation for the IBM RS6000?
> >
> > I think that IBM sells & supports this. Or at least they were planing
> > to a few years ago.
> >
> > --linas
> >
>
------------------------------
From: "Shourya Sarcar" <[EMAIL PROTECTED]>
Date: Sun, 11 Jun 2000 00:16:06 +0530
Subject: Re: RS6000?
The article said :
</quote>
While the company will initially offer support only for Linux superclusters
using IBM Netfinity servers, Gelardi left open the possibility that IBM may
expand the program.
The RS/6000 SP is basically a large-scale server designed to handle massive
parallel workloads across hundreds or thousands of processors. The server
operates using AIX, IBM's version of Unix. But the supercomputing power
comes at a hefty price, with systems often costing millions of dollars.
</quote>
I thought this meant that IBM has currently no support for Linux on RS6000,
but "The server operates using [only] AIX, IBM's version of Unix" (although
it could be supported by others via independent ports) and that the
"possibilty that IBM would expand the program" implied that IBM wa thinking
in terms of including the RS6000 under the Linux umbrage.
The article would probably make more sense if these two para had been
swapped.
I think we had different semantic analysis.
Regards
- ----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Saturday, June 10, 2000 11:44 PM
Subject: Re: RS6000?
>
> If you read the article carefully, you will see that it says absolutely
> zero about running linux on rs/6000's or sp/2's
>
> The article only states that they support linux beowulf clusters running
> on intel (netfinity) platforms.
>
> fwiw linux should run on f50's and h50's,
> but I don't know if its 'officially supported'.
>
> -- linas
>
> It's been rumoured that Shourya Sarcar said:
> >
> > This link should prove useful for settling all doubts ;-)
>
> like none of them? ;-)
>
> >
> > http://www.zdnet.com.au/linux/stories/au0003286.html
> >
> > Regards
> > Shourya Sarcar
> >
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: Guido Macchi <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, June 07, 2000 5:47 AM
> > Subject: Re: RS6000?
> >
> >
> > > It's been rumoured that Guido Macchi said:
> > > >
> > > > Hi.
> > > >
> > > > Anybody knows if exists a Linux implementation for the IBM RS6000?
> > >
> > > I think that IBM sells & supports this. Or at least they were planing
> > > to a few years ago.
> > >
> > > --linas
> > >
> >
>
>
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 10 Jun 2000 23:52:52 -0500 (CDT)
Subject: Re: RS6000?
It's been rumoured that Shourya Sarcar said:
>
> I think we had different semantic analysis.
I think I have the advantage of having worked at IBM, and knowing the
people who do this stuff. Several years ago, I talked to one of the
planners about linux on the mainframe, and the conversation drifted off
to linux/6000. I reiterate, I beleive it works fine on f50/h50's.
The planner was working on getting some of IBM's high-availability
cluster tools ported from netfinity+NT to linux/6000. (actually, the
programmers had already done the port, they hated NT. what he was
working on was getting the business plan together, getting the sales &
marketing materials prepared, pushing the beurocratic infrastructure to
do what it takes to productize.) Of course, its pointless of sell
software that runs on top of linux/6000 if you don't *also* support
linux/6000 itself.
Note that having linux/6000 work is not the same as linux running on an
sp2. Although the hardware is based on the same architecture, there
are enough differences that its not instantly compatible.
Note that having a running copy of linux/6000 is not the same as
offering support for it. Its possible/likely that IBM nuked support for
it beacuse:
1) it cuts into the aix revenue stream
2) "what customer would be crazy enough to buy an rs/6000 and run linux
on it? wouldn't they want to run the much better aix?" these words I
quote, straight out of the plannners mouth.
3) perception that there's no demand for this product
4) perception that it would cost too much to support it
5) it costs millions of dollars to launch a product at IBM. You have to
print hundreds of thousands of sales brochures, translated into
dozens of languages, just to let the immense staff of salespeople
know that linux/6000 exists, and not to look stoopid when a customer
calls. If 10,000 salesmen each spend one hour learning about
linux/6000, you've already wasted in excess of $0.5M in salaries alone.
So, basically, its not worth launching a product unless you think
you'll make millions of dollars in revenue.
- --linas
>
> Regards
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Saturday, June 10, 2000 11:44 PM
> Subject: Re: RS6000?
>
>
> >
> > If you read the article carefully, you will see that it says absolutely
> > zero about running linux on rs/6000's or sp/2's
> >
> > The article only states that they support linux beowulf clusters running
> > on intel (netfinity) platforms.
> >
> > fwiw linux should run on f50's and h50's,
> > but I don't know if its 'officially supported'.
> >
> > -- linas
> >
> > It's been rumoured that Shourya Sarcar said:
> > >
> > > This link should prove useful for settling all doubts ;-)
> >
> > like none of them? ;-)
> >
> > >
> > > http://www.zdnet.com.au/linux/stories/au0003286.html
> > >
> > > Regards
> > > Shourya Sarcar
> > >
> > > ----- Original Message -----
> > > From: <[EMAIL PROTECTED]>
> > > To: Guido Macchi <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, June 07, 2000 5:47 AM
> > > Subject: Re: RS6000?
> > >
> > >
> > > > It's been rumoured that Guido Macchi said:
> > > > >
> > > > > Hi.
> > > > >
> > > > > Anybody knows if exists a Linux implementation for the IBM RS6000?
> > > >
> > > > I think that IBM sells & supports this. Or at least they were planing
> > > > to a few years ago.
> > > >
> > > > --linas
> > > >
> > >
> >
> >
>
------------------------------
From: "Shourya Sarcar" <[EMAIL PROTECTED]>
Date: Sun, 11 Jun 2000 21:22:19 +0530
Subject: Re: RS6000?
Hi Linas!
Thanks for your insight on the issue. I happened to chance upon an IBM
brochure which is abt a few months old an I am quoting some parts thereof.
Hope this should add substance to our discussion.
"IBM is strongly committed to Linux through its establishment of key
alliances and the provision opf the most comprehensive service
offereing-hardware, software and technical support."
Linux users _will_ benefit from IBM's wide range of softare and hardware
solutions including :
blah ....
blah....
A linux version of IBM DB2 Universal database. Plans for Lotus
Domino to support Linux
Delivery of IBM's enterprise File system , AFS, on Linux
More PowerPC based systems-IBM RS/6000 43P Models 150 and 260 , and
RS/6000 F50 - to run on
Linux.
The brochure also talks about AIX palnning to render "Linux application
executon environment" support in 2000.
Linas also wrote:
Its possible/likely that IBM nuked support for
> it beacuse:
> 1) it cuts into the aix revenue stream
> 2) "what customer would be crazy enough to buy an rs/6000 and run linux
> on it? wouldn't they want to run the much better aix?" these words I
> quote, straight out of the plannners mouth.
An additional reason would be the new Monterey OS being launched by IBM, an
UNIX system based on the AIX.
Does IBM sell AIX as a part o the RS/6000 or is it bought additionally,
by default ? wqhat are your opinions regarding the usability and performance
of AIX versus Linux especially vis-a-vis IBM HACMP (High availibilty cluster
multiprocessing ) software programs. Especially since Linux SMP is known not
to scale well beyond 4 processors.
Also, I shall check out www.rs6000.ibm.com and let the list knwo if I
find something interesting.
Warmest regards.
Shourya Sarcar
- ----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, June 11, 2000 10:22 AM
Subject: Re: RS6000?
> It's been rumoured that Shourya Sarcar said:
> >
> > I think we had different semantic analysis.
>
> I think I have the advantage of having worked at IBM, and knowing the
> people who do this stuff. Several years ago, I talked to one of the
> planners about linux on the mainframe, and the conversation drifted off
> to linux/6000. I reiterate, I beleive it works fine on f50/h50's.
> The planner was working on getting some of IBM's high-availability
> cluster tools ported from netfinity+NT to linux/6000. (actually, the
> programmers had already done the port, they hated NT. what he was
> working on was getting the business plan together, getting the sales &
> marketing materials prepared, pushing the beurocratic infrastructure to
> do what it takes to productize.) Of course, its pointless of sell
> software that runs on top of linux/6000 if you don't *also* support
> linux/6000 itself.
>
> Note that having linux/6000 work is not the same as linux running on an
> sp2. Although the hardware is based on the same architecture, there
> are enough differences that its not instantly compatible.
>
> Note that having a running copy of linux/6000 is not the same as
> offering support for it. Its possible/likely that IBM nuked support for
> it beacuse:
> 1) it cuts into the aix revenue stream
> 2) "what customer would be crazy enough to buy an rs/6000 and run linux
> on it? wouldn't they want to run the much better aix?" these words I
> quote, straight out of the plannners mouth.
> 3) perception that there's no demand for this product
> 4) perception that it would cost too much to support it
> 5) it costs millions of dollars to launch a product at IBM. You have to
> print hundreds of thousands of sales brochures, translated into
> dozens of languages, just to let the immense staff of salespeople
> know that linux/6000 exists, and not to look stoopid when a customer
> calls. If 10,000 salesmen each spend one hour learning about
> linux/6000, you've already wasted in excess of $0.5M in salaries alone.
> So, basically, its not worth launching a product unless you think
> you'll make millions of dollars in revenue.
>
> --linas
>
> >
> > Regards
> >
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > Sent: Saturday, June 10, 2000 11:44 PM
> > Subject: Re: RS6000?
> >
> >
> > >
> > > If you read the article carefully, you will see that it says
absolutely
> > > zero about running linux on rs/6000's or sp/2's
> > >
> > > The article only states that they support linux beowulf clusters
running
> > > on intel (netfinity) platforms.
> > >
> > > fwiw linux should run on f50's and h50's,
> > > but I don't know if its 'officially supported'.
> > >
> > > -- linas
> > >
> > > It's been rumoured that Shourya Sarcar said:
> > > >
> > > > This link should prove useful for settling all doubts ;-)
> > >
> > > like none of them? ;-)
> > >
> > > >
> > > > http://www.zdnet.com.au/linux/stories/au0003286.html
> > > >
> > > > Regards
> > > > Shourya Sarcar
> > > >
> > > > ----- Original Message -----
> > > > From: <[EMAIL PROTECTED]>
> > > > To: Guido Macchi <[EMAIL PROTECTED]>
> > > > Cc: <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, June 07, 2000 5:47 AM
> > > > Subject: Re: RS6000?
> > > >
> > > >
> > > > > It's been rumoured that Guido Macchi said:
> > > > > >
> > > > > > Hi.
> > > > > >
> > > > > > Anybody knows if exists a Linux implementation for the IBM
RS6000?
> > > > >
> > > > > I think that IBM sells & supports this. Or at least they were
planing
> > > > > to a few years ago.
> > > > >
> > > > > --linas
> > > > >
> > > >
> > >
> > >
> >
>
>
------------------------------
From: Jeff Parker <[EMAIL PROTECTED]>
Date: Thu, 15 Jun 2000 12:14:05 -0400
Subject: Shared libraries
I'm new to creating and using shared libraries in LINUX. When I use
static libraries while building an application, everything works fine
but going to shared libaries , I get many 'undefined references' to
calls in other libraries that my program never needs. Is there a switch
for gcc that stops trying to resolve the dependencies when they aren't
needed?
If any one has some example makefiles for shared libaries and/or
applications using shared libraries, I'd appreciate a look.
Thanks,
Jeff Parker
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 02:22:32 EDT
Subject: Re: Shared libraries
What shared libraries are you having trouble with?
The troubles most people have with ld are usually because they don't
understand that unless directed otherwise it is a ONE PASS linker.
if you mention a library to it that defines a symbol, but you haven't
mentioned a library or object file that needs that symbol, it forgets
it, so if you then mention a library or object file that needs it, it is
undefined. Either order your references to occur before your
definitions (in the ld command line (gcc will generate one from the gcc
command line)), or group libraries with the -( option. Also known as
- --start-group. info ld is pretty good on this. I am afraid I have a
hard time finding it in man ld, but I think I've seen it there too.
Oh, you may mention the same library more than once in the ld command
line. Sometimes that is easier.
If you want something really simple that uses shared libraries, you
could look at
ftp://metalab.unc.edu/pub/Linux/utils/console/lockvc-3.6.tgz
or even simpler,
ftp://metalab.unc.edu/pub/Linux/utils/text/safe-1.3.8.tar.bz2
or
ftp://nwonknu.org/pub/junopine-1.5.6.tar.gz
Those are all from memory, but should be close enough to find.
If you want something hairy that uses shared libraries, look at
ftp://metalab.unc.edu/pub/Linux/ALPHA/wine/development/Wine-20000614.tar.gz
ftp://tsx-11.mit.edu/pub/linux/ALPHA/Wine/development/Wine-20000614.tar.gz
ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wine-20000614.tar.gz
ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/Wine-20000614.tar.gz
On Thu, 15 Jun 2000, Jeff Parker wrote:
> I'm new to creating and using shared libraries in LINUX. When I use
> static libraries while building an application, everything works fine
> but going to shared libaries , I get many 'undefined references' to
> calls in other libraries that my program never needs. Is there a
switch
> for gcc that stops trying to resolve the dependencies when they aren't
> needed?
>
Oh, a switch. You can tell ld, -noinhibit-exec. On the gcc command
line, that would be spelled -Wl,-noinhibit-exec
> If any one has some example makefiles for shared libaries and/or
> applications using shared libraries, I'd appreciate a look.
>
> Thanks,
>
> Jeff Parker
>
>
Lawson
For the man who rises early is a man whose life is lost.
He will never know what he has missed till he's counted up the cost.
It's too late to put eggs in the nest when the bird's already flown.
If you're known as an early riser you can sleep till the cows com home.
- Robbie O'Connell
- -------------------------
________________________________________________________________
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: "Shourya Sarcar" <[EMAIL PROTECTED]>
Date: Sun, 18 Jun 2000 23:15:21 +0530
Subject: Re: RS6000?
Finally , Linux on RS6000 :-)
Tnx suse
http://www.rs6000.ibm.com/resource/pressreleases/2000/Jun/suse.html
Shourya
------------------------------
From: Guido Macchi <[EMAIL PROTECTED]>
Date: Mon, 19 Jun 2000 22:41:25 -0300 (ART)
Subject: Re: RS6000?
Hi, Shourya.
On Sun, 18 Jun 2000, Shourya Sarcar wrote:
> Finally , Linux on RS6000 :-)
Yessssss!!
> Tnx suse
>
> http://www.rs6000.ibm.com/resource/pressreleases/2000/Jun/suse.html
>
> Shourya
>
Thanks a lot!
guido
........................................................................
"One of the symptoms of an approaching nervous breakdown is the belief
that one's work is terribly important."
- Bertrand Russell (1872-1970)
"If you assume that there's no hope, you guarantee that there will be no
hope. If you assume that there is an instinct for freedom, there are
opportunities to change things, there's a chance you may contribute to
making a better world. That's your choice"
- Noam Chomsky
........................................................................
------------------------------
From: "Madhav" <[EMAIL PROTECTED]>
Date: Tue, 20 Jun 2000 15:05:45 +0530
Subject: problem with math.h
Hi all,
I have a problem compiling this simple program in gcc under my RH linux
6.1. I am giving it here.
#include <math.h>
#include <stdio.h>
main()
{
double i,n;
n=0;
for (i=0;i<100;i++)
n += sqrt (i);
printf("the sum of square roots of first 100 natural numbers=%f",n);
}
is giving an error "undefined reference to 'sqrt' ". Can anybody tell me
what the problem may be?
thanks in advance,
Madhav
------------------------------
From: "Gabor Z. Papp" <[EMAIL PROTECTED]>
Date: Tue, 20 Jun 2000 11:19:20 GMT
Subject: problem with math.h
* Madhav <[EMAIL PROTECTED]>:
| is giving an error "undefined reference to 'sqrt' ". Can anybody tell me
| what the problem may be?
Compile with -lm
------------------------------
From: Karthik Vishwanath <[EMAIL PROTECTED]>
Date: Tue, 20 Jun 2000 10:09:47 -0400 (EDT)
Subject: Re: problem with math.h
Try gcc -lm <program.c>.
- -Karthik.
On Tue, 20 Jun 2000, at 3:05pm, Madhav wrote:
> Hi all,
> I have a problem compiling this simple program in gcc under my RH linux
> 6.1. I am giving it here.
>
> #include <math.h>
> #include <stdio.h>
> main()
> {
> double i,n;
> n=0;
> for (i=0;i<100;i++)
> n += sqrt (i);
> printf("the sum of square roots of first 100 natural numbers=%f",n);
> }
>
> is giving an error "undefined reference to 'sqrt' ". Can anybody tell me
> what the problem may be?
>
> thanks in advance,
> Madhav
>
>
>
------------------------------
From: Andre Majorel <[EMAIL PROTECTED]>
Date: Wed, 21 Jun 2000 00:32:38
Subject: Re: problem with math.h
At 15:05 2000.06.20 +0530, Madhav wrote:
>#include <math.h>
[snipped C code]
>is giving an error "undefined reference to 'sqrt' ". Can anybody tell me
>what the problem may be?
Basically, if you need to #include <math.h>, also use "-lm"
when linking. This is true for unices in general (and perhaps
other systems), not only for GCC on Linux.
Do something like
cc -c -Wall -O foo.c
cc foo.o -lm -o foo
or, in one step,
cc -Wall -O foo.c -lm -o foo
The C FAQ is your friend
(http://www.eskimo.com/~scs/C-faq/top.html).
Andr� Majorel <[EMAIL PROTECTED]>
http://www.teaser.fr/~amajorel/
------------------------------
From: "H . J . Lu" <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 23:30:19 -0700
Subject: binutils 2.10.0.9 is released.
This is the beta release of binutils 2.10.0.9 for Linux, which is
based on binutils 2000 0617 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.9 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.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.9.tar.gz. Source code.
2. binutils-2.9.5.0.46-2.10.0.9.diff.gz. Patch against the previous
beta source code.
3. binutils-2.10.0.9-1.i386.rpm. IA-32 binary RPM for RedHat 6.2.
4. binutils-2.10.0.9-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.9.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]
06/23/2000
------------------------------
From: Graham Murray <[EMAIL PROTECTED]>
Date: 23 Jun 2000 17:29:49 +0000
Subject: Re: binutils 2.10.0.9 is released.
"H . J . Lu" <[EMAIL PROTECTED]> writes:
> This is the beta release of binutils 2.10.0.9 for Linux, which is
> based on binutils 2000 0617 in CVS on sourecware.cygnus.com plus
> various changes.
How does this compare with the 'released' binutils 2.10 on
ftp.gnu.org?
------------------------------
From: "13mb80000-HallM(10053584)37x10" <[EMAIL PROTECTED]>
Date: Fri, 23 Jun 2000 14:24:19 -0600 (MDT)
Subject: Re-directing a BSS symbol to another segment
I would like to place a symbol into another segment and am running into
great difficulty. The symbol is uninitialized (and therefore COMMON).
Suppose that there is a symbol thus:
int X[1000];
This normally gets marked as a COMMON symbol and the loader eventually
puts it into .bss at final link time. If I change the code to look like:
int X[1000] __attributes__((segment(".mybss")));
This has no effect, since the symbol is COMMON and not attached to a segment
yet (or so I presume). Now, if I add the "nocommon" attribute like this:
int X[1000] __attributes__((nocommon,segment(".mybss")));
I do get the symbol "X" palced into the .mybss segment, but it is
now an initialized variable. The problem with this is that it makes
the object file quite large for some of the data I need to be using.
If I take the original file, then do a relocatable link with the script:
SECTIONS { .mybss : { *(.bss) } }
I actually do get the symbol put into .mybss. I'm not quite sure how this
works, but the problem is that I can only move the entire bss segment this
way, and it takes extra post-processing after the compile. I guess I could
live with that if I really had to, but I'm searching for a better way right
now...
If I look at the object file header produced for the 3rd case (with the
initialized data) I see that .mybss is being created with the CONTENTS,
ALLOC, LOAD, and DATA flags set, which seems appropriate for initialized
data, and in the last case only the ALLOC flag is set. So, perhaps another
way of saying this is that I would like to put my data into a segment
with only the ALLOC flag set, or change the flags on a segment somehow.
Does anybody have any suggestions on the best way to accomplish this?
marcus hall
marcus
------------------------------
From: Harald Milz <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 00:02:36 +0200 (CEST)
Subject: Re: RS6000?
Shourya Sarcar <[EMAIL PROTECTED]> wrote:
> Finally , Linux on RS6000 :-)
Oh man, it ran DB2 on an F50 in Feb 98. (no typo)
But there's just 3 supported machines: B50, 43P-150 and F50, not the old
MCA stuff. Linux on a 520, eh? Very 'umble, very 'eavy.
- --
This fortune intentionally not included.
------------------------------
From: Scott Long <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 09:21:40 -0700
Subject: Position independent code
As we all know, shared objects want to be compiled with -fPIC.
But shouldn't this be the linking loader's job? Why is there no fixup
section for jumps?
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).
So there are two possible states the universe can be in at this point:
1) I'm right about the limitations of relative jumps on Intel, in which
case I wonder why this is something for the compiler to do as opposed to
the linking loader.
2) I'm totally wrong about the limitations of relative jumps on Intel,
in which case this message qualifies as noise.
If the latter case is true, please accept my apologies.
Regards,
Scott
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 22:50:42 +0200
Subject: Re: Position independent code
> As we all know, shared objects want to be compiled with -fPIC.
No, shared objects are lifeless - users want to compile shared objects
with -fPIC :-)
> But shouldn't this be the linking loader's job? Why is there no fixup
> section for jumps?
Sure there is. At least on Linux, compiling shared libraries with
- -fPIC is not an absolute requirement. If you don't, it will still work
- - only it will require relocations on run-time. These result, due to
copy-on-write, that the shared pages are not shared anymore. Since
there is likely at least one relocation per page, you essentially have
to copy the entire library to swap on start-up.
> 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.
> 1) I'm right about the limitations of relative jumps on Intel
No, see above.
> 2) I'm totally wrong about the limitations of relative jumps on Intel,
> in which case this message qualifies as noise.
The problem is that the static linker can't know the final location of
a function in a shared library, so you still pay the overhead of going
through the PLT. In addition, there are no PC-relative read and write
operations - which is the real overhead of -fPIC on ia32
Regards,
Martin
------------------------------
From: [EMAIL PROTECTED]
Date: Thu, 29 Jun 2000 14:34:01 EDT
Subject: Re: Position independent code
On Thu, 29 Jun 2000, Scott Long wrote:
> As we all know, shared objects want to be compiled with -fPIC.
>
> But shouldn't this be the linking loader's job? Why is there no fixup
> section for jumps?
>
> 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).
16 bits, I think.
>
> So there are two possible states the universe can be in at this point:
>
> 1) I'm right about the limitations of relative jumps on Intel, in which
> case I wonder why this is something for the compiler to do as opposed
to
> the linking loader.
>
> 2) I'm totally wrong about the limitations of relative jumps on Intel,
> in which case this message qualifies as noise.
>
> If the latter case is true, please accept my apologies.
>
> Regards,
> Scott
>
The intel only jumps relatively. It has no way to address data relative
to the IP. I think that is what PIC is all about. At least that is
what the code gcc generates when told to -fPIC looks like it is trying
to do.
Lawson
- ---cut here
________________________________________________________________
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: Fri, 30 Jun 2000 09:04:14 -0500 (EST)
Subject: Re: Position independent code
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.
(In protected mode CS indexes the descriptor table, and the segment base
is found there, but the effect is similar for the purpose of this
discussion.)
I'll let the philosophers argue whether or not a jump relative to a
segment with base of zero is absolute.
- --
Mark H. Wood, Lead System Programmer [EMAIL PROTECTED]
Life was so much simpler on the PDP-10.
------------------------------
From: Scott Long <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2000 09:45:25 -0700
Subject: More Position Independent Code
Thanks to all those who replied to my original question. I'll restate
what I've learned, let's see if I'm correct:
The purpose of PIC is really to allow position-independent data access,
not for jump fixes. In order to prove this to myself I wrote the
following piece:
- --- BEGIN pic.c
unsigned int array[256];
int init_array()
{
int i;
for(i = 0; i < 256; i++)
array[i] = 0xDEADBEEF;
}
- --- END pic.c
scott@abacus:~$ gcc -O -fPIC -S -o pic.s pic.c
The relevant portion of pic.s:
...
pushl %ebx
call .L8
.L8:
popl %ebx
addl $_GLOBAL_OFFSET_TABLE_+[.-.L8],%ebx
...
Indeed what I'm seeing are not jump fixes but data access fixes. I'm not
100% familiar with the GNU assembler so I'm not sure exactly what this
_GLOBAL_OFFSET_TABLE is referring to, but it is clear from this snippet
that Intel cannot address data relative to EIP and therefore must load
the PC into a general purpose register.
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? It seems like
all shared libraries and shared objects on Intel take a serious penalty
every time they access non-auto storage.
So now I have a question pertinent to this list's raison d'etre:
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? Imagine the following, compiled with -fPIC:
- --- BEGIN pic2.c
int expensive_var;
void crunch_numbers()
{
while(some_condition_that_is_true_for_many_iterations)
{
expensive_var =
some_inline_function_that_exhausts_the_registers(expensive_var);
}
}
- --- END pic2.c
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?
Regards and thanks,
Scott
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 30 Jun 2000 14:14:52 EDT
Subject: Re: More Position Independent Code
On Fri, 30 Jun 2000, Scott Long wrote:
> Thanks to all those who replied to my original question. I'll restate
> what I've learned, let's see if I'm correct:
>
> The purpose of PIC is really to allow position-independent data access,
> not for jump fixes. In order to prove this to myself I wrote the
> following piece:
>
> --- BEGIN pic.c
>
> unsigned int array[256];
>
> int init_array()
> {
> int i;
>
> for(i = 0; i < 256; i++)
> array[i] = 0xDEADBEEF;
> }
>
> --- END pic.c
>
> scott@abacus:~$ gcc -O -fPIC -S -o pic.s pic.c
>
> The relevant portion of pic.s:
>
> ...
>
> pushl %ebx
> call .L8
> .L8:
> popl %ebx
> addl $_GLOBAL_OFFSET_TABLE_+[.-.L8],%ebx
>
> ...
>
> Indeed what I'm seeing are not jump fixes but data access fixes. I'm
not
> 100% familiar with the GNU assembler so I'm not sure exactly what this
> _GLOBAL_OFFSET_TABLE is referring to, but it is clear from this snippet
> that Intel cannot address data relative to EIP and therefore must load
> the PC into a general purpose register.
>
> 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? It seems like
> all shared libraries and shared objects on Intel take a serious penalty
> every time they access non-auto storage.
You pay the penalty not for each access, but for each entry to a
function that makes such access. The function is responsible to not
disturb ebx as set by the caller, if you look past what you consider
relevant you will see it restores ebx on exit. Not only does it take 2
memory accesses, it wastes a register to hold the address of the
GOT. But it doesn't do the call/pop every time you reference a
variable.
gcc is fairly clever. maybe even clever than I am.
>
> So now I have a question pertinent to this list's raison d'etre:
>
> 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? Imagine the following, compiled with -fPIC:
>
- ---pseudocode snipped
> Regards and thanks,
> Scott
>
Lawson
- ---cut here
________________________________________________________________
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: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 01 Jul 2000 01:02:13 -0700
Subject: glibc 2.1.91 (first test release for 2.2)
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.
This is a first test release and not much testing in complete systems
and for compatibility has been done so far (this is why we are doing
public release). This release is mainly meant to show the new
technologies and get early testers. Don't install this version on any
production machine, best install it in a chroot environment or perform
tests without actually installing it.
This version is very near to feature-completeness for the 2.2 release.
There are only a few things which will change:
* the RPM code is completely f*cked up. We are completely in limbo
between the old code, a version with IPv6 support, and Sun's code.
None of the developers actually has much experience with this code
and so not much was done.
I actually intended to remove the IPv6 changes before the release
(since they are binary incompatible with the 2.1 release) but left
it in since I don't want anybody to install this libc anyway and in
the hope that somebody has mercy with the RPC code and volunteers to
work on it. If there is such a kind soul out there, please get in
contact with me.
* the Linux/IA-64 code is not yet complete
* I do not know about the status of the two Linux ports which are not
yet in glibc: HP/PA and S390. Maybe they get in, maybe not.
Now a word about the changes:
* the db and db2 code is gone. Since yet another interface change would
have been necessary (the upstream maintainer did it, not me) I decided
to drop it from glibc. The only reason the code was there in the fist
place was the NSS code and we now worked around the problem of not
having the code in glibc. The nss_db module us still built.
* the utmpd daemon is also gone. It was only necessary for the transition
from glibc 2.0 to 2.1
* new Linux ports: SPARC64, SH, IA-64. The MIPS port now also works.
* completely rewritten locale code. This is one of the biggest
improvements but includes also the greatest risk of breakage. The
changes include:
+ full multibyte character set support. This includes Asian character
sets but (especially) also UTF-8
+ wide character stream functions. All functions from ISO C99 are
now implemented
+ next generation locale specification support, including new categories,
and working without repertoire maps
+ much more standard compliant through testing and more careful studying
of standards
+ better message translation support with handling of plural forms and
automatic transformation of message to the current character set
* dozens (hundreds?) of new functions, mostly from new POSIX standards you
probably have not even heard of. This includes:
+ POSIX spawn functions
+ POSIX spinlocks
+ POSIX barriers
+ POSIX timer & clocks
+ POSIX shared memory
+ POSIX timed wait functions for various synchronization objects
+ extended socket API functions
* the resolver of the NSS DNS module is now allows access from multiple
threads at the same time.
* major improvements in the thread library
+ fewer bugs
+ better performance (esp on x86)
+ new functions which help programs heavily using synchronization
objects
Beside this we have the usual bug fixes (mainly for better compliance
with standards and compatibility with other systems) and cleanups.
What has not yet happened, we will start with this soon, is profiling
and memory leak testing.
HOW CAN YOU HELP?
The most important question (for me).
* simply compile and run the test suite. But be aware, it's not a small
package:
sources: 88MB
compile objects: 320MB (on IA-32, with static, shared, profile)
Add to this the size for the installed files. Compilation takes on
a high-end dual CPU IA-32 machine about 40 min. Don't try this on
your i386 or Atari ST, kids. You might not be able to use the
machine for a week or so.
* volunteer to help on some of the open issues. Take a look at
http://www.cygnus.com/~drepper/TODO.html
I'm updating the list when something is done or something new comes
up. So please revisit the page.
* Test:
+ write own programs, recompile old programs. I'm especially interested
in programs using the new locale stuff. Use it and write tons of
UTF-8 enabled programs. Also programs patched for Asian users should
be tested. No hacked-up glibc version is necessary anymore.
+ write new tests. Tests are appreciated for all parts of the code, but
especially again for the locale code. Since a lot of the libc is
influenced by the locale setting a lot has to be tested.
You don't even have to be able to write C programs. One part of the
locale test suite consists of programs which are driven by tables.
Simply adding new entries to the tables adds more tests.
+ compatibility testing. Run programs compiled with old versions using
the new libc. Note that you cannot simply use only the new libc.so,
you at least have to use the new ld.so as well.
How soon we can make the final 2.2 release depends on the help and
feedback we get. If nobody gives any feedback this is as bad as if
nobody would do any tests at all. Even if everything works
(especially then) also let us know. All feedback related to this
release should be sent to
[EMAIL PROTECTED]
This mailing list is open for everybody.
- --
- ---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
------------------------------
End of linux-gcc-digest V1 #407
*******************************
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".
