libc.so.1.6 and libc.so.1.8
Thanks to
Michael Sullivan <mike@trdlnk.chi.il.us>
Mike Raffety <mike_raffety@il.us.swissbank.com>
grevemes%VTC@TACOM-EMH1.Army.Mil
Michael Betti/Development <betti@reston.raxco.com>
Russ Poffenberger <poffen@San-Jose.ate.slb.com>
Mike Hill <mhill@lesol1.dseg.ti.com>
"Todd L. Kindig-System Manager" <tlk@micom.com>
Dan Stromberg - OAC-DCS <strombrg@hydra.acs.uci.edu>
Jian Ye <ye@Software.ORG>
al griffin <griffin@bialy.lehman.com>
"LaCoursiere J. D." <z056716@uprc.com>
Keith Bierman Fortran Team <Keith.Bierman@eng.sun.com>
Barry Margolin <barmar@Think.COM>
Jim Redpath SRI Ft Bragg <jredpath@ags.ga.erg.sri.com>
I would like to clarify that I mistakenly stated that the programs bombed.
They gave ld.so warnings.
The answers ranged from "No Problem" to "Watch Out".
I have one response that such a thing has been tried with no problems. A
4.1.1 system with libc.so.1.8 is running fine for over a year.
Any way here's the summary.
--------------------------original question------------------------------
We have a a few suns running SunOS 4.1.1 and a bunch others running SunOS
4.1.3. I have compiled C programs on the 4.1.3 machines and could not run
them on the 4.1.1 machines due to different versions of shared libraries.
The programs would ask for libc.so.1.8 and bomb. To solve this problem I
copied libc.so.1.8 and libc.sa.1.8 from a 4.1.3 machine to the 4.1.1
machine, and ran ldconfig. ldconfig updates the cache so the dynamic
linker uses the shared library with the higher rev. The programs ran
happily there after. The 4.1.1 machine has been running for more than 10
days since, and no adverse side-effects have been observed from any
operating system/user programs.
Am I safe to assume that the libc.so.1.8 library of 4.1.3 is fully
backward compatible with the libc.so.1.6 library of 4.1.1? I will
appreciate your responses and comments.
Gautam
----------------------------Resoponses------------------------------------
From: Michael Sullivan <mike@trdlnk.chi.il.us>
>Am I safe to assume that the libc.so.1.8 library of 4.1.3 is fully
>backward compatible with the libc.so.1.6 library of 4.1.1? I will
>appreciate your responses and comments.
To the best of my knowledge, your assumption is correct.
We copied libc.s[oa].1.8 onto some 4.1.1 and 4.1.2 systems over a year ago and
have never experienced any problems.
--
Michael T. Sullivan | email:mike@trdlnk.chi.il.us
TradeLink L.L.C. | voice: +1 312 408 2599
175 W. Jackson, Suite A1235 | fax: +1 312 939 2531
Chicago, Illinois 60604 USA |
---------------------------
From: Mike Raffety <mike_raffety@il.us.swissbank.com>
Well, in effect, you've partially upgraded the 4.1.1 machines to 4.1.3.
If you copy over /vmunix too, you've pretty much done it. :)
---------------------------
From:grevemes%VTC@TACOM-EMH1.Army.Mil
Your better approach is to create a symbolic link:
ln -s libc.so.1.6 libc.so.1.8
this will leave only the one library from the right OS.
-seg
---------------------------
From: Michael Betti/Development <betti@reston.raxco.com>
> Am I safe to assume that the libc.so.1.8 library of 4.1.3 is fully> backward compatible with the libc.so.1.6 library of 4.1.1? I will > appreciate your responses and comments.
The only problem will be if you want to compile on the 4.1.1 system and
want the software to run correctly on another 4.1.1 system. The compiler
will use the latest version of the libraries that you have loaded, so,
in effect, you will have a binary that will use some 4.1.1 information
(includes) with 4.1.3 shared libc libraries.
If you are doing no development on the 4.1.1 system, then you should not
have any problems.
Good Luck.
Mike
------------------------
From:rwolf@dretor.dciem.dnd.ca
Ummmm. You may be okay, but personally I would have taken the 4.1.1 shared
libraries and simply changed the name to the same version number.
Hope it works.
Robert
---------------------------
From: Russ Poffenberger <poffen@San-Jose.ate.slb.com>
I am surprised that the programs bomb. What are the effects?
We have a mixed house also, and the worst I have ever seen is a warning about
libc being older than expected, but never had a problem with the program
running.
---------------------------
From: Mike Hill <mhill@lesol1.dseg.ti.com>
Why not just compile the programs statically instead of dynamically? Then
the library is included in the program and you won't have to worry.
---------------------------
From: "Todd L. Kindig-System Manager" <tlk@micom.com>
I believe you can run sunupgrade (30 minutes from cd) and have em all up
to 4.1.3.. Why not?
-------------------------
From: Dan Stromberg - OAC-DCS <strombrg@hydra.acs.uci.edu>
Subject: Re: libc.so.1.6 and libc.so.1.8
If you just compile under 4.1.1 you should be in good shape under
either.
Dan Stromberg - OAC/DCS strombrg@uci.edu
---------------------------
From:gdmr@dcs.ed.ac.uk
> The programs would ask for libc.so.1.8 and bomb.
That indicates that you're using some feature of the later version that isn't
in the earlier version. Normally it's just a warning and the program runs
anyway.
> Am I safe to assume that the libc.so.1.8 library of 4.1.3 is fully> backward compatible with the libc.so.1.6 library of 4.1.1?
No.
If you really must do this kind of thing then the safest way would be to put
the alien version in a directory of its own on the 4.1.1 machine and use
LD_LIBRARY_PATH to make your application use it instead of the correct one for
the machine.
********** I have done just this. Thanks. Gautam Das
-------------------------
From: Jian Ye <ye@Software.ORG>
I have similar problem, I have some machines on 4.1.2 with shared
lib rev 7. I always get warning from time to time, but I am not
brave enough to do what you did. So could you please post a summary.
I'd very appreciate it. I am looking forward to read your summary and
good luck in getting your responses.
-------------------------
From: al griffin <griffin@bialy.lehman.com>
Bad idea. Your SunOS 4.1.1 system is no longer standard, it is nothing.
The proper way was to compile your applications with a "-Bstatic" for the
runtime libraries that changed. To identify your runtime libraries execute
"ldd application_name"
If you feel that you just cannot compile staticly, copy the runtime libraries
into a directory with other application specific files and modify your
"LD_LIBRARY_PATH" by putting the new directory first in the PATH. Then when
your application is run it will find the needed libraries and your system
directories will still be standard.
-------------------------
From: "LaCoursiere J. D." <z056716@uprc.com>
You can run ldd on the resulting binaries to show which shared lib they
are dependant on. By having both versions on your machine, you should be
able to satisfy both sets of binaries. The best thing to do in this case
(in my opinion, of course) is to statically compile the binaries that will
exist on both machines. You can do this with the flag "-Bstatic" on the
link line.
------------------------
From: Keith Bierman Fortran Team <Keith.Bierman@eng.sun.com>
>Am I safe to assume that the libc.so.1.8 library of 4.1.3 is fully
No. Backwards compatibility is neither designed for nor tested. It
might work. I have no proof (offhand) that it doesn't. But you are
completely on your own.
Generally the advice to application creators is to build on the lowest
rev of the OS that the application is intended to support. Upwards
compatibility *is* a design goal and often *is* tested.
------------------------
From: Barry Margolin <barmar@Think.COM>
>Am I safe to assume that the libc.so.1.8 library of 4.1.3 is fully>backward compatible with the libc.so.1.6 library of 4.1.1? I will >appreciate your responses and comments.
No. The 4.1.3 version of libc may depend on kernel features that didn't
exist in 4.1.1.
The recommended solution is to do all your compiling on the oldest system
you wish to run on. New releases are designed to run programs compiled on
old releases, but it's not possible for 4.1.1 to have anticipated the
needs of 4.1.3 libraries.
---------------------------
From: Jim Redpath SRI Ft Bragg <jredpath@ags.ga.erg.sri.com>
I would have NOT done that, wasting space and possible lookup problems (maybe);
Simply just make a symbolic link of the name libc.sa.1.8 to libc.so.1.6.
******Jim, This does not work ----- Gautam
---------------------------
Gautam
