This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Jan Carlson <janc@iname.com>
Date: Sat, 24 Apr 1999 00:40:59 -0400
Subject: Re: What Netscape File?
Donald Carpenter wrote:
>
> Jan Carlson wrote:
>
> > Donald Carpenter wrote:
> > > You didn't say if you were running an Intel or Alpha
> > > system. But if your running an Intel system, then
> > > this Netscape
> > > http://rpmfind.net/linux/RPM/contrib/libc5/i386/communicator-4.5-1.i386.html
> > No, that's the wrong one. You want glibc, not libc5!
> I'm relatively new to Linux, but I installed that netscape
> on my box and it's working fine. That's why I suggested
> it. If it's the wrong one, why is it working on my RH 5.2
> system? (a question not sarcasm)
libc5 is the old nasty libc. glibc2 = libc6 is the nice new one that
Red Hat and the rest of Linux distros are moving to, or will.
Red Hat tries to support nasty old libc5 too, and Red Hat is good at
what they do, so the nasty old libc5 Netscape may work ok
for awhile.
Why does Netscape 'support' libc5 and not glibc? It's the lowest
common denominator. But in this case the lcd is not as stable,
for many.
===
Subject: Compiling Berkeley DB2 shared libraries
From: "Kevin Myer" <kevin_myer@elanco.k12.pa.us>
Date: Fri, 16 Apr 1999 12:06:31 -0400 (EDT)
Hi,
I have been attempting to get the Sleepycat Berkeley DB2 libraries,
version 2.7.3, installed on my system. At first, they weren't showing up
at all when I ran ldconfig. Then, I realized that they were just compiled
as static libraries so of course they weren't going to show up. So I read
some more documentation and found these instructions for making a shared
library:
(add -fpics to the CFLAG in the Makefile)
mkdir tmp
cd tmp
ar xv ../libdb.a
gcc -shared -o libdb.so *.o
This extracted the symbols and created what appeared to be a shared
library. It shows up in the list of shared libraries now but when I
attempted to compile a program (like OpenLDAP) it finds the header files,
recognizes that they are DB2, but it never finds the DB2 library. I
thought I could just symbolically link /lib/libdb.so.2 to
/usr/local/BerkeleyDB/lib/libdb.so but that didn't work either - running
ldconfig relinks it with /lib/libdb-2.0.7.so.
I'm thinking it must be a version problem - at compile time, it thinks
that libdb-2.0.7.so is newer than libdb.so but I don't know how to get
around it.
Any pointers or help on this matter would be greatly appreciated.
Thanks,
Kevin
==========
Subject: Re: Compiling Berkeley DB2 shared libraries
From: "Igor S. Livshits" <igorl@life.uiuc.edu>
Date: Fri, 16 Apr 1999 11:20:36 -0500
At 12:06 PM -0400 on 4/16/99, Kevin Myer wrote:
>Hi,
>
>I have been attempting to get the Sleepycat Berkeley DB2 libraries,
>version 2.7.3, installed on my system. At first, they weren't showing up
>at all when I ran ldconfig. Then, I realized that they were just compiled
>as static libraries so of course they weren't going to show up. So I read
>some more documentation and found these instructions for making a shared
>library:
>
>(add -fpics to the CFLAG in the Makefile)
>
>mkdir tmp
>cd tmp
>ar xv ../libdb.a
>gcc -shared -o libdb.so *.o
I'd recommend that you keep your locally compiled and packaged stuff
separately. To that end, grab the latest gcc, pgcc, or egcs (I used
gcc-2.8.1 on one system and egcs-1.1.2 on another) and compile and
install it in your /usr/local/ hierarchy. Then, recompile Berkeley DB
with the new compiler, and run make install which will add stuff to
the /usr/local/BerkeleyDB/ hierarchy. Follow the steps to produce a
shared version of Berkely DB and add it to /usr/local/BerkeleyDB/lib/.
Finally, make links in /usr/local/lib/, /usr/local/include, and
/usr/local/bin to the corresponding items within
/usr/local/BerkeleyDB.
Also, add /usr/local/lib to your /etc/ld.so.conf and run ldconfig.
You'll now be ready to compile and link against the new libraries
without any worries of stomping on stuff packaged by RedHat or others
using legacy libraries and gcc-2.7.2.*.
Here's a summary of the BerkeleyDB-2.7.3.1 steps I took on my system:
Install Berkeley DB 2.7.3
patch -p0 < ../archives/db-2.7.3-patches/patch.2.7.3.*
cd build_unix
env CC=gcc ../dist/configure --enable-compat185
make
make install
build a shared library as per
<http://www.sleepycat.com/docs/build/shared.html>
cp -r build_unix build_shlib
cd build_shlib
make clean
patch < ../../site/db.shlib.patch
make
mkdir tmp
cd tmp
ar xv ../libdb.a
gcc -shared -o libdb.so *.o
mv libdb.so /usr/local/BerkeleyDB/lib/
[inherited] create links in /usr/local/bin/, /usr/local/lib/, and
/usr/local/include/
ln -s ../BerkeleyDB/bin/db_* .
ln -s ../BerkeleyDB/lib/libdb* .
ln -s ../BerkeleyDB/include/db* .
ldconfig
==========
Subject: Re: Compiling Berkeley DB2 shared libraries
From: "Kevin Myer" <kevin_myer@elanco.k12.pa.us>
Date: Fri, 16 Apr 1999 15:35:45 -0400 (EDT)
On Fri, 16 Apr 1999, Igor S. Livshits wrote:
> I'd recommend that you keep your locally compiled and packaged stuff
> separately. To that end, grab the latest gcc, pgcc, or egcs (I used
> gcc-2.8.1 on one system and egcs-1.1.2 on another) and compile and
> install it in your /usr/local/ hierarchy. Then, recompile Berkeley DB
> with the new compiler, and run make install which will add stuff to
> the /usr/local/BerkeleyDB/ hierarchy. Follow the steps to produce a
> shared version of Berkely DB and add it to /usr/local/BerkeleyDB/lib/.
I have already done this. I am using pgcc 1.1.1 and Berkeley DB2 v2.7.3.
Everything compiles fine. Everything installs fine. The shared library
is generated fine. But nothing seems to include it in a compile. All
tests for DB2 fail. /usr/local/Berkeley/lib is in my /etc/ld.so.conf,
ldconfig was run many times, the shared library shows up as being in the
linker's cache BUT nothing seems to compile against it.
For example, if I run configure, trying to setup OpenLDAP 1.2.1, it barfs
./configure --with-ldbm-api=db2
[stuff deleted]
checking for DB2 library... checking for db_open in -ldb... no
no
checking for db.h... yes
checking if db.h is DB2... yes
checking for Berkeley DB2... no
configure: warning: could not find suitable LDBM backend
configure: error: select appropriate LDBM options or disable
ldconfig shows that:
/usr/local/BerkeleyDB/lib:
libdb-2.7.3.so => libdb-2.7.3.so
and this is symlinked in /usr/local/lib
I guess my question should have been - how do I force a program to use a
particular version of a library? Better yet, why isn't the linker smart
enough to figure out that one version of the db libraries is just plain
ole Berkeley DB while the other is Berkeley DB2?
I just want to take advantage of the newer features in DB2 - WAHHHHH!
More to the point - I know how to make the shared library and have it
recognized by the linker. However, why won't it compile DB2 related
stuff? Is there some sort of internal version number with shared
libraries that might be lower on the DB2 library than the legacy db
library? Hrm, or maybe the DB2 test routines in the configure script for
openLDAP are broken...any ideas to try??
Kevin
=============
Subject: Re: Making StarOffice work with glibc-2.1
From: Jan Carlson <janc@iname.com>
Date: Tue, 04 May 1999 14:12:57 -0400
"John N. Alegre" wrote:
>
> NOT THE PROBLEM.
>
> The problem is that upgrading anywhere past libc-2.0.7 breaks StarOffice. Sure
> you can go back and do a virgin install, but that will break everything that
> needs libc-2.1.1, which is most things in RH 6.0.
>
> The problem is finding a place to put the old libc and getting SO to find it
> before it finds the new one. Right answer gets super kudos from the list.
The solution is a 'wrapper' script for each of the
StarOffice executables.
1. Make a directory called /lib/rh52/
2. Copy libc-2.0.7 into /lib/rh52/
3. Set permissions on the new directory and libc-2.0.7
to be the same as their counterparts /lib and libc-2.1.1.
4. Find the executable for staroffice.
Suppose it's /opt/Office50/bin/so.
Make a new directory, say /opt/Office50/bin/rh52 and move
all unhappy StarOffice executables into it.
5. Make a script /opt/Office50/bin/so (same exactly as old executable),
containing:
#!/bin/bash
ME=$(basename $0)
LD_LIBRARY_PATH=/lib/rh52 /opt/Office50/bin/rh52/$ME $*
Make a script by the name of each executable you moved,
to take its place.
I don't know if this will work for StarOffice, but it probably
will - It does work for xcdroast which has a similar problem,
but with the tcl library instead.
===
Subject: Re: glibc
From: Rob Napier <rnapier@employees.org>
Date: Thu, 6 May 1999 09:54:23 -0400
glibc-2.1 is known to be incompatible with some products, notably
StarOffice.
Personally I'd hold off on glibc-2.1 unless you have packages that
need it.
If you do choose to install it, there's a compat-glibc-5.2-2.0.7.1.rpm
and compat-libs-5.2-1.rpm out there that are supposed to provide all
the old libraries. You can then use LD_LIBRARY_PATH to choose which
set of libraries you want to use. Haven't tried this because I've seen
no reason to go to glibc-2.1 at this point.
===
Subject: Re: Someone please explain to me the Berkeley DB mess in RH 6.0
From: "Steve \"Stevers!\" Coile" <scoile@redhat.com>
Date: Wed, 12 May 1999 07:42:55 -0400 (EDT)
[The DB saga according to Jeff Johnson, one of our developers. Note that
this is not an "official" Red Hat statement. I asked about this on an
internal mailing list and Jeff was kind enough to give me permission to
repost his response. -sjc]
There are three Berkeley DB libraries shipped with Red Hat 6.0. (Actually
there are two libraries, one of which has a (broken!) backward compatible
interface, but for the purposes of this discussion there are 3 ways to
try to use Berkeley DB libraries).
LIBRARY1) The db-1.85 that has always been part of linux.
To include: #include <db1/db.h>
To link: -ldb1
LIBRARY2) The newer db-2.x.y library with an incompatible interface.
To include: #include <db.h>
To link: -ldb
LIBRARY3) The newer db-2.x.y library with a compatible interface but
(broken!) incompatible database format.
To include: #include <db_185.h>
To link: -ldb
All Red Hat 6.0 packages (except glibc) should use LIBRARY1 because a)
LIBRARY3 has a (broken!) incompatible on-disk database format. Symptoms
are EINVAL returned (see symptom in text below). b) LIBRARY2 has
(except for glibc) a restrictive commercial license.
[Cristian Gafton, our lead developer, responds with: Actually, LIBRARY3
is not exactly broken. The on disk format is changed and matches the one
of LIBRARY2. Thus the only difference between the lib2 and lib3 above
are the programming interfaces used. There is no was to ensure binary
backwards compatibility between db-2 and the older db-1.85.]
Everything would be hunky-dory EXCEPT that LIBRARY1 needs explicit
changes to force it's use. Consequently many, many packages are gonna
configure against LIBRARY2 or LIBRARY3 and will need to be forced to
build against LIBRARY1 for the Right Thing To Happen.
To further obscure the issue: It's OK to use db2 with glibc. Several
programs (NIS database management programs come to mind) that are part of
the glibc package may very well do that. That means that tools that want
to access those data bases will probably have to be built to use something
other than LIBRARY1. [...]
Oh, yeah the sonames of the shared libraries are gonna confuse everybody
too. AFAIK, you can sort out what's what using ldd as follows
LIBRARY1 /lib/libdb1.so.2 -> libdb1-2.1.1.so
(glibc-2.0.7 compat) /lib/libdb.so.2 -> libdb1-2.1.1.so
LIBARRY2 /lib/libdb.so.3 -> libdb-2.1.1.so
LIBARRY3 /lib/libdb.so.3 -> libdb-2.1.1.so
And then there's the file(1) problem -- I'll try to fix this one.
And, to address the gentleman's problem, he needs to include <db1/db.h>
and link with -ldb1 just like the Red Hat 6.0 sendmail does and forget
about using db_dump and db_dump185. At least I think that will work ...
[Cristian adds: He will need a compatibility DB_File module, built against
the db-1.85 library - I will get this out as part of the powertools.]
===
Subject: Re: Broken Glint
From: Jan Carlson <janc@iname.com>
Date: Wed, 07 Apr 1999 00:50:07 -0400
Bruce Richardson wrote:
>
> Upgrading tcl/tk to 8.04 (or possibly upgrading python) seems to have
> broken Glint. If I select some packages and then click on Upgrade, it does
> the job but Glint stops updating it's display from that point - I have to
> click on the close button for the progress bar and the Installed/Available
> windows show false information from then on.
>
> Unfortunately, Red Hat don't seem to be developing Glint any further (this
> is a shame - gnorpm may be prettier but it has no equivalent to Glint's
> Installed/Available interface, a big victory for style over content).
> Anyone know how I can fix Glint?
Keep 2 copies of the tcl library, or whatever library
is giving glint fits. Point glint to the copy
it likes. It will be happy.
How?
Reinstall the old tcl rpm that makes glint work.
rpm -Uvh --oldpackage tcl-oldversion.rpm
Go to /usr/lib.
cp libtcl8.0.so libtcl7.9.so
but be sure the two names have the same number of characters.
Then emacs (not vi) /usr/bin/glint and change
libtcl8.0 to libtcl7.9 inside glint, and save.
Don't let emacs put a newline at the end of glint!
Now reinstall the tcl version you really wanted.
Glint is now pointed to the tcl it likes, and
your other programs will use the other one.
It's also a fix that tends to get wiped out
as I upgrade, but it's sometimes better than waiting for
new packages that cooperate.
I did this to xcdroast because 'wish' hates
tcl that xcdroast likes. make xconfig uses wish,
so I need wish to work.
Anybody have a cleaner way to make xcdroast and
'wish' work at the same time, besides recompiling
one of them?
===
Subject: Re: Broken Glint, redhat-digest Digest V99 #768
From: "Walter B Kulecz, PhD" <wally@wahine.jsc.nasa.gov>
Date: Wed, 07 Apr 1999 10:45:09 -0500
>Anybody have a cleaner way to make xcdroast and
>'wish' work at the same time, besides recompiling
>one of them?
>
What's wrong with the standard wrapper method where you move the old
library to say /usr/local/lib/libtcl8.0.so.
If /usr/local/bin is first in your path all you need to do is create an
executable file named glint
#!/bin/shell
export LD_PRELOAD=/usr/local/lib/libtcl8.0.so
/usr/bin/glint $*
if /usr/bin is searched first then you need to rename glint and use the new
name in the shell script.
===
Subject: Re: a.out-type compatibility gone?
From: Steve Borho <sborho@ststech.com>
Date: Tue, 6 Jul 1999 14:46:30 -0500
On Tue, Jul 06, 1999 at 03:32:32PM -0400, Tasos Kotsikonas wrote:
> Is anyone having problems running mwm under 6.0? My executable is
> statically linked, and of the a.out type, and it appears the new
> kernels have dropped the backward compatibility for that executable
> format.
>
> Do you have any suggestions as to how I might be able to run the
> mwm executable on redhat 6?
try:
modprobe binfmt_aout
===