move static libs from /lib to /usr/lib

[gerard@…]

Now that we don't use the ncurses patch anymore, we need to put the ln command back, that creates the libcurses.a symlink:

cd /lib && ln -s libncurses.a libcurses.a

[gerard@…]

And we should move all the static libraries to /usr/lib instead of keeping them in /lib

[markh@…]

Done both the moving static libraries and symlink things.

[gerard@…]

We need to expand on this bug.

there are more static libraries in /lib:

libpanel*.a libform*.a libmenu*.a - ncurses package libbz2.a - bzip2 package libshadow.a - shadow package

btw, the mv command in ncurses installation could be changed to : mv /lib/lib*.a /usr/lib

At that point there shouldn't be any other static libs in the /lib directory, but check it anyways. If there are others, then just use a mv /lib/lib*curses*.a /lib/libmenu*.a /lib/libform*.a /usr/lib (this is a bit shorter than typing out libcurses.a and libncurses.a)

[markh@…]

OK. I've sorted the ncurses static libraries:

cd /lib mv *.a /usr/lib ==> I checked and all the .a files in /lib at this point are from ncurses and should be moved to /usr/lib

chmod 755 *.5.2 ==> ldd complains if shared libraries aren't executable so chmod them.

cd /usr/lib ln -sf libncurses.a libcurses.a ==> Create the curses link

This is now in cvs.

The only other two .a files are from bzip2 and shadowutils. I'll deal with them tomorrow.

[gerard@…]

update ncures-exp.xml to explain why we mv, chmod and ln stuff

[gerard@…]

we need to create the /usr/lib/libncurses.so file containing this one line:

GROUP ( /lib/libncurses.so )

Or, simpler

cd /usr/lib ln -s ../../lib/libncurses.so

the reason for this is that without /usr/lib/libncurses.so, the linker ld will pick the static library first for some reason. Although "ld --verbose -lncurses" will find /lib/libncurses.so first, when I compiled vim and bash, the static ncurses lib was found first and used, so we ended up with a vim and bash that didn't use the dynamic ncurses lib

now that we move other libs like from shadow and bzip2, we should check for this same behaviour (or just make sure /lib/libxyz.so and /usr/lib/libxyz.so both exist and could be simple symlinks).

[markh@…]

ncurses explanation added

[markh@…]

I've added a command: ln -sf ../../lib/libncurses.so to the ncurses install as this seems the easiest way of solving this. I'm about to sort out bzip2 and shadow so I'll use the same method for those as well.

[markh@…]

Altered bzip2 chapter 6 install. The relevant changes are:

cp -af libbz2.so* /lib && --> removed copying libbz2.a to /lib

rm -f /usr/lib/libbz2.a && --> Left this in to remove chapter 5 installed libbz2.a file

cp -f libbz2.a /usr/lib && --> Copy the new .a file to /usr/lib instead

cd /usr/lib && ln -sf ../../lib/libbz2.so && --> Create the symlink to the shared library as mentioned for ncurses above.

[markh@…]

OK. Final part of this bug (I Hope!)

I've been checking out how shadow installs it's libraries. It installs the following in /lib

libshadow.a libshadow.la libshadow.so.0 -> libshadow.so.0.0.0 libshadow.so.0.0.0

I'm planning on moving libshadow.a to /usr/lib and possible linking /usr/lib/libshadow.so -> ../../lib/libshadow.so.0

Two points really. What should I do with the .la file, I was thinking of leaving it and symlinking it from /usr/lib (it seems to be some sort of config file but I'm not sure which is why I want advice). Secondly, would it be better to create a symlink in /lib: libshadow.so -> libshadow.so.0 then link /usr/lib/libshadow.so to this instead of directly to the .so.0 file?

[markh@…]

I've expanded the ncurses dynamic symlinks to encompass all five of the .so files. This should fix the problem completely. (I hope)

[gerard@…]

keep the .la files in /usr/lib. they are used by libtool

yes i'd create the /lib/libshadow.so symlink pointing to .so.0. This missing file always annoyed me as KDE likes to link to libshadow but libshadow.so couldn't be found anywhere. I read somewhere that this is done this way on purpose (not creating libshadow.so) but I don't know anymore why. Whether or not done on purpose, other packages (like kdebase or kdelibs) do want it.

[markh@…]

ok. this has all been done, statics moved and symlinks for dynamics created and it's all in cvs.