Hi!
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>
rwolf@dretor.dciem.dnd.ca
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>
gdmr@dcs.ed.ac.uk
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
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:58 CDT