currently if you have this setup: root@vapier 0 work # pwd /var/tmp/portage/testing-0/work root@vapier 0 work # ls -al total 12 drwx------ 2 root root 4096 Jul 28 21:54 . drwxr-xr-x 6 portage portage 4096 Jul 28 21:54 .. -rw-r--r-- 1 root root 2 Jul 28 21:54 blah.so lrwxr-xr-x 1 root root 7 Jul 28 21:54 blah.so.1 -> blah.so lrwxr-xr-x 1 root root 7 Jul 28 21:54 blah.so.2 -> blah.so and you run `dolib.so blah.so*`, you'll get this root@vapier 0 lib # pwd /var/tmp/portage/testing-0/image/usr/lib root@vapier 0 lib # ls -al total 20 drwxr-xr-x 2 root root 4096 Jul 28 21:56 . drwxr-xr-x 3 root root 4096 Jul 28 21:55 .. -rwxr-xr-x 1 root root 2 Jul 28 21:56 blah.so -rwxr-xr-x 1 root root 2 Jul 28 21:56 blah.so.1 -rwxr-xr-x 1 root root 2 Jul 28 21:56 blah.so.2 so i made a patch so the 'proper' behavior will be: root@vapier 0 lib # pwd /var/tmp/portage/testing-0/image/usr/lib root@vapier 0 lib # ls -al total 12 drwxr-xr-x 2 root root 4096 Jul 28 21:56 . drwxr-xr-x 3 root root 4096 Jul 28 21:55 .. -rwxr-xr-x 1 root root 2 Jul 28 21:56 blah.so lrwxr-xr-x 1 root root 7 Jul 28 21:56 blah.so.1 -> blah.so lrwxr-xr-x 1 root root 7 Jul 28 21:56 blah.so.2 -> blah.so note ! if the lib is linked in some other manner than that (i.e. the file is trying to do /usr/lib/libblah.so -> /lib/libblah.so.1, or /usr/lib/libblah.so -> /usr/lib/blahblah/blahhh/liblbah.so.1, then this patch will still do /usr/lib/libblah.so -> libblah.so.1). i figured that ppl who do crazy linking have a makefile ...
Created attachment 15165 [details, diff] dolib.so.patch was made against dolib.so but it is trivial to apply to dolib.a also
Created attachment 15166 [details, diff] dolib.so.patch err, wrong file :/
*** Bug 36094 has been marked as a duplicate of this bug. ***
*** Bug 36095 has been marked as a duplicate of this bug. ***
This bug is a few month old and a patch exists, so why it is not included in portage yet?
I think that 'readlink' command is better than "$(basename $(ls -al ${x} | awk '{print $NF}'))" carpaski: Is there a reason not to include this patch? If not, I'll do...
the reason i didnt use readlink at the time was because readlink was part of debianutils ... i didnt want to make portage DEPEND on such a thing :) now that it's part of coreutils i guess using readlink is cool
Created attachment 41067 [details, diff] dolib.patch nick: here's a much cooler patch ... lets get it into .51 !@ - have dolib create symlinks - have dolib.a/dolib.so just call dolib with the appropriate $LIBOPTIONS having the same code duplicated in dolib/dolib.a/dolib.so is just a waste ... so now everything is just in dolib also, having the strip in dolib.so was pointless since portage runs strip on all the shared files in $D anyways
*** Bug 65730 has been marked as a duplicate of this bug. ***
*** Bug 67012 has been marked as a duplicate of this bug. ***
*** Bug 67790 has been marked as a duplicate of this bug. ***
Bug has been fixed and released in stable portages on or before 2.0.51-r2
@Nicholas Jones: This bug has been fixed? Look at comment #10: http://bugs.gentoo.org/show_bug.cgi?id=67012 It's still there. I'm using Portage 2.0.51-r2, "x86" Reopen?
yes this bug is fixed Bug 67012 was filed before 2.0.51 was released :p