Hi Gilad I tried the dual installation of glibc-2.2 and glibc-2.3.
rpm -ivh fails the upgrade because the depend on their glibc-common packages (which don't want each other whatsoever). When I installed glibc with --nodeps I got a fine list of file conflicts. It seems like it's not intended to work. It seems like my only resort is to create a "compat-" RPM which only installs the stuff under /lib. Thanks, Isaac Aaron > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Gilad Ben-Yossef > Sent: Thursday, July 03, 2003 11:28 AM > To: Isaac Aaron > Cc: [EMAIL PROTECTED] > Subject: Re: Multiple GLIBCs > > > Isaac Aaron wrote: > > > >>-----Original Message----- > >>From: Gilad Ben-Yossef [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, July 03, 2003 10:56 AM > >>To: Isaac Aaron > >>Cc: [EMAIL PROTECTED] > >>Subject: Re: Multiple GLIBCs > >> > >> > >>Isaac Aaron wrote: > >> > >>>Hi List > >>> > >>>Running Red Hat 7.3 requires me to recompile everything I want > >> > >>from Red Hat 9 (or that is avaliable to Red Hat) before I install it. > >> > >>>I'm looking for a way to co-install GLIBC 2.3 with the existing > >> > >>GLIBC 2.1. > >> > >>>Any opinions? > >>> > >> > >>No problem at all. Linux (like other Un*x like systems) has a rather > >>elegant way to deal with libraries. When you install the RPM (I'm > >>assuming you using RPM) make sure to "install" with -i rather then > >>upgrade with -U. > >> > > > > > > Won't I need a --force there? > > Not because of the exitence of an older library. > > > How about if I just "steal" the libc* files (not links) and > drop them on the /usr/lib directory. > > Would that satisfy the RPM "Requires" directive? > > The application will be able to use them (once you run ldconfig at > least), but RPM will have no knowledge on it so it wont let you install > (unless you use --nodeps of course). > > > >>When the RPM will run ldconfig it will set things up so that > any program > >>that explicitly asks for the older version will get it, a program that > >>does not specify a specific version will get the latest, and if a > >>program seems to mis behave with the newer lib you can always use > >>LD_PRELOAD (man ld.so) to override. > > > > > > That seems to do the trick as long as the small stuff > "util-linux" "fileutils" are all linked in a way > > that won't mess up the whole installation. > > I don't think they will but don't trust me. Copy the binaries to some > bizzare location and use LD_PRELOAD to force load the library with the > stuff you need to test it BEFORE "installation". > > > Red hat used to have compat-glibc-* packages which contained > older glibc libraries. > AFAIR that was for REALLY old libc that had major binary interface > changes from the newer ones. > > > For some reason they don't do that anymore (to promote the > advanced server?). For 99% of the cases it's not needed. > > > > What would really be nice is if I had a way to prepare such > RPMS by myself (install cleanly, work with any version). > Of course you can! That's the whole point of using Free Software. Just > download the SRPMS use to create the RPMs you need and generate the RPMs > localy. man rpm for the gory details. > > Gilad > > > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] ================================================================To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
