linux-gcc-digest Monday, 8 February 1999 Volume 01 : Number 361
In this issue:
[none]
Q: symbol hiding and controlling dynamic linkage
Where is g++-2.7.2.8?
Re: glibc 2.0.112
Re: Bug with dlclose and static class elements
Re: Bug with dlclose and static class elements
Re: Bug with dlclose and static class elements
Re: Bug with dlclose and static class elements
Re: Bug with dlclose and static class elements
Bug in reboot() for Alpha
Re: Bug in reboot() for Alpha
Where did libg++ go?
gdb 4.17.0.10 is released.
porting to a new architecture
Re: C++ Destructor Question
Re: C++ Destructor Question
Re: porting to a new architecture
Re: Bug with dlclose and static class elements
Re: porting to a new architecture
binutils 2.9.1.0.20 is released.
FTP site for crypt code
Problem w/ dynamic linking
glibc 2.1
Question about new software
function return values
FTP site for crypt code
Re: Question about new software
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 30 Jan 1999 14:31:06 -0500
Subject: [none]
I am linking a number of executables against a shared library that I've built,
and some the executables contain code that collides with symbols defined in the
shared library for both function names and some static data in the shared obj.
I have a few questions about how to control the linkage here.
Initially I was having all kinds of namespace collisions between . By using a
version script like
youch.so.0.0 {
global:
entry1;
entry2;
entry3;
entry4;
local:
*;
};
I was able to avoid the function cross-linkage (I think). However, it appears
that I am still having cross-linkage problems with some static data in my shared
object, where the code from the executable seems to be accessing static data
that should be for the shared object (or vice versa). Stripping the shared
object before linking against it doesn't seem to help.
Questions:
- Is linking the shared object specifing the --version-script the proper
way to hide the symbols that I don't want to export? That's what the ld info
seemed to be saying, but it was a bit confusing.
- Should the version script above hide my data as well as the functions,
i.e., is this apparent cross-linkage on static data the expected behavior in
this case?
- Is there a way to make the link happen the way I want it, i.e. references
to global data in the code in the shared object and in the objects statically
linked into the executable are resolved to the symbols in their respective data
segments?
Any help with these questions would be appeciated, as would any pointers to
further documentation.
Thanks
Matt La Mantia
$ cat /proc/version
Linux version 2.0.34 ([EMAIL PROTECTED]) (gcc version 2.7.2.3) #1 Fri May 8
16:05:57 EDT 1998
$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/specs
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
------------------------------
From: [EMAIL PROTECTED]
Date: Sat, 30 Jan 1999 14:34:19 -0500
Subject: Q: symbol hiding and controlling dynamic linkage
I am linking a number of executables against a shared library that I've
built, and some the executables contain code that collides with symbols
defined in the shared library for both function names and some static data
in the shared obj. I have a few questions about how to control the linkage
here.
Initially I was having all kinds of namespace collisions between . By
using a version script like
youch.so.0.0 {
global:
entry1;
entry2;
entry3;
entry4;
local:
*;
};
I was able to avoid the function cross-linkage (I think). However, it
appears that I am still having cross-linkage problems with some static
data in my shared object, where the code from the executable seems to be
accessing static data that should be for the shared object (or vice
versa). Stripping the shared object before linking against it doesn't seem
to help.
Questions:
- Is linking the shared object specifing the --version-script the
proper way to hide the symbols that I don't want to export? That's what
the ld info seemed to be saying, but it was a bit confusing.
- Should the version script above hide my data as well as the
functions, i.e., is this apparent cross-linkage on static data the
expected behavior in this case?
- Is there a way to make the link happen the way I want it, i.e.
references to global data in the code in the shared object and in the
objects statically linked into the executable are resolved to the symbols
in their respective data segments?
Any help with these questions would be appeciated, as would any pointers to
further documentation.
Thanks
Matt La Mantia
$ cat /proc/version
Linux version 2.0.34 ([EMAIL PROTECTED]) (gcc version 2.7.2.3) #1 Fri May 8
16:05:57 EDT 1998
$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/specs
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
------------------------------
From: Oliver Mai <[EMAIL PROTECTED]>
Date: Sat, 30 Jan 1999 20:37:01 +0100
Subject: Where is g++-2.7.2.8?
I am searching for the C++ library I which is compatible with
my standard C library libc.so.5.4.46. I read that I should use
libg++-2.7.2.8, but I cannot find that anywhere.
Where is it (preferrably a binary distribution for i686-linux-glibc1)?
Please email me directly, because I don't read this list regularly.
Thanks a lot in advance.
Oliver Mai
mailto:[EMAIL PROTECTED]
------------------------------
From: Richard Henderson <[EMAIL PROTECTED]>
Date: Sat, 30 Jan 1999 12:50:04 -0800
Subject: Re: glibc 2.0.112
On Sat, Jan 30, 1999 at 08:04:31AM -0800, Ulrich Drepper wrote:
> > It is not a bug in glibc.
>
> The same is true for Alpha. Though I think rth said he fixed the
> problems recently.
Yes, the Alpha problems with single precision complex are
a compiler problem. The solution I had appears to be only
and still crashes the compiler on occasion.
r~
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Date: 01 Feb 1999 10:56:50 +0100
Subject: Re: Bug with dlclose and static class elements
Harald Hoyer <[EMAIL PROTECTED]> writes:
|> Hi,
|>
|> the attached tarball demonstrates the failure of deleting static elements in
|> classes, if the library that contains these class is unloaded with dlclose.
|>
|> My question is whether this is a glibc (libdl) bug or a bug in generating the
|> code (egcs).
IMHO this is a bug in gcc. It should not use atexit to register the dtor
for static local objects. Instead it should set up an entry in the .dtors
section. There is no (standard) way to unregister an atexit function, and
implementing it would require to put a hook into libc for use by the
dynamic linker.
[For the readers of the egcs list: the full report is available under
http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/938]
- --
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mike Stump)
Date: Mon, 1 Feb 1999 13:52:22 -0800
Subject: Re: Bug with dlclose and static class elements
> From: Andreas Schwab <[EMAIL PROTECTED]>
> Date: 01 Feb 1999 10:56:50 +0100
> IMHO this is a bug in gcc. It should not use atexit to register the
> dtor for static local objects. Instead it should set up an entry in
> the .dtors section. There is no (standard) way to unregister an
> atexit function, and implementing it would require to put a hook
> into libc for use by the dynamic linker.
I've said it before, I'll say it again, anything less than the right
fix is a waste of time in my humble opinion, and the right fix is I
claim obvious and singular. We have talked about it before.
If someone wants to implement this, I'd be happy to explain again or
critique a proposal.
------------------------------
From: [EMAIL PROTECTED] (Mike Stump)
Date: Mon, 1 Feb 1999 13:52:22 -0800
Subject: Re: Bug with dlclose and static class elements
> From: Andreas Schwab <[EMAIL PROTECTED]>
> Date: 01 Feb 1999 10:56:50 +0100
> IMHO this is a bug in gcc. It should not use atexit to register the
> dtor for static local objects. Instead it should set up an entry in
> the .dtors section. There is no (standard) way to unregister an
> atexit function, and implementing it would require to put a hook
> into libc for use by the dynamic linker.
I've said it before, I'll say it again, anything less than the right
fix is a waste of time in my humble opinion, and the right fix is I
claim obvious and singular. We have talked about it before.
If someone wants to implement this, I'd be happy to explain again or
critique a proposal.
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Tue, 2 Feb 1999 00:22:51 +0100
Subject: Re: Bug with dlclose and static class elements
> If someone wants to implement this, I'd be happy to explain again or
> critique a proposal.
So I have a patch
(http://www.cygnus.com/ml/egcs-patches/1998-Sep/0371.html)
Explain and critique, please.
Martin
------------------------------
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
Date: Tue, 2 Feb 1999 00:22:51 +0100
Subject: Re: Bug with dlclose and static class elements
> If someone wants to implement this, I'd be happy to explain again or
> critique a proposal.
So I have a patch
(http://www.cygnus.com/ml/egcs-patches/1998-Sep/0371.html)
Explain and critique, please.
Martin
------------------------------
From: Bruce Elliott <[EMAIL PROTECTED]>
Date: Tue, 2 Feb 1999 01:15:40 -0800
Subject: Bug in reboot() for Alpha
The "reboot" function fails on Linux/Alpha. The problem is due to type
promotion rules. The constant 0xfee1dead exceeds the range for (int), and
is promoted to (unsigned int). The INLINE_SYSCALL passes (long), so the
value is zero-extended to 64 bits and passed in a register. The kernel
code specifies (int), and expects sign-extension to 64 bits. The magic
match fails. The following corrects this for me. (I think that the large
constants for the "howto" parameter are handled by the prototype, although
I haven't checked for this.)
============================================================================
- --- glibc-2.0.112/sysdeps/unix/sysv/linux/reboot.c.orig Tue Oct 20 11:10:57
1998
+++ glibc-2.0.112/sysdeps/unix/sysv/linux/reboot.c Sat Jan 30 19:00:50 1999
@@ -28,5 +28,5 @@
int
reboot (int howto)
{
- - return INLINE_SYSCALL (reboot, 3, 0xfee1dead, 672274793, howto);
+ return INLINE_SYSCALL (reboot, 3, (int)0xfee1dead, 672274793, howto);
}
============================================================================
- --
B. D. Elliott [EMAIL PROTECTED] (Seattle)
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 02 Feb 1999 09:07:34 -0800
Subject: Re: Bug in reboot() for Alpha
Bruce Elliott <[EMAIL PROTECTED]> writes:
> The "reboot" function fails on Linux/Alpha. The problem is due to type
> promotion rules. The constant 0xfee1dead exceeds the range for (int), and
> is promoted to (unsigned int).
Makes sense to me. Thanks,
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: "Mark H. Wood" <[EMAIL PROTECTED]>
Date: Wed, 3 Feb 1999 12:09:12 -0500 (EST)
Subject: Where did libg++ go?
Where should I be looking for a libg++ 2.7.2.x that builds on Linux?
I just heard about HP's WebJetAdmin release for Linux, and as we have
dozens of HP printers here I'd really like to administer them from my
office. Unfortunately the install bombs with complaints that turned out
to be about missing libraries. For some reason my libg++.so insists that
it is version 27.2.1, and the loader and its buddies are determined not to
see any links or outright copies I might make calling it libg++.so.2.7.2.
Of course HP only supplied binaries. So I need to build a new libg++ with
the right version number. The stock 2.7.2 kit from FSF doesn't build a
shareable library at all so that didn't help.
You're going to ask what distribution I'm running. The answer is
Slackware 1.2 (yes, one dot two) but just about everything has been
replaced so you could call it StupidMarkWare 0.1 if you wanted to. :-)
Thanks!
- --
Mark H. Wood, Lead System Programmer [EMAIL PROTECTED]
Innovation is only valuable if it improves one's life; otherwise it's
just one more silly change to cope with.
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Wed, 3 Feb 1999 16:49:29 -0800 (PST)
Subject: gdb 4.17.0.10 is released.
Hi,
gdb 4.17.0.10 seems to work pretty well with threads in glibc 2.1 on
x86 now.
- --
H.J. Lu ([EMAIL PROTECTED])
- --
Hi, Folks,
This is the beta release of gdb 4.17.0.10, which is based on gdb 4.17
plus Linux/x86 hardware watchpoint/FPU, glibc 2 pthread and Linux/PPC
support. You need linux 2.0.35 or above, or 2.1.xx to get the x86 FPU
to work correctly. The Linux/x86 binary works with all recent kernels
and C libraries, and the x86 FPU support is enabled at the run-time,
depending on the kernel version.
Please report any bugs related to gdb 4.17.0.10 to [EMAIL PROTECTED]
Problems:
Because most of system calls in glibc 2 are written in assembly without
frame pointer, gdb may not be able to debug nor get stack trace system
calls on glibc-based 2 systems. Due to this, "make check" may fail in
FAIL: gdb.base/a1-selftest.exp: backtrace through signal handler
FAIL: gdb.base/signals.exp: bt in signals.exp
with glibc 2.
Also, it is normal to see
FAIL: gdb.base/interrupt.exp: continue (timeout)
FAIL: gdb.base/interrupt.exp: echo data (timeout)
if there is
XPASS: gdb.base/interrupt.exp: send_gdb end of file
Due to the new cplus-dem.c from egcs 1.1.1, you will get a few
FAIL: gdb.c++/demangle.exp: maint demangle __xxxxxxxxxx
Changes from gdb 4.17.0.9:
1. Fix support for glibc 2.1 pthread. Need the latest glibc 2.1, newer
than 16:30pm PST of 19990-02-03.
2. Fix deleting the hardware watchpoint on x86.
Changes from gdb 4.17.0.8:
1. The new cplus-dem.c from egcs 1999-01-12 with a bug fix.
2. Add support for deleting the hardware watchpoint on x86.
3. Update support for glibc 2.1 pthread.
4. Fix C++ testsuite.
Changes from gdb 4.17.0.6:
1. Support for glibc 2.1 pthread. But it doesn't work, probably due
to the CLONE_PTRACE change to pthread in glibc 2.1.
2. Add support for the older Linux C libraries.
3. Add -static support for glibc 2.1.
Changes from gdb 4.17.0.5:
1. Support for glibc 2.0 pthread. It doesn't work with glibc 2.1.
2. The Linux/PPC support.
3. The Linux/Sparc support. Untested.
Changes from gdb 4.17.0.4:
1. Fix the Intel FPU tag code handling.
Changes from gdb 4.17.0.3:
1. Fix testcases for FPU.
2. Fix x86 hardware watchpoint support.
Changes from gdb 4.17.0.2:
1. Fake FP registers on older kernels.
Changes from gdb 4.17:
1. Linux/x86 FPU support is added. You can debug floating point numbers
just like integers.
2. x86 hardware watchpoint is extended to long long, double and long
double.
3. More information on x86 CPU status register.
4. Fix a bug when reading beyond the memory boundary.
The file list:
1. gdb-4.17-4.17.0.10.diff.gz. Patch against gdb 4.17.
2. gdb-4.17.0.9-4.17.0.10.diff.gz. Patch against gdb 4.17.0.9.
3. gdb-4.17.0.10.x86.gz. Precompiled Linux/x86 statically linked binary.
4. gdb-4.17.0.10.spec. A RPM spec file for RedHat 5.2.
The ftp sites for my gdb patches:
ftp://ftp.yggdrasil.com/private/hjl
ftp://ftp.kernel.org/pub/linux/devel/gcc
gdb 4.17 source code is available at
ftp://ftp.gnu.org/pub/gnu
To install the precompiled binary,
# gunzip gdb-4.17.0.10.x86.gz
# cp gdb-4.17.0.10.x86 /usr/bin/gdb
H.J.
[EMAIL PROTECTED]
02/03/1999
------------------------------
From: Linas Vepstas <[EMAIL PROTECTED]>
Date: Thu, 4 Feb 1999 00:09:43 -0600
Subject: porting to a new architecture
I've been working on a port of gcc/binutils/glibc to a new
architecture, the IBM mainframe 360/370/390 architecture. I've got
something sort of working and need some advice & pointers. Long list
follows:
1) where are the latest gcc sources? I'm working on gcc-2.8.1
and have a core dump. Before I hit my head on it too hard, I'd
like to work with the latest.
2) the core dump is in cc1, in cse.c and only occurs when -O2 is
specified. Some instruction that wants to use a condition code
gets scheduled before the condition code is set. This causes a core
dump. Does this sound like a known bug?
3) How does one go about debugging something like this? The -da
flag was interesting, but I have no simple test case to demonstrate
the bug. Any tools I should be aware of?
4) how hard is it to take a gcc machine description file & port it
to egcs? Should I stick to gcc or is egcs really the future?
5) who owns crt0.o? the kernel? libc ? it seems not to be part of
binutils or gcc.
6) what's the best way to bootstrap an elf loader? In particular,
say I wanted to write something that will load and run elf binaries
(that have been linked to glibc) on MVS. What's the quickest way to
hack this up?
7) I'm trying to cross-compile glibc-2.0.6 but the cross-compiler
configure setup is a bit broken & requires nasty hacks. Is
cross-compiling fixed or improved in a later version?
8) what's the secret to configing the right math libs & etc for glibc?
9) is there a way of compiling glibc with support for long-long crippled
out? My version of gcc craps out on long long and I don't feel like
fixing it right now ...
- --linas
BTW, old and broken-ish patches to gcc and binutils are at
http://linas.org/linux/i370/ & will have newer patches soon.
------------------------------
From: holotko <[EMAIL PROTECTED]>
Date: Wed, 03 Feb 1999 22:15:14 +0000
Subject: Re: C++ Destructor Question
I just want to say thanks to everyone who responded to this posting.
Your responses were all very helpful in helping me to more fully
understand the concepts in question. Thanks to everyone and hopefully
I can offer similar assistance in the future...
/Sincerely,
John <[EMAIL PROTECTED]>
>
> holotko <[EMAIL PROTECTED]> wrote:
> >
> > Being spoiled by Java's garbage collector leads me to this quick
> > question again concerning constructors in C++.
> >
> > If I allocate memory via "new" using a constructor
> >
> > i.e.
> >
> > class Foo
> > {
> > Foo()
> > { word = new char[LENGTH + 1]; }
> >
> > ~Foo()
> > { delete word; }
> >
> > ...
> > }
> >
> > When I create an object of class Foo memory will be allocated for the
> > char buffer "word". Now when the object is no longer needed must I
>
- --
email: [EMAIL PROTECTED]
Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
------------------------------
From: holotko <[EMAIL PROTECTED]>
Date: Wed, 03 Feb 1999 22:26:42 +0000
Subject: Re: C++ Destructor Question
Prasanna Bose wrote:
>
> Actually the destructor should be
> ~Foo()
> { delete[] word; } // as an array has been allocated.
>
> vive,
> Prasanna subash
>
Actually, although I didn'tshow it in the example but I defined the
variable "word" at the beginning of the class as:
private:
char *word;
As a pointer.
Thus, when the allocated memory is killed can'tit be done as :
delete word;
Or is it still required that it be done in array format as:
delete[] word; ???
/John <[EMAIL PROTECTED]>
> >Hi,
> >The destructor is automatically called when the
> >object in question is no longer needed. Such as
> >an object is created inside a function locally and
> >when the function returns the object gets killed with
> >the destructor executed. Hence we dont call the
> >destructor explicitly.
> >
> >And in java I feel the garbage collection concept is
> >implemented quite strong and rarely do we use explicit
> >deallocation.
> >
> >Cheers,
> >Suresh
> >Wipro-Nortel Networks
> >Bangalore
> >>
> >>
> >>Being spoiled by Java's garbage collector leads me to this quick
> >>question again concerning constructors in C++.
> >>
> >>If I allocate memory via "new" using a constructor
> >>
> >>i.e.
> >>
> >> class Foo
> >> {
> >> Foo()
> >> { word = new char[LENGTH + 1]; }
> >>
> >> ~Foo()
> >> { delete word; }
> >>
> >> ...
> >> }
> >>
> >>When I create an object of class Foo memory will be allocated for the
> >>char buffer "word". Now when the object is no longer needed must I
> >>make an explicit call to the destructor ~Foo() to destroy the object
> >>and subsequently call "delete", or, is the destructor somehow called
> >>automatically when the object is no longer needed,i.e. outside of
> >>it's scope?
> >>
> >>Even in Java there are times when it is up to you to destroy an object
> >>and/or free memory used for that object, depending on how the object
> >>is/was created and an method equivalent of a destructor is required...
> >>The garbage collector is not always adequate.
> >>
> >>Thanks...
> >>
> >>Sincerely,
> >>
> >>/John <[EMAIL PROTECTED]>
> >>
> >>
> >>--
> >>email: [EMAIL PROTECTED]
> >>Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
> >>
> >>There is a great alternative to war, it's called Peace.
> >>
> >
> >
> >--
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
- --
email: [EMAIL PROTECTED]
Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
"I don't like dictatorship of the rich" - Alan Ginsberg.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Date: 04 Feb 1999 07:30:00 +0100
Subject: Re: porting to a new architecture
>>>>> Linas Vepstas writes:
> I've been working on a port of gcc/binutils/glibc to a new
> architecture, the IBM mainframe 360/370/390 architecture. I've got
> something sort of working and need some advice & pointers. Long list
> follows:
> 1) where are the latest gcc sources? I'm working on gcc-2.8.1
> and have a core dump. Before I hit my head on it too hard, I'd
> like to work with the latest.
Check egcs from http://egcs.cygnus.com
> 2) the core dump is in cc1, in cse.c and only occurs when -O2 is
> specified. Some instruction that wants to use a condition code
> gets scheduled before the condition code is set. This causes a core
> dump. Does this sound like a known bug?
> 3) How does one go about debugging something like this? The -da
> flag was interesting, but I have no simple test case to demonstrate
> the bug. Any tools I should be aware of?
> 4) how hard is it to take a gcc machine description file & port it
> to egcs? Should I stick to gcc or is egcs really the future?
> 5) who owns crt0.o? the kernel? libc ? it seems not to be part of
> binutils or gcc.
> 6) what's the best way to bootstrap an elf loader? In particular,
> say I wanted to write something that will load and run elf binaries
> (that have been linked to glibc) on MVS. What's the quickest way to
> hack this up?
> 7) I'm trying to cross-compile glibc-2.0.6 but the cross-compiler
> configure setup is a bit broken & requires nasty hacks. Is
> cross-compiling fixed or improved in a later version?
Please explain this in more detail. The last cross compile I did was
the test release 2.0.95 of glibc 2.1 and it worked.
> 8) what's the secret to configing the right math libs & etc for glibc?
You want to look through the sysdeps dir and check Implies.
> 9) is there a way of compiling glibc with support for long-long crippled
> out? My version of gcc craps out on long long and I don't feel like
> fixing it right now ...
Not that I know of.
Andreas
- --
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: 04 Feb 1999 01:31:15 -0600
Subject: Re: Bug with dlclose and static class elements
>>>>> "HH" == Harald Hoyer <[EMAIL PROTECTED]> writes:
HH> Hi,
HH> the attached tarball demonstrates the failure of deleting static elements in
HH> classes, if the library that contains these class is unloaded with dlclose.
HH> My question is whether this is a glibc (libdl) bug or a bug in generating the
HH> code (egcs).
HH> System is Linux kernel 2.2.0, glibc 2.0.111, gcc version egcs-2.91.58 19981101
HH> (egcs-1.1.1 pre-release).
It also happens with g++2.8.1 and related bug occurs with g++2.7.2
The problem is someone getting clever, in generating code, in 2.8.x.
The instead of putting the a call to the destructor in the .dtors section
atexit is called.
When dlclose is called the function is removed, and then when atexit
attempts to call the destructor it dies because the code is gone.
HH> Bug showed up in all older versions of kernel, libc and egcs.
HH> If this bug is known could you please point me to a fix.
A simple fix is to give your static file scope, and not function scope.
HH> If this bug is unknown I likely want to know, if it could be fixed in the recent
HH> future.
I don't know about fixing right but I have tracked it ;)
Eric
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 5 Feb 1999 02:21:20 -0600 (CST)
Subject: Re: porting to a new architecture
Hi,
It's been rumoured that Andreas Jaeger said:
>
> >>>>> Linas Vepstas writes:
>
> > I've been working on a port of gcc/binutils/glibc to a new
> > architecture, the IBM mainframe 360/370/390 architecture. I've got
> > something sort of working and need some advice & pointers. Long list
> > follows:
>
> > 1) where are the latest gcc sources? I'm working on gcc-2.8.1
> Check egcs from http://egcs.cygnus.com
OK, but where are the latest patches to gcc-2.8.1 ? Im looking for
2.8.1.0.xx whatever xx is, or even gcc-2.8.2 if that exists.
Is the machine description language the same for egcs and gcc?
what about the macros?
I really don't want to bite off more work porting to egcs, the project
is already way too complex.
> > 5) who owns crt0.o? the kernel? libc ? it seems not to be part of
> > binutils or gcc.
>
> > 6) what's the best way to bootstrap an elf loader? In particular,
> > say I wanted to write something that will load and run elf binaries
> > (that have been linked to glibc) on MVS. What's the quickest way to
> > hack this up?
>
> > 7) I'm trying to cross-compile glibc-2.0.6 but the cross-compiler
> Please explain this in more detail. The last cross compile I did was
> the test release 2.0.95 of glibc 2.1 and it worked.
OK, I'll try a newer glibc.
- --linas
Extra credit: anyone care to clue me in on how to implement 64-bit support
in the machine description file of a machine that only has 32-bit int math?
The current i370.md confuses 64-bit floats which the machine supports, with
64-bit ints, which the machine does not and thus its a real ugly mess.
In particular, will any patches for gcc be portable to egcs?
- --linas
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Fri, 5 Feb 1999 14:41:46 -0800 (PST)
Subject: binutils 2.9.1.0.20 is released.
WARNING: This release does not support Linux/PPC. Please don't use
it on Linux/PPC.
This should be final release for binutils 2.9.1.0.x based on binutils
2.9.1. I am planning to release to public this weekend. Please test it
as much as you can. Thanks.
This is the beta release of binutils 2.9.1.0.20 for Linux, which is
based on binutils 2.9.1 plus Linux/ARM support, some x86 assembler
changes, some PPC bug fixes, some alpha bug fixes and an exception
frame optimization bug fix.
Due to the exception frame optimization bug fix, it is highly
recommended that you recompile all your C++ codes. Otherwise,
exception handling may not work right when an exception is thrown.
Since I no longer have machine running libc 5, starting from this
release, there will be no pre-compiled binaries for libc 5.
There was some problem on Linux/alpha. The binaries generated by the
new binituls may not run correctly on Linux/alpha. It turned out it was
a bug in the alpha dynamic linker in glibc 2.0.6. The current glibc 2.1
and glibc 2.0.7 should be ok.
This release should work on linux/x86/alpha. There are some ELF bug
fixes. But I don't know if it fixes all the bugs reported on
linux/sparc, Linux/MIPS and linux/PPC. I'd like to hear reports on them.
I'd like to release it to public soon. Please test it as much as you
can.
Please report any bugs related to binutils 2.9.1.0.20 to [EMAIL PROTECTED]
Changes from binutils 2.9.1.0.20:
1. Enable ld for Solaris/x86.
2. Fix an ELF/i386 bfd/linker bug.
3. Fix a BFD bug.
4. Fix the ELF aligment.
5. Fix an AMD 3DNow! bug.
6. Fix ELF/x86 8/16-bit relocation bug.
7. Add --redefine-sym=old_form=new_form to objcopy.
8. Update cplus-dem.c from the egcs snapshot.
9. Support new Pentium II instructions.
10. Add --demangle/--no-demangle to ld.
Changes from binutils 2.9.1.0.19a:
1. A PPC DWARF2 EH patch for gas.
Changes from binutils 2.9.1.0.19:
1. Allow '.' in the middle of a symbol name for the versioning script.
Changes from binutils 2.9.1.0.17:
1. An ELF bug fix.
Changes from binutils 2.9.1.0.16:
1. Some Linux/Sparc64 patches.
2. A shared library linking patch.
3. Update cplus-dem.c from egcs 1.1.1 release.
Changes from binutils 2.9.1.0.15:
1. Update cplus-dem.c from egcs 1.1.1 prerelease.
2. Fix ARM bugs.
3. Fix MIPS/ELF bugs.
4. Fix an objdump bug.
Changes from binutils 2.9.1.0.14:
1. Update the program header handling bug fix from the binutils
snapshot.
2. Added AMD 3DNow! support to disassembler.
Changes from binutils 2.9.1.0.13:
1. An ELF bug fix for program header handling.
2. Added AMD 3DNow! support.
3. Add some vxworks suppport.
4. Fix ld on none-linux platforms.
Changes from binutils 2.9.1.0.12:
1. An ELF/alpha bug fix for creating large shared libraries.
2. An ELF/PPC bug fix.
Changes from binutils 2.9.1.0.11:
1. Use the real fix from Ian for the exception frame optimization bug.
Changes from binutils 2.9.1.0.10:
1. Fix an exception frame optimization bug.
Changes from binutils 2.9.1.0.9:
1. Fix another -Bsymbolic bug for Linux/alpha.
Changes from binutils 2.9.1.0.7:
1. Fix -Bsymbolic for Linux/alpha.
2. Fix a 16bit x86 gas bug.
Changes from binutils 2.9.1.0.6:
1. Fix various ARM bugs.
Changes from binutils 2.9.1.0.5:
1. A MIPS assembler ".align" bug is fixed.
2. bfd.h, bfd.h and bfdlink.h are included in the binary package.
Changes from binutils 2.9.1.0.4:
1. 2 x86 16bit mode assembler bugs, "ret" and "movb $35,0x4(%di)", are
fixed.
IMPORTANT:
The .plt format that the Alpha was using was not thread safe. So I
changed it. The new format is *not* binary compatible with the old,
thus you must use glibc 2.0.4 to get an ld.so that can understand it.
Note that the new ld.so knows how to deal with the old .plt format, so
old libraries will still work, but they should be relinked eventually
for performance reasons.
The file list:
1. binutils-2.9.1.0.20.tar.gz. Source code.
2. binutils-2.9.1.0.20-2.9.1.0.20.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.1.0.20-glibc.x86.tar.gz. Precompiled Linux/x86 binaries
for libc 6 (glibc 2.0.7 1998-12-11 or above).
4. binutils-2.9.1.0.20-alpha.tar.gz. Precompiled Linux/alpha binaries
for glibc 2.0.7 1998-12-11 or above.
The primary ftp sites for the Linux binutils are:
1. ftp://ftp.varesearch.com/pub/support/hjl/binutils
2. ftp://tsx-11.mit.edu/pub/linux/packages/GCC
3. ftp://sunsite.unc.edu/pub/Linux/GCC
The beta directory is in private/tofu under the GCC directory.
Most of my stuff can also be found at
1. ftp://ftp.kernel.org/pub/linux/devel/gcc
To install the binary package, please follow the procedure very closely.
Please backup/save all the files you are instructed to delete and you
should do
gzip -dc binutils-2.9.1.0.20-glibc.x86.tar.gz | tar tvvf -
or
gzip -dc binutils-2.9.1.0.20-alpha.tar.gz | tar tvvf -
to see what is in there.
Please do back up before you remove things.
To install for libc 6 (glibc 2.0.5c or above), PLEASE DO
1. su root
2. cd /
3. rm -f /usr/bin/encaps /usr/bin/nm
4. gzip -dc binutils-2.9.1.0.20-glibc.x86.tar.gz | tar xvvf -
5. ldconfig
Now you have the new gas/binutils under /usr/bin and
/usr/ix86-linuxaout/bin. You have to use
/usr/ix86-linuxaout/bin/as
and
/usr/ix86-linuxaout/bin/ld -m i386linux
if you want to use a.out as and ld directly.
To install for alpha, PLEASE DO
1. su root
2. cd /
3. gzip -dc binutils-2.9.1.0.20-alpha.tar.gz | tar xvvf -
4. ldconfig
I have changed the target names for Linux/x86 and Linux/x86 (a.out)
to ix86-linux and ix86-linuxaout respectively. The precompiled
binaries are installed under /usr/ix86-linux and /usr/ix86-linuxaout.
You should make appropriate symbolic links if you have a different
name for the Linux/x86 target, like i586-unknown-linux.
The target name for Linux/alpha is alpha-linux. The precompiled alpha
binaries are installed under /usr/alpha-linux. You should make
appropriate symbolic links if you have a different name for the
Linux/alpha target, like alpha-redhat-linux.
If you have an old linux library in the a.out format and you cannot
obtain the newer version in the ELF format for whatever reason, you
can try "objcopy --remove-leading-char" on the a.out library and see
if it can link with your code in ELF.
Thanks.
H.J. Lu
[EMAIL PROTECTED]
02/05/99
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 06 Feb 1999 08:25:35 -0800
Subject: FTP site for crypt code
Hi,
I'm ready to release glibc 2.1 for now three days but can't do this
because we don't have the crypt add-on in place. The place where it
was announced to be for the test releases is not stable and capable to
handle large numbers of requests. We can't upload it to the usual
place since the person who has to do this does not respond.
So, if you have a non-US FTP server large enough to handle a few
thousand downloads of a package with 30kB after every glibc release
please contact me ASAP.
Thanks,
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Oliver Mai <[EMAIL PROTECTED]>
Date: Sat, 06 Feb 1999 18:06:17 +0100
Subject: Problem w/ dynamic linking
This is a multi-part message in MIME format.
- --------------BA376F653969E23109B8F9D1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've got both libc5 and libc6 libraries on my system, my
primary C library is still libc.so.5.
The problem is that the dynamic linker for some programs
(the java bytecode interpreter in JDK 1.1.7) links libc5-based
X libraries, although the programs are libc6-based.
Here is my setup:
/etc/ld.so.conf:
/lib-aout=libc4
/usr/local/lib=libc5
/opt/kde/lib=libc5
/usr/X11R6/lib=libc5
/usr/i486-linuxaout/lib=libc4
/usr/openwin/lib
/opt/Office50/lib=libc6
/opt/jdk117_v1a/lib/i686/green_threads=libc6
(in /opt/Office50/lib I have all necessary libc6 libraries.)
I have attached the output of ldconfig -p (which is OK).
ldd /opt/jdk117_v1a/bin/i686/green_threads/java gives
following output:
libjava.so => /opt/jdk117_v1a/lib/i686/green_threads/libjava.so
(0x40010000)
libm.so.6 => /opt/Office50/lib/libm.so.6 (0x4007b000)
libdl.so.2 => /opt/Office50/lib/libdl.so.2 (0x40094000)
libawt.so => /opt/jdk117_v1a/lib/i686/green_threads/libawt.so
(0x40097000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x400df000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x400ec000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40134000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40149000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40152000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4015c000)
libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x401f7000)
libc.so.6 => /opt/Office50/lib/libc.so.6 (0x401fd000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x402a1000)
Here you see the problem: The dynamic linker should link the
libc6-based X libraries in /opt/Office50/lib and not the libc5-based
ones in /usr/X11R6/lib.
ldd /opt/Office50/bin/soffice.bin (output attached) shows that
the correct libc6-based X libraries are linked for StarOffice!
It does not help to set LD_LIBRARY_PATH.
I am using version 1.9.9 of ld.so (compiled for libc5).
Any idea what's wrong w/ my setup?
Thanks a lot in advance.
Cheers,
Oliver Mai
- --------------BA376F653969E23109B8F9D1
Content-Type: text/plain; charset=us-ascii; name="ldconfig.out"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="ldconfig.out"
310 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
libzip505li.so (libc6) => /opt/Office50/lib/libzip505li.so
libzip_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libzip_g.so
libzip.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libzip.so
libz.so.1 (ELF) => /usr/lib/libz.so.1
libz.so.0 (ELF) => /usr/lib/libz.so.0
libz.so (ELF) => /usr/lib/libz.so
libxv3.so.3 (libc4) => /usr/openwin/lib/libxv3.so.3
libxv3.so.2 (libc4) => /usr/openwin/lib/libxv3.so.2
libxview.so.3 (ELF) => /usr/openwin/lib/libxview.so.3
libwxutl_motif.so.1 (libc4) => /usr/i486-linuxaout/lib/libwxutl_motif.so.1
libwx_motif.so.1 (libc4) => /usr/i486-linuxaout/lib/libwx_motif.so.1
libvos505li.so (libc6) => /opt/Office50/lib/libvos505li.so
libvgagl.so.1 (ELF) => /usr/lib/libvgagl.so.1
libvga.so.1 (libc4) => /usr/i486-linuxaout/lib/libvga.so.1
libvga.so.1 (ELF) => /usr/lib/libvga.so.1
libvcl505li.so (libc6) => /opt/Office50/lib/libvcl505li.so
libuulib.so.0 (libc5) => /opt/kde/lib/libuulib.so.0
libuulib.so (libc5) => /opt/kde/lib/libuulib.so
libuuid.so.1 (libc5) => /lib/libuuid.so.1
libuuid.so.0 (libc4) => /lib/libuuid.so.0
libuuid.so (libc5) => /usr/lib/libuuid.so
libutil.so.1 (libc6) => /opt/Office50/lib/libutil.so.1
libusr505li.so (libc6) => /opt/Office50/lib/libusr505li.so
libuno505li.so (libc6) => /opt/Office50/lib/libuno505li.so
libtya.so (libc5) => /usr/local/lib/libtya.so
libtl505li.so (libc6) => /opt/Office50/lib/libtl505li.so
libtk505li.so (libc6) => /opt/Office50/lib/libtk505li.so
libtkx.so.3 (libc4) => /usr/i486-linuxaout/lib/libtkx.so.3
libtkt505li.so (libc6) => /opt/Office50/lib/libtkt505li.so
libtk.so.3 (libc4) => /usr/i486-linuxaout/lib/libtk.so.3
libtk.so.2 (ELF) => /usr/lib/libtk.so.2
libtk.so.1.4.0 (ELF) => /usr/lib/libtk.so.1.4.0
libtk.so.1 (ELF) => /usr/lib/libtk.so.1
libtiff.so.1 (ELF) => /usr/lib/libtiff.so.1
libtfu505li.so (libc6) => /opt/Office50/lib/libtfu505li.so
libtermnet.so.2 (ELF) => /usr/lib/libtermnet.so.2
libtermcap.so.2 (ELF) => /lib/libtermcap.so.2
libtermcap.so (ELF) => /usr/lib/libtermcap.so
libtcl7.6.so (ELF) => /usr/lib/libtcl7.6.so
libtclx.so.3 (libc4) => /usr/i486-linuxaout/lib/libtclx.so.3
libtcl.so.3 (libc4) => /usr/i486-linuxaout/lib/libtcl.so.3
libtcl.so.2 (ELF) => /usr/lib/libtcl.so.2
libtcl.so.1 (ELF) => /usr/lib/libtcl.so.1
libtcl.so (ELF) => /usr/lib/libtcl.so
libtawt_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libtawt_g.so
libtawt.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libtawt.so
libsysresource_g.so (libc6) =>
/opt/jdk117_v1a/lib/i686/green_threads/libsysresource_g.so
libsysresource.so (libc6) =>
/opt/jdk117_v1a/lib/i686/green_threads/libsysresource.so
libsw505li.so (libc6) => /opt/Office50/lib/libsw505li.so
libsvx505li.so (libc6) => /opt/Office50/lib/libsvx505li.so
libsvt505li.so (libc6) => /opt/Office50/lib/libsvt505li.so
libstu505li.so (libc6) => /opt/Office50/lib/libstu505li.so
libstdc++.so.27 (libc5) => /usr/lib/libstdc++.so.27
libstdc++.so.26 (libc5) => /usr/lib/libstdc++.so.26
libstdc++.so.2.7.2 (libc6) => /usr/lib/libstdc++.so.2.7.2
libstdc++.so (libc5) => /usr/lib/libstdc++.so
libss505li.so (libc6) => /opt/Office50/lib/libss505li.so
libsspkg.so.1 (ELF) => /usr/openwin/lib/libsspkg.so.1
libsspkg.so (ELF) => /usr/openwin/lib/libsspkg.so
libss.so.3 (libc4) => /usr/openwin/lib/libss.so.3
libss.so.2 (libc5) => /lib/libss.so.2
libss.so.1 (libc4) => /lib-aout/libss.so.1
libss.so.1 (libc4) => /lib/libss.so.1
libss.so (libc5) => /usr/lib/libss.so
libspl505li.so (libc6) => /opt/Office50/lib/libspl505li.so
libso505li.so (libc6) => /opt/Office50/lib/libso505li.so
libsot505li.so (libc6) => /opt/Office50/lib/libsot505li.so
libsm505li.so (libc6) => /opt/Office50/lib/libsm505li.so
libsim505li.so (libc6) => /opt/Office50/lib/libsim505li.so
libshujit.so (libc5) => /usr/local/lib/libshujit.so
libsfx505li.so (libc6) => /opt/Office50/lib/libsfx505li.so
libsex505li.so (libc6) => /opt/Office50/lib/libsex505li.so
libset505li.so (libc6) => /opt/Office50/lib/libset505li.so
libsd505li.so (libc6) => /opt/Office50/lib/libsd505li.so
libsdb505li.so (libc6) => /opt/Office50/lib/libsdb505li.so
libsc505li.so (libc6) => /opt/Office50/lib/libsc505li.so
libsch505li.so (libc6) => /opt/Office50/lib/libsch505li.so
libsb505li.so (libc6) => /opt/Office50/lib/libsb505li.so
libsba505li.so (libc6) => /opt/Office50/lib/libsba505li.so
librts505li.so (libc6) => /opt/Office50/lib/librts505li.so
librtl505li.so (libc6) => /opt/Office50/lib/librtl505li.so
librle.so.1 (ELF) => /usr/lib/librle.so.1
libresolv.so.2 (libc6) => /opt/Office50/lib/libresolv.so.2
libreg505li.so (libc6) => /opt/Office50/lib/libreg505li.so
libqt.so.1 (libc5) => /usr/X11R6/lib/libqt.so.1
libqt.so (libc5) => /usr/X11R6/lib/libqt.so
libpthread.so.0 (libc6) => /opt/Office50/lib/libpthread.so.0
libpthread.so.0 (ELF) => /lib/libpthread.so.0
libpthread.so (ELF) => /usr/lib/libpthread.so
libppm.so.1 (ELF) => /usr/lib/libppm.so.1
libpnm.so.1 (ELF) => /usr/lib/libpnm.so.1
libpng.so.1 (ELF) => /usr/lib/libpng.so.1
libpng.so.0 (ELF) => /usr/lib/libpng.so.0
libpng.so (ELF) => /usr/lib/libpng.so
libpgm.so.1 (ELF) => /usr/lib/libpgm.so.1
libpbm.so.1 (ELF) => /usr/lib/libpbm.so.1
libosl505li.so (libc6) => /opt/Office50/lib/libosl505li.so
libopcodes.so.2.6.0.14 (ELF) => /usr/lib/libopcodes.so.2.6.0.14
libone505li.so (libc6) => /opt/Office50/lib/libone505li.so
libolgx.so.3 (ELF) => /usr/openwin/lib/libolgx.so.3
libolg.so.3 (libc4) => /usr/openwin/lib/libolg.so.3
libofa505li.so (libc6) => /opt/Office50/lib/libofa505li.so
libnss_nis.so.1 (libc6) => /opt/Office50/lib/libnss_nis.so.1
libnss_files.so.1 (libc6) => /opt/Office50/lib/libnss_files.so.1
libnss_dns.so.1 (libc6) => /opt/Office50/lib/libnss_dns.so.1
libnss_db.so.1 (libc6) => /opt/Office50/lib/libnss_db.so.1
libnss_compat.so.1 (libc6) => /opt/Office50/lib/libnss_compat.so.1
libnsl.so.1 (libc6) => /opt/Office50/lib/libnsl.so.1
libni505li.so (libc6) => /opt/Office50/lib/libni505li.so
libnet_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libnet_g.so
libnet.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libnet.so
libncurses.so.1 (ELF) => /lib/libncurses.so.1
libncurses.so (ELF) => /lib/libncurses.so
libmmedia_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libmmedia_g.so
libmmedia.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libmmedia.so
libmimelib.so.1 (libc5) => /opt/kde/lib/libmimelib.so.1
libmimelib.so (libc5) => /opt/kde/lib/libmimelib.so
libmediatool.so.1 (libc5) => /opt/kde/lib/libmediatool.so.1
libmediatool.so (libc5) => /opt/kde/lib/libmediatool.so
libmath_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libmath_g.so
libmath.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libmath.so
libm.so.6 (libc6) => /opt/Office50/lib/libm.so.6
libm.so.5 (libc5) => /lib/libm.so.5
libm.so.4 (libc4) => /lib/libm.so.4
libm.so (libc5) => /usr/lib/libm.so
libkhtmlw.so.1 (libc5) => /opt/kde/lib/libkhtmlw.so.1
libkhtmlw.so (libc5) => /opt/kde/lib/libkhtmlw.so
libkfm.so.1 (libc5) => /opt/kde/lib/libkfm.so.1
libkfm.so (libc5) => /opt/kde/lib/libkfm.so
libkfile.so.1 (libc5) => /opt/kde/lib/libkfile.so.1
libkfile.so (libc5) => /opt/kde/lib/libkfile.so
libkdeui.so.1 (libc5) => /opt/kde/lib/libkdeui.so.1
libkdeui.so (libc5) => /opt/kde/lib/libkdeui.so
libkdecore.so.1 (libc5) => /opt/kde/lib/libkdecore.so.1
libkdecore.so (libc5) => /opt/kde/lib/libkdecore.so
libj505li_g.so (libc6) => /opt/Office50/lib/libj505li_g.so
libjscript.so.0 (libc5) => /opt/kde/lib/libjscript.so.0
libjscript.so (libc5) => /opt/kde/lib/libjscript.so
libjpeg_sun_g.so (libc6) =>
/opt/jdk117_v1a/lib/i686/green_threads/libjpeg_sun_g.so
libjpeg_sun.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libjpeg_sun.so
libjpeg.so.6 (ELF) => /usr/lib/libjpeg.so.6
libjpeg.so.1 (ELF) => /usr/lib/libjpeg.so.1
libjpeg.so (ELF) => /usr/lib/libjpeg.so
libjava_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libjava_g.so
libjava.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libjava.so
libiostream.so.26 (ELF) => /usr/lib/libiostream.so.26
libgtk.so.1.0.0 (libc5) => /usr/X11R6/lib/libgtk.so.1.0.0
libgtk.so.1 (libc5) => /usr/X11R6/lib/libgtk.so.1
libgtk.so (libc5) => /usr/X11R6/lib/libgtk.so
libgr.so.1 (libc4) => /usr/i486-linuxaout/lib/libgr.so.1
libgo505li.so (libc6) => /opt/Office50/lib/libgo505li.so
libglib.so.1.0.0 (libc5) => /usr/X11R6/lib/libglib.so.1.0.0
libglib.so.1 (libc5) => /usr/X11R6/lib/libglib.so.1
libglib.so (libc5) => /usr/X11R6/lib/libglib.so
libgimpui.so.1.0.0 (libc5) => /usr/X11R6/lib/libgimpui.so.1.0.0
libgimpui.so.1 (libc5) => /usr/X11R6/lib/libgimpui.so.1
libgimpui.so (libc5) => /usr/X11R6/lib/libgimpui.so
libgimp.so.1.0.0 (libc5) => /usr/X11R6/lib/libgimp.so.1.0.0
libgimp.so.1 (libc5) => /usr/X11R6/lib/libgimp.so.1
libgimp.so.0 (libc5) => /usr/local/lib/libgimp.so.0
libgimp.so (libc5) => /usr/local/lib/libgimp.so
libgimp.so (libc5) => /usr/X11R6/lib/libgimp.so
libgif.so.2 (libc5) => /opt/kde/lib/libgif.so.2
libgif.so (libc5) => /opt/kde/lib/libgif.so
libgdk.so.1.0.0 (libc5) => /usr/X11R6/lib/libgdk.so.1.0.0
libgdk.so.1 (libc5) => /usr/X11R6/lib/libgdk.so.1
libgdk.so (libc5) => /usr/X11R6/lib/libgdk.so
libgdbm.so.2 (ELF) => /usr/lib/libgdbm.so.2
libgdbm.so.0 (libc5) => /opt/kde/lib/libgdbm.so.0
libgdbm.so (libc5) => /opt/kde/lib/libgdbm.so
libgck.so.0.0.1 (libc5) => /usr/X11R6/lib/libgck.so.0.0.1
libgck.so.0 (libc5) => /usr/X11R6/lib/libgck.so.0
libgck.so (libc5) => /usr/X11R6/lib/libgck.so
libgal505li.so (libc6) => /opt/Office50/lib/libgal505li.so
libg++.so.27 (libc5) => /usr/lib/libg++.so.27
libg++.so.26 (libc5) => /usr/lib/libg++.so.26
libg++.so.2.7.2 (libc6) => /usr/lib/libg++.so.2.7.2
libg++.so (libc5) => /usr/lib/libg++.so
libf2c.so.0 (libc4) => /usr/i486-linuxaout/lib/libf2c.so.0
libf2c.so.0 (ELF) => /usr/lib/libf2c.so.0
libforms.so.0.86 (libc5) => /usr/X11R6/lib/libforms.so.0.86
libforms.so.0.81 (ELF) => /usr/lib/libforms.so.0.81
libforms.so.0 (ELF) => /usr/lib/libforms.so.0
libforms.so (libc5) => /usr/X11R6/lib/libforms.so
libforms.so (ELF) => /usr/lib/libforms.so
libfbm.so.1 (ELF) => /usr/lib/libfbm.so.1
libe2p.so.2 (libc5) => /lib/libe2p.so.2
libe2p.so.1 (libc4) => /lib-aout/libe2p.so.1
libe2p.so.1 (libc4) => /lib/libe2p.so.1
libe2p.so (libc5) => /usr/lib/libe2p.so
libe2fs.so.1 (libc4) => /lib-aout/libe2fs.so.1
libe2fs.so.1 (libc4) => /lib/libe2fs.so.1
libext2fs.so.2 (libc5) => /lib/libext2fs.so.2
libext2fs.so (libc5) => /usr/lib/libext2fs.so
libet.so.1 (libc4) => /lib-aout/libet.so.1
libet.so.1 (libc4) => /lib/libet.so.1
libdo505li.so (libc6) => /opt/Office50/lib/libdo505li.so
libdmn505li.so (libc6) => /opt/Office50/lib/libdmn505li.so
libdl.so.2 (libc6) => /opt/Office50/lib/libdl.so.2
libdl.so.1 (libc5) => /lib/libdl.so.1
libdl.so (libc5) => /lib/libdl.so
libdbm.so.2.0.0 (ELF) => /usr/lib/libdbm.so.2.0.0
libdbm.so.2 (ELF) => /usr/lib/libdbm.so.2
libdbm.so (ELF) => /usr/lib/libdbm.so
libdb.so.2 (libc6) => /opt/Office50/lib/libdb.so.2
libdb.so.2 (ELF) => /usr/lib/libdb.so.2
libdb.so.1 (libc4) => /usr/i486-linuxaout/lib/libdb.so.1
libdb.so (ELF) => /usr/lib/libdb.so
libcurses.so.1 (ELF) => /lib/libcurses.so.1
libcurses.so.0 (libc4) => /lib-aout/libcurses.so.0
libcurses.so (ELF) => /lib/libcurses.so
libcsp505li.so (libc6) => /opt/Office50/lib/libcsp505li.so
libcrypt.so.1 (libc6) => /opt/Office50/lib/libcrypt.so.1
libcom_err.so.2 (libc5) => /lib/libcom_err.so.2
libcom_err.so (libc5) => /usr/lib/libcom_err.so
libcnt505li.so (libc6) => /opt/Office50/lib/libcnt505li.so
libc.so.6 (libc6) => /opt/Office50/lib/libc.so.6
libc.so.5 (libc5) => /lib/libc.so.5
libc.so.4 (libc4) => /lib/libc.so.4
libc.so.1 (ELF) => /usr/lib/libc.so.1
libc.so (libc5) => /usr/lib/libc.so
libc-lite.so.4 (libc4) => /lib/libc-lite.so.4
libbfd.so.2.6.0.14 (ELF) => /usr/lib/libbfd.so.2.6.0.14
libbfd.so.2.5.2l.11 (ELF) => /usr/lib/libbfd.so.2.5.2l.11
libawt_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libawt_g.so
libawt.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libawt.so
libagent_g.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libagent_g.so
libagent.so (libc6) => /opt/jdk117_v1a/lib/i686/green_threads/libagent.so
libX11.so.6 (libc5) => /usr/X11R6/lib/libX11.so.6
libX11.so.6 (libc4) => /usr/i486-linuxaout/lib/libX11.so.6
libX11.so.6 (libc6) => /opt/Office50/lib/libX11.so.6
libX11.so.3 (libc4) => /usr/i486-linuxaout/lib/libX11.so.3
libX11.so.3 (libc4) => /lib/libX11.so.3
libX11.so (libc5) => /usr/X11R6/lib/libX11.so
libX11.so (libc6) => /opt/Office50/lib/libX11.so
libXtst.so.6 (libc5) => /usr/X11R6/lib/libXtst.so.6
libXtst.so.6 (libc6) => /opt/Office50/lib/libXtst.so.6
libXtst.so (libc5) => /usr/X11R6/lib/libXtst.so
libXtst.so (libc6) => /opt/Office50/lib/libXtst.so
libXt.so.6 (libc5) => /usr/X11R6/lib/libXt.so.6
libXt.so.6 (libc4) => /usr/i486-linuxaout/lib/libXt.so.6
libXt.so.6 (libc6) => /opt/Office50/lib/libXt.so.6
libXt.so.3 (libc4) => /usr/i486-linuxaout/lib/libXt.so.3
libXt.so.3 (libc4) => /lib/libXt.so.3
libXt.so (libc5) => /usr/X11R6/lib/libXt.so
libXt.so (libc6) => /opt/Office50/lib/libXt.so
libXpm.so.4 (libc5) => /usr/X11R6/lib/libXpm.so.4
libXpm.so.4 (libc4) => /usr/i486-linuxaout/lib/libXpm.so.4
libXpm.so.4 (libc6) => /opt/Office50/lib/libXpm.so.4
libXpm.so.3 (libc4) => /usr/i486-linuxaout/lib/libXpm.so.3
libXpm.so (libc5) => /usr/X11R6/lib/libXpm.so
libXpm.so (libc6) => /opt/Office50/lib/libXpm.so
libXp.so.6 (libc5) => /usr/X11R6/lib/libXp.so.6
libXp.so.6 (libc6) => /opt/Office50/lib/libXp.so.6
libXp.so (libc6) => /opt/Office50/lib/libXp.so
libXmu.so.6 (libc5) => /usr/X11R6/lib/libXmu.so.6
libXmu.so.6 (libc6) => /opt/Office50/lib/libXmu.so.6
libXmu.so (libc5) => /usr/X11R6/lib/libXmu.so
libXmu.so (libc6) => /opt/Office50/lib/libXmu.so
libXmt.so.2 (libc5) => /usr/X11R6/lib/libXmt.so.2
libXmt.so (libc5) => /usr/X11R6/lib/libXmt.so
libXm.so.2 (libc5) => /usr/X11R6/lib/libXm.so.2
libXm.so.2 (libc4) => /usr/i486-linuxaout/lib/libXm.so.2
libXm.so.1 (libc4) => /usr/i486-linuxaout/lib/libXm.so.1
libXm.so (libc5) => /usr/X11R6/lib/libXm.so
libXi.so.6 (libc5) => /usr/X11R6/lib/libXi.so.6
libXi.so (libc5) => /usr/X11R6/lib/libXi.so
libXext.so.6 (libc5) => /usr/X11R6/lib/libXext.so.6
libXext.so.6 (libc6) => /opt/Office50/lib/libXext.so.6
libXext.so (libc5) => /usr/X11R6/lib/libXext.so
libXext.so (libc6) => /opt/Office50/lib/libXext.so
libXaw3d.so.3 (libc4) => /usr/i486-linuxaout/lib/libXaw3d.so.3
libXaw.so.6 (libc5) => /usr/X11R6/lib/libXaw.so.6
libXaw.so.6 (libc4) => /usr/i486-linuxaout/lib/libXaw.so.6
libXaw.so.3.1.1 (libc4) => /usr/i486-linuxaout/lib/libXaw.so.3.1.1
libXaw.so.3 (libc4) => /usr/i486-linuxaout/lib/libXaw.so.3
libXaw.so.3 (libc4) => /lib/libXaw.so.3
libXaw.so (libc5) => /usr/X11R6/lib/libXaw.so
libXThrStub.so.6 (libc5) => /usr/X11R6/lib/libXThrStub.so.6
libXIE.so.6 (libc5) => /usr/X11R6/lib/libXIE.so.6
libXIE.so.6 (libc4) => /usr/i486-linuxaout/lib/libXIE.so.6
libXIE.so.6 (libc6) => /opt/Office50/lib/libXIE.so.6
libXIE.so (libc5) => /usr/X11R6/lib/libXIE.so
libXIE.so (libc6) => /opt/Office50/lib/libXIE.so
libUSS.so.2 (libc4) => /usr/openwin/lib/libUSS.so.2
libUIC.so.2 (libc4) => /usr/openwin/lib/libUIC.so.2
libSM.so.6 (libc5) => /usr/X11R6/lib/libSM.so.6
libSM.so.6 (libc6) => /opt/Office50/lib/libSM.so.6
libSM.so (libc5) => /usr/X11R6/lib/libSM.so
libSM.so (libc6) => /opt/Office50/lib/libSM.so
libPEX5.so.6 (libc5) => /usr/X11R6/lib/libPEX5.so.6
libPEX5.so.6 (libc6) => /opt/Office50/lib/libPEX5.so.6
libPEX5.so (libc5) => /usr/X11R6/lib/libPEX5.so
libPEX5.so (libc6) => /opt/Office50/lib/libPEX5.so
libMrm.so.2 (libc5) => /usr/X11R6/lib/libMrm.so.2
libMrm.so.2 (libc4) => /usr/i486-linuxaout/lib/libMrm.so.2
libMrm.so (libc5) => /usr/X11R6/lib/libMrm.so
libMagick.so.3 (libc5) => /usr/local/lib/libMagick.so.3
libMagick.so (libc5) => /usr/local/lib/libMagick.so
libICE.so.6 (libc5) => /usr/X11R6/lib/libICE.so.6
libICE.so.6 (libc6) => /opt/Office50/lib/libICE.so.6
libICE.so (libc5) => /usr/X11R6/lib/libICE.so
libICE.so (libc6) => /opt/Office50/lib/libICE.so
libBrokenLocale.so.1 (libc6) => /opt/Office50/lib/libBrokenLocale.so.1
libBLT.so.3 (libc4) => /usr/i486-linuxaout/lib/libBLT.so.3
ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
ld-linux.so.1.8.10 (ELF) => /lib/ld-linux.so.1.8.10
ld-linux.so.1.7.14 (ELF) => /lib/ld-linux.so.1.7.14
ld-linux.so.1.7.3 (ELF) => /lib/ld-linux.so.1.7.3
ld-linux.so.1 (ELF) => /lib/ld-linux.so.1
- --------------BA376F653969E23109B8F9D1
Content-Type: text/plain; charset=us-ascii; name="soffice.ldd"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="soffice.ldd"
libgo505li.so => /opt/Office50/lib/libgo505li.so (0x40010000)
libofa505li.so => /opt/Office50/lib/libofa505li.so (0x40096000)
libsvx505li.so => /opt/Office50/lib/libsvx505li.so (0x4016e000)
libsfx505li.so => /opt/Office50/lib/libsfx505li.so (0x40802000)
libsb505li.so => /opt/Office50/lib/libsb505li.so (0x40b2c000)
libso505li.so => /opt/Office50/lib/libso505li.so (0x40bb1000)
libsvt505li.so => /opt/Office50/lib/libsvt505li.so (0x40c52000)
libvcl505li.so => /opt/Office50/lib/libvcl505li.so (0x40e84000)
libtl505li.so => /opt/Office50/lib/libtl505li.so (0x410a5000)
libsot505li.so => /opt/Office50/lib/libsot505li.so (0x41115000)
libuno505li.so => /opt/Office50/lib/libuno505li.so (0x41143000)
libvos505li.so => /opt/Office50/lib/libvos505li.so (0x411bf000)
libosl505li.so => /opt/Office50/lib/libosl505li.so (0x411e4000)
libdl.so.2 => /opt/Office50/lib/libdl.so.2 (0x411f3000)
libpthread.so.0 => /opt/Office50/lib/libpthread.so.0 (0x411f7000)
libm.so.6 => /opt/Office50/lib/libm.so.6 (0x41204000)
libc.so.6 => /opt/Office50/lib/libc.so.6 (0x4121d000)
libone505li.so => /opt/Office50/lib/libone505li.so (0x412c1000)
librtl505li.so => /opt/Office50/lib/librtl505li.so (0x414fd000)
libX11.so.6 => /opt/Office50/lib/libX11.so.6 (0x414ff000)
libXext.so.6 => /opt/Office50/lib/libXext.so.6 (0x41596000)
libcnt505li.so => /opt/Office50/lib/libcnt505li.so (0x415a1000)
libusr505li.so => /opt/Office50/lib/libusr505li.so (0x41778000)
libtk505li.so => /opt/Office50/lib/libtk505li.so (0x419fb000)
libj505li_g.so => /opt/Office50/lib/libj505li_g.so (0x41acb000)
libXt.so.6 => /opt/Office50/lib/libXt.so.6 (0x41b60000)
libXmu.so.6 => /opt/Office50/lib/libXmu.so.6 (0x41ba3000)
libcrypt.so.1 => /opt/Office50/lib/libcrypt.so.1 (0x41bb3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libSM.so.6 => /opt/Office50/lib/libSM.so.6 (0x41be0000)
libICE.so.6 => /opt/Office50/lib/libICE.so.6 (0x41be8000)
- --------------BA376F653969E23109B8F9D1--
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 06 Feb 1999 12:09:42 -0800
Subject: glibc 2.1
Release 2.1 of the GNU C library is now available at
ftp://ftp.gnu.org/pub/gnu/glibc
and all the mirror sites around the globe.
The new files are
glibc-2.1.tar.gz
glibc-linuxthreads-2.1.tar.gz
glibc-crypt-2.1.tar.gz
People outside the US must *not* download the crypt add-on from this
server. Instead get the file from
ftp://ftp.funet.fi/pub/gnu/funet
There is no localedata add-on anymore as there was in glibc 2.0. Don't
use the add-on from glibc 2.0, the necessary data already comes with the
main tar file.
This release of the library runs on the following targets:
*-*-gnu GNU Hurd
i[3456]86-*-linux-gnu Linux-2.x on Intel
m68k-*-linux-gnu Linux-2.x on Motorola 680x0
alpha-*-linux-gnu Linux-2.x on DEC Alpha
powerpc-*-linux-gnu Linux and MkLinux on PowerPC systems
sparc-*-linux-gnu Linux-2.x on SPARC
sparc64-*-linux-gnu Linux-2.x on UltraSPARC
arm-*-none ARM standalone systems
arm-*-linux Linux-2.x on ARM
arm-*-linuxaout Linux-2.x on ARM using a.out binaries
Work on ports to mips-*-linux-gnu, sparc-sun-solaris, and mips-sgi-irix6
are under way but need more work. Help to finish the ports is welcome.
The 2.1 release is the result of two years of work and includes
thousands of changes, improvements, and bug fixes. It is therefore
advised that all users of glibc 2.0 upgrade to this version.
*BUT*: updating the C library is no trivial task and it is very easy
to damage one's system. Therefore, persons who do not exactly know
what to do, should consider using a binary distribution instead, when
they become available. All major Linux distributors will hopefully
base their next release on glibc 2.1. Don't tell us you haven't been
warned. Another reason why not everybody should think about compiling
glibc is the disk and CPU requirements: on Intel platforms the full
build requires about 290MB plus the space you need to install it.
This number is probably higher on RISC platforms. During the
compilation the compiler will need large amounts of virtual memory.
We are talking about 100MB on Intel and 200MB on Alpha. If using the
`-j' option of make this numbers grow linearly. Compiling takes more
than 4 hours on a i586@133, and still 45 minutes on a 2xi686@233. See
the FAQ file for more numbers.
In case you decide to compile glibc yourself you need to read the file
INSTALL. It will explain among other things which tools are
necessary. The most important one is the compiler. Although other
versions might work it is recommended to get egcs 1.1.1 to compile
glibc since it is the only version of gcc which proved to work for all
the supported platforms. In case of a problem during the compilation
with a compiler other than egcs 1.1.1 get the recommended version
first (at http://egcs.cygnus.com). This is especially true for gcc
2.7.2.3 which (some people believe) is a usable compiler. But in fact
it is extremely buggy and will definitely fail to compile glibc on
every platform.
The 2.1 release should be binary compatible with the 2.0 release. All
programs should continue to run. There are only a few exceptions:
- - some shared libraries have to be updated as well. They are using
details from the libc. These libraries include the C++ library
(libstdc++) and the curses library. See the FAQ for more information.
Programs using these libraries are not effected.
- - some programs use *internal* symbols of the C library. These names of
these symbols all start with an underscore and the reason why these
symbols are "internal" is because they change or might fall away in
new versions of the library. And this did happen a lot. Don't even
think about complaining on the libc lists about this, the programmers
of these applications made the errors. We have now mechanisms in
place which will prevent this from happening again even in the presence
of programmers unwilling to follow the rules.
For people using old pre-2.0 snapshots (this particularly affects
PowerPC users, for a while the standard glibc on powerpc was a 961212
snapshot), note that all 2.x versions are binary incompatible with
pre-2.0 snapshots. In general, binary compatibility is not guaranteed
if you use unreleased versions of glibc.
Problems should all be reported using the `glibcbug' shell script. Simply
run this script, fill out the information and you are set. If at the time
you start the script it complains like this
/usr/bin/glibcbug: emacs: command not found
simply set one of the environment variables EDITOR and VISUAL (this should
happen on every system automatically):
env EDITOR=vi glibcbug
Before sending a bug report make sure you have read the BUGS and the
FAQ file which come with the glibc sources. You won't even get an
answer if it is obvious you haven't read these files. It is also
helpful to scan the appropriate newsgroups and mailing lists to see
whether somebody else already had this problem. There is another
thing we don't want to hear about: the size. glibc is big, but this
is necessary for a multi-platform Unix library.
Over the last two years many people helped by contributing code,
reporting bugs, sending patches. I cannot mention them all here but
sure want to mention those who continuously helped all the time. In
purely random order:
Andreas Jaeger
Andreas Schwab
H.J. Lu
Philip Blundell
Richard Henderson
Geoff Keating
Zack Weinberg
Roland McGrath
Mark Kettenis
Thorsten Kukuk
Christian Gafton
The list with the changes below contains a few more names. Please
remember those names for the day you have the opportunity to thank
them.
Finally, the (certainly incomplete) list of changes:
* Richard Henderson corrected size of struct timeval on Linux/Alpha to
conform to POSIX member type requirements. Symbol versions have been
adjusted as needed within the library, and for direct use by applications,
but there is potential for problems if third-party libraries use
struct timeval as part of their interface. This does not present
a problem for X and other "essential" system libraries.
* An additional locale model to support C++ Standard Library locale
model and probably more was implemented by Ulrich Drepper.
* Eric Youngdale and Ulrich Drepper implemented versioning of objects on
symbol level.
* Miles Bader provided the `argp' function family to support hierachical
command line argument parsing, layered on top of getopt.
* strtod accepts new hexadecimal floating-point format from ISO C 9X.
* printf has two new specifiers %a and %A to print hexadecimal flaoting-point
numbers.
* scanf recognizes the %a and %A format for scanning floating point numbers.
* the new headers <stdint.h> and <inttypes.h> from ISO C 9X provides
information and interfaces for the available integer types.
* about 130 new math functions were added to implement the ISO C9x math
library.
* the new header <complex.h> contains definitions of the complex math
functions from ISO C 9X.
* the new header <tgmath.h> defines generic macros to use complex or
real valued functions.
* Thorsten Kukuk provided an implementation for NIS+, securelevel 0, 1 and 2.
* Andreas Jaeger provided a test suite for the math library.
* Mark Kettenis implemented the utmpx interface and an utmp daemon.
* Ulrich Drepper added character set conversion functions (iconv).
* Optimized string functions have been added.
* The localedata addon is now part of glibc.
* An implementation of profiling shared libraries was added by Ulrich Drepper.
* Thorsten Kukuk and Ulrich Drepper provided an implementation for a caching
daemon for NSS (nscd).
Missing a better place here are some numbers on improvements. Under
Linux 2.1.125 un-tar-ing the kernel sources takes
user system wall
using local files 12.19s 6.88s 22.91s
using NIS 13.92s 8.91s 26.34s
using NIS & nscd 10.37s 7.34s 25.30s
using NIS+ 27.57s 30.37s 640.46s
using NIS+ & nscd 10.25s 7.83s 26.51s
using NIS & old nscd [1] 13.83s 8.32s 29.60s
Keep in mind that non-namelookup related operations dominate above times.
It was just a common complain that using NIS+ unpacking the kernel is
horribly slow.
[1] The old nscd implementation is not available anymore since it was
distributed with glibc up to version 2.0.98 and thus is now replaced.
* Tim Waugh provided an implementation of the POSIX.2 wordexp function family.
* Mark Kettenis provided a Hesiod NSS module.
* The ELF dynamic loader knows how to process dynamic string tokens ($ORIGIN
and $PLATFORM) in RPATHs and similar strings (Ulrich Drepper).
* rcmd can now handle netgroups (Dick Streefland).
* A port to the ARM was contributed by Phil Blundell, Pat Beirne and Scott
Bambrough.
* Support for the IPv6 protocol has been added to the socket API, as per the
latest draft standards.
* Support for Linux 2.2 has been added.
- --
- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Alexander Feldman <[EMAIL PROTECTED]>
Date: Sat, 06 Feb 1999 22:10:35 +0200
Subject: Question about new software
Hello everybody,
I'm about to complete my first package which I consider will be useful
for the public.
It is a tool for helping sysadmins syncing password files among small
nets. Yes, I know there is NIS, but this is more easier to setup and
maintain. For now it consists from daemon for changing passwd/shadow
files, client for linux, client for window$, cgi script in perl.
I want to ask where to upload this, is there any interest and if there
is, how to get support for extending capabilities of the software. I'm
also interested who would help me with beta testing when I upload the
package.
Best regards:
Alexander Feldman
------------------------------
From: Linas Vepstas <[EMAIL PROTECTED]>
Date: Sat, 6 Feb 1999 20:21:01 -0600
Subject: function return values
OK,
thanks everyone; I got onto egcs it was a lot easier than I imagined.
I got extendsidi to work. Now for the next stumper:
How can I get functions that return scalars that are SImode or smaller
to return in a register, but functions returning DImode to do so in
memory?
I've got this little problem: by convention/history/backwards
comaptibility, the value returned by a subroutine went into
R15 (and there are only 16 registers, all SI in size.) So clearly
a DImode returned value won't fit. I can't just shuffle things around,
r14 is used for linkage, r13 for stack, r12 for toc, r11 for args.
So it would be nasty to move these.
I've tried fiddling with the FUNCTION_VALUE macro to turn it into a
pointer to memory, but that leads to various core dumps. I've tried
putting stronger restrictions on registers, but that never changes
anything.
Maybe I should try writing an instruction pattern that "demotes"
a set:DImode regsiter into an SImode pointer to memory?
- --linas
------------------------------
From: Torsten Duwe <[EMAIL PROTECTED]>
Date: Mon, 8 Feb 1999 16:33:29 +0100 (MET)
Subject: FTP site for crypt code
Ulrich> Hi, I'm ready to release glibc 2.1 for now three days but can't
Ulrich> do this because we don't have the crypt add-on in place.
[...]
Ulrich> So, if you have a non-US FTP server large enough to handle a few
[...]
What is your problem ? Does glibc-crypt contain more than DES ? In case you
missed it -- US export restrictions have been loosened last fall, up to 56
bit encryptions are free to go, unless the downloader sits in Cuba, the Iraq,
Iran, Libya or the like.
Torsten
------------------------------
From: Adam Wiggins <[EMAIL PROTECTED]>
Date: Mon, 8 Feb 1999 11:11:09 -0800 (PST)
Subject: Re: Question about new software
> It is a tool for helping sysadmins syncing password files among small
> nets. Yes, I know there is NIS, but this is more easier to setup and
> maintain. For now it consists from daemon for changing passwd/shadow
> files, client for linux, client for window$, cgi script in perl.
Cool. There is actually a commercial one (can't remember the name right off
hand) that was reviewed in Linux Journal this month which is similar.
But of course we always prefer free/open source software in these parts...
> I want to ask where to upload this,
You need to make a homepage for it. Go to www.linuxapps.com and look up any
small software package; most of them will have a homepage with a brief
description of the software, information on how to get it (or best yet,
a link straight to the file), and a screenshot if it's a GUI-based app.
If you don't have your own web space, there are several of sites which are
devoted to giving space to open source projects. I don't know any right
off hand, but I've seen them listed on slashdot.org in the past. Maybe
start with opensource.org and see if they've got some links...
> is there any interest and if there
> is, how to get support for extending capabilities of the software. I'm
> also interested who would help me with beta testing when I upload the
> package.
You just need to get people using it. Once that happens, it's inevitible
that you'll get a) bug reports and b) people who want to extend its
capabilities.
In order to get people using it, you first need the above-mentioned website.
Then you need to get it linked someplace with visibility. The first two
I'd go for would be linuxapps.com and freshmeat.net. Once you've got a
blurb about it archived in those two spots, other links should show up over
time.
------------------------------
End of linux-gcc-digest V1 #361
*******************************
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".
