I have moved a critical lib from its location, so all programms linked to libc dont work .
I still have two shells on the machine, bash and ksh
The only thing I see is copying back the lib, but of course : dd, cp , mv etc are dead .
So i tryed a loop with read ...
{^Jwhile read line^Jdo^Jecho $line^Jdone } < /lib/TOTO.a.old > /lib/libTOTO.a
but it doesnt work because it s a binary file .(i tryed it elsewhere, the filesize doenst match ...)
Any idea ?
basically I need to copy back the file with ksh/bash builtins commands only
What if you export the LD_LIBRARY_PATH environment variable (to the directory where the libc library has been moved to) of your shell ( should be LIBPATH on AIX, I *guess*) and then try to exec the cp or mv programs?
That would have probably worked if the lib had been moved to a different directory while keeping its original name but I understand the issue is it has been renamed.
I am an admin, whenever I work , I have to be root, I am hired to login as root
Of course if i dont need to be root, I never am ...
to do my expreince I had to be root of course
fyi, i tryed ld_preload, wont do it, it is AIX it doesnt even support ldconfig ...
and most importantly, this a test server ... there is no way I would have attempted this elsewhere ...
It seems on AIX that would be LDR_PRELOAD=xxx but I doubt this can work anyway as the loader itself depends on libc to fulfill its tasks ... a catch-22 situation.
I was under the impression that LDR_PRELOAD was the preload directive, like the normal UNIX LD_PRELOAD. I think he would need LIBPATH which is the equivalent of LD_LIBRARY_PATH, would he not ? I guess it may be worth trying both...
LD_LIBRARY_PATH allows to set a list of directories where to the program loader will look for libraries. This is fine when the library you want to run is not in the default path but has kept its initial name. The OP issue is not the library being elsewhere but a library name mismatch due to a renaming. A preload was a good guess as it accepts a full arbitrary library name.
/usr/lib/libc.a <--- is ok , but commands need it call libcrypt.a too ...
/usr/lib/libcrypt.a <--- RIP , it's called now /usr/lib/libcrypt.a.old ,
aix 5.2 power3 , ksh vanilla and a fresh bash4 from oss4aix ...
i am going to complaint a little bit (just like its not my fault : if every programm that needs libc calls libcrypt.a , why they werent sticked together ? ... i know each one contains two kinda of sets of routines ... but fonctionally, having them together ... i wouldnt have done this !! yes my limit is libc, that one even on a unmounted floppy i wont touch it
under my AIX 5.2 its the .a ... for this libs, and many others are .a , very few .so
and no there is no libxxx.a and libxxx.so in either /lib nor /usr/lib of any "lib" in there .
its and old fashion unix , far from Linux ...
but its the same , if i remeber .so == shared objets , the file is practically just an archive holding the functions/routines ... so AIX calles it a .aRchive ...
here are my messages :
root@toto:/$ ls
Could not load program ls:
Could not load module /usr/lib/libc.a(shr.o).
Dependent module /usr/lib/libcrypt.a(shr.o) could not be loaded.
File /usr/lib/libcrypt.a is not an
archive or the file could not be read properly.
fyi : thnx god I mean, Bash, the tab tab works still, so i was able confirm where is what file ..
thnx again
Not only Gnu/Linux but almost all other Unix and Unix like implementations use .so for shared objects and .a for statically linked archives. AIX doesn't follow that convention.
What you might do to fix your problem is put that libcrypt.a file on some removable media like a USB key or drive, or a CD/DVD and use the LIBPATH trick. Alternatively, just put a statically linked mv command there and you are done.
One remaining issue would be the mount might fail because of that missing library ...
you'r right ... the mount is dead too ahhh i wish there were some statics on that machine ....
thnx for your time
---------- Post updated at 04:48 PM ---------- Previous update was at 04:42 PM ----------
just a note, I think with the prices of the disks today, all crucial binaries should be static,
yes i know i just didnt have to do that ... but bash knows, it might happend to someoneelse otherhow ...
could be a good idea for distros used by paraniods ... a packages of those bins -static version .
until then, i ll do it on my servers,
because talking about other reasons, if a hard disk sector fails, and that sector is used by a lib ... we will have the same issue .. currupted fs ... etc
I disagree with your conclusion.
Statically linked programs are evil and thus are phased out in modern Unix implementations. Dynamically loaded libraries aren't there (only) to save disk space but also to ease upgrade/patching and allow upward compatibility.
About your disk sector point, the best practice is to avoid it in the first place by using some redundancy in your volume management or file system.
for learning as you see 
