/opt/firebird/bin/fbmgr.bin: error while loading shared libraries: libfbclient.so.1: cannot open shared object file: No such file or directory Also, php doesn't recompile after revdep-rebuild : checking for isc_detach_database in -lfbclient... no checking for isc_detach_database in -lgds... no checking for isc_detach_database in -lib_util... no configure: error: libgds, libib_util or libfbclient not found! Check config.log for more information. Something missing ?
and impossible to downgrade, dev-db/firebird-1.5.3-r1 isn't is the tree anymore ! Please, help !
Solved by : # pwd /usr/lib64 # ln -snf ../../opt/firebird/lib/libfbclient.so # ln -snf libfbclient.so libfbclient.so.1 Something really wrong with the ebuild.
I am not sure how you are missing those links? From ebuild # create links for back compatibility dosym ../../opt/firebird/${my_lib}/libfbclient.so /usr/${my_lib}/libgds.so dosym ../../opt/firebird/${my_lib}/libfbclient.so /usr/${my_lib}/libgds.so.0 dosym ./libfbclient.so /opt/firebird/${my_lib}/libgds.so dosym ./libfbclient.so /opt/firebird/${my_lib}/libgds.so.0 # we want relative symlinks... dosym ../../opt/firebird/${my_lib}/libfbclient.so /usr/${my_lib}/libfbclient.so dosym ../../opt/firebird/${my_lib}/libfbclient.so.1 /usr/${my_lib}/libfbclient.so.1 dosym ../../opt/firebird/${my_lib}/libfbclient.so.1.5.4 /usr/${my_lib}/libfbclient.so.1.5.4 Then from system nas ~ # ls -l /opt/firebird/lib/ total 540 lrwxrwxrwx 1 firebird firebird 16 May 13 12:54 libfbclient.so -> libfbclient.so.1 lrwxrwxrwx 1 firebird firebird 20 May 13 12:54 libfbclient.so.1 -> libfbclient.so.1.5.4 -r-xr-xr-x 1 firebird firebird 538360 May 13 12:54 libfbclient.so.1.5.4 lrwxrwxrwx 1 root root 16 May 13 12:54 libgds.so -> ./libfbclient.so lrwxrwxrwx 1 root root 16 May 13 12:54 libgds.so.0 -> ./libfbclient.so -r-xr-xr-x 1 firebird firebird 4608 May 13 12:54 libib_util.so nas ~ # ls -l /usr/lib64/libfbclient.so* lrwxrwxrwx 1 root root 37 May 13 12:54 /usr/lib64/libfbclient.so -> ../../opt/firebird/lib/libfbclient.so lrwxrwxrwx 1 root root 39 May 13 12:54 /usr/lib64/libfbclient.so.1 -> ../../opt/firebird/lib/libfbclient.so.1 lrwxrwxrwx 1 root root 43 May 13 12:54 /usr/lib64/libfbclient.so.1.5.4 -> ../../opt/firebird/lib/libfbclient.so.1.5.4 Not sure why those symlinks weren't created for you in your env? Are you running a 64bit arch? That part of the ebuild did not change from 1.5.3. Other than me introducing ${my_lib} so the link will go in lib64 or lib depending on arch. Even though lib is a link to lib64. Actually having reviewed past 1.5.3 ebuilds, they never put links in /usr/lib? Looks to be first used in 1.5.4? http://viewcvs.gentoo.org/viewcvs.py/gentoo-x86/dev-db/firebird/?hideattic=0
Ok found what's going on. For some reason on ~arch Firebird generates and installs shared objects to /opt/firebird/lib64 on 64bit archs. However it seems stable is configuring the package for /opt/firebird/lib64 instead. Going to add a temp hack/fix for this. Quite interesting. Likely 2.0.1 will need that as well.
(In reply to comment #3) > nas ~ # ls -l /opt/firebird/lib/ > total 540 > lrwxrwxrwx 1 firebird firebird 16 May 13 12:54 libfbclient.so -> > libfbclient.so.1 > lrwxrwxrwx 1 firebird firebird 20 May 13 12:54 libfbclient.so.1 -> > libfbclient.so.1.5.4 > -r-xr-xr-x 1 firebird firebird 538360 May 13 12:54 libfbclient.so.1.5.4 > lrwxrwxrwx 1 root root 16 May 13 12:54 libgds.so -> > ./libfbclient.so > lrwxrwxrwx 1 root root 16 May 13 12:54 libgds.so.0 -> > ./libfbclient.so > -r-xr-xr-x 1 firebird firebird 4608 May 13 12:54 libib_util.so > nas ~ # ls -l /usr/lib64/libfbclient.so* lrwxrwxrwx 1 root root 38 mai 16 03:59 /usr/lib64/libfbclient.so -> ../..//opt/firebird/lib/libfbclient.so lrwxrwxrwx 1 root root 25 mai 16 04:01 /usr/lib64/libfbclient.so.1 -> /usr/lib64/libfbclient.so what I created. > Not sure why those symlinks weren't created for you in your env? don't know > Are you running a 64bit arch? Yes, I forgot to tell it. > That part of the ebuild did not change from 1.5.3. Other than me introducing > ${my_lib} so the link will go in lib64 or lib depending on arch. Even though > lib is a link to lib64. It is : # ls -l /usr/lib lrwxrwxrwx 1 root root 5 mar 31 19:40 /usr/lib -> lib64 > Actually having reviewed past 1.5.3 ebuilds, they never put links in /usr/lib? with 1.5.3 I never had problem. All symlinks where fine. > Looks to be first used in 1.5.4? ?
(In reply to comment #4) > However it seems stable is configuring the package for /opt/firebird/lib64 > instead. ok. > Going to add a temp hack/fix for this. Quite interesting. Likely 2.0.1 will > need that as well. Fine. thanks.
(In reply to comment #5) > > It is : > # ls -l /usr/lib > lrwxrwxrwx 1 root root 5 mar 31 19:40 /usr/lib -> lib64 No I mean this wlt@wlt ~/gentoo/gentoo-x86/dev-db/firebird $ ls -l /opt/firebird/lib lrwxrwxrwx 1 firebird firebird 7 May 13 22:46 /opt/firebird/lib -> ./lib64 On ~arch Firebird spits out /opt/firebird/lib64/*so, but for some reason on stable or arch, it's spitting out /opt/firebird/lib/*so. In 2.0.1 I make a symlink in /opt/firebird from lib -> lib64, seems I need to do that as well as move the dir so both ~arch layouts and arch are the same :( > > Actually having reviewed past 1.5.3 ebuilds, they never put links in /usr/lib? > > with 1.5.3 I never had problem. All symlinks where fine. Yeah, but did you look at the ones in CVS? They lacked any links in /usr/lib other than libgds.so. Maybe that was enough and it needed either libgds.so or libfbclient.so in /usr/lib.
Ok just committed -r3 to portage. I will likely seek rush stabilization again since current stable version is broken. Much less older versions with upstream bugs, security issues, and etc have been removed. Give it a bit of time, 3-4 hours and sync your tree. Or pull file from cvs, digest locally and emerge. Should resolve the problem, and if it does please let me know so I can close bug. Thanks for the report, and sorry for the problems.
Tried, seems ok, except bad symlink : >>> /usr/lib64/libib_util.so -> ../../opt/firebird/lib/libib_util.so /opt/firebird/lib/libib_util.so doesn't exist. only /opt/firebird/lib64/libib_util.so
In /opt/firebird lib should be a symbolic link to lib64. That seems not to be the case in your scenario. wlt@wlt ~ $ ls -l /opt/firebird total 452 drwxr-xr-x 2 firebird firebird 4096 May 13 22:46 UDF lrwxrwxrwx 1 firebird firebird 26 May 13 22:46 aliases.conf -> /etc/firebird/aliases.conf drwxr-xr-x 2 firebird firebird 4096 May 13 22:46 bin -rw-r--r-- 1 firebird firebird 138484 May 13 22:46 de_DE.msg lrwxrwxrwx 1 firebird firebird 27 May 13 22:46 firebird.conf -> /etc/firebird/firebird.conf lrwxrwxrwx 1 firebird firebird 30 May 13 22:46 firebird.log -> /var/log/firebird/firebird.log -rw-r--r-- 1 firebird firebird 127696 May 13 22:46 firebird.msg -rw-r--r-- 1 firebird firebird 139044 May 13 22:46 fr_FR.msg drwxr-xr-x 2 firebird firebird 4096 May 13 22:46 help drwxr-xr-x 2 firebird firebird 4096 May 13 22:46 include drwxr-xr-x 2 firebird firebird 4096 May 13 22:46 intl lrwxrwxrwx 1 firebird firebird 7 May 13 22:46 lib -> ./lib64 drwxr-xr-x 2 firebird firebird 4096 May 13 22:46 lib64 lrwxrwxrwx 1 firebird firebird 27 May 13 22:46 security2.fdb -> /etc/firebird/security2.fdb This symlink is not created by the ebuild? /usr/lib64/libib_util.so -> ../../opt/firebird/lib/libib_util.so But on a 64bit system if /opt/firebird/lib -> ./lib64 then the link should not be broken if it exists.
*** Bug 178747 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > In /opt/firebird lib should be a symbolic link to lib64. That seems not to be > the case in your scenario. It is not. > > wlt@wlt ~ $ ls -l /opt/firebird # ls -l /opt/firebird/ total 688 lrwxrwxrwx 1 root root 31 mai 16 22:18 aliases.conf -> ../../etc/firebird/aliases.conf drwxrwxr-x+ 3 corida users 4096 mai 3 23:13 bases drwxr-xr-x+ 2 firebird firebird 4096 mai 16 22:18 bin -rw-r--r-x 1 firebird firebird 145272 mai 16 22:18 de_DE.msg lrwxrwxrwx 1 root root 32 mai 16 22:18 firebird.conf -> ../../etc/firebird/firebird.conf lrwxrwxrwx 1 root root 21 avr 1 17:28 firebird.log -> /var/log/firebird.log -rw-r--r-x 1 firebird firebird 132796 mai 16 22:18 firebird.msg -rw-r--r-x 1 firebird firebird 144216 mai 16 22:18 fr_FR.msg drwxr-xr-x 2 firebird firebird 4096 mai 16 22:18 help drwxr-xr-x 2 firebird firebird 4096 mai 16 22:18 include drwxr-xr-x 2 firebird firebird 4096 mai 16 22:18 intl -rw-rw-rw- 1 firebird firebird 0 avr 24 04:24 isc_guard1.opline -rw-rw-rw- 1 firebird firebird 0 avr 24 04:24 isc_init1.opline -rw-rw-rw- 1 firebird firebird 262144 mai 1 18:11 isc_lock1.opline -rw-r--r-x 1 firebird firebird 135656 mai 16 22:18 ja_JP.msg drwxr-xr-x 2 firebird firebird 4096 mai 16 22:18 lib drwxr-xr-x 2 root root 4096 mai 16 22:18 lib64 drwxr-xr-x 2 firebird firebird 4096 mai 16 22:18 run lrwxrwxrwx 1 root root 31 mai 16 22:18 security.fdb -> ../../etc/firebird/security.fdb -rw-r----- 1 corida users 45525 avr 24 20:57 test_create.sql drwxr-xr-x 2 firebird firebird 4096 mai 16 22:18 UDF > This symlink is not created by the ebuild? > /usr/lib64/libib_util.so -> ../../opt/firebird/lib/libib_util.so Yes it is, but /opt/firebird/lib/libib_util.so doesn't exist ! only /opt/firebird/lib64/libib_util.so does exist. (already said that) > But on a 64bit system if /opt/firebird/lib -> ./lib64 then the link should not > be broken if it exists. May be, but my first install was dev-db/firebird-1.5.3-r1, and I just upgraded to dev-db/firebird-1.5.4-r2 (then now dev-db/firebird-1.5.4-r3) and this symlink was never created.
And there is files in both lib64 AND lib : # ls -l /opt/firebird/lib* /opt/firebird/lib: total 1404 -rwxr----- 1 root root 134728 avr 4 23:02 ld-2.5.so -rwxr----- 1 root root 1293776 avr 4 23:02 libc-2.5.so lrwxrwxrwx 1 root root 11 avr 4 23:00 libc.so.6 -> libc-2.5.so /opt/firebird/lib64: total 508 lrwxrwxrwx 1 firebird firebird 16 mai 16 22:18 libfbclient.so -> libfbclient.so.1 lrwxrwxrwx 1 firebird firebird 20 mai 16 22:18 libfbclient.so.1 -> libfbclient.so.1.5.4 -r-xr-xr-x 1 firebird firebird 506584 mai 16 22:18 libfbclient.so.1.5.4 lrwxrwxrwx 1 root root 16 mai 16 22:18 libgds.so -> ./libfbclient.so lrwxrwxrwx 1 root root 16 mai 16 22:18 libgds.so.0 -> ./libfbclient.so -r-xr-xr-x 1 firebird firebird 4576 mai 16 22:18 libib_util.so
(In reply to comment #12) > drwxr-xr-x 2 root root 4096 mai 16 22:18 lib64 That's interesting ownership wise. > May be, but my first install was dev-db/firebird-1.5.3-r1, and I just upgraded > to dev-db/firebird-1.5.4-r2 (then now dev-db/firebird-1.5.4-r3) and this > symlink was never created. Only -r3 is good, -r2 had the symlink, but it would fail or etc, since lib existed as a dir. I added a hack to test for /opt/firebird/lib on 64bit systems, and to move that to lib64, so the symlink lib -> lib64 is created. (In reply to comment #13) > And there is files in both lib64 AND lib : > # ls -l /opt/firebird/lib* > /opt/firebird/lib: > total 1404 > -rwxr----- 1 root root 134728 avr 4 23:02 ld-2.5.so > -rwxr----- 1 root root 1293776 avr 4 23:02 libc-2.5.so > lrwxrwxrwx 1 root root 11 avr 4 23:00 libc.so.6 -> libc-2.5.so Those are stray files, left over by a -bin version of Firebird, possibly. Or maybe some other way old version of Firebird. Those need to be removed, and because they are there, the /opt/firebird/lib dir is not being removed by portage. Thus the symlink fails to get created. I guess I need to add a || die function to the symlink so it's creation will fail, and the merge. Run equery belongs /opt/firebird/lib/ld-2.5.so And you can repeat for the other files in that lib dir. You will most likely need to manually delete that dir and files. Even removing Firebird altogether and re-emerging will likely fail. Doubt you will find they belong to a package but would be interesting if they did. > /opt/firebird/lib64: > total 508 > lrwxrwxrwx 1 firebird firebird 16 mai 16 22:18 libfbclient.so -> > libfbclient.so.1 > lrwxrwxrwx 1 firebird firebird 20 mai 16 22:18 libfbclient.so.1 -> > libfbclient.so.1.5.4 > -r-xr-xr-x 1 firebird firebird 506584 mai 16 22:18 libfbclient.so.1.5.4 > lrwxrwxrwx 1 root root 16 mai 16 22:18 libgds.so -> > ./libfbclient.so > lrwxrwxrwx 1 root root 16 mai 16 22:18 libgds.so.0 -> > ./libfbclient.so > -r-xr-xr-x 1 firebird firebird 4576 mai 16 22:18 libib_util.so That is correct, and how it should be. And if those other files did not exist, and /opt/firebird/lib as a stray directory. Then portage would remove it, and would replace with a symlink. Local issue more than likely. Now I would like to know if we need to have a symlink to /opt/firebird/lib/libib_util.so in /usr/lib ? Again I could not find that either in past ebuilds, thus is not in current. But I can add. Run equery against that symlink as well in your /usr/lib, to see if it belongs to an ebuild or not. FYI, if you don't have it, equery is part of gentoolkit.
(In reply to comment #14) > (In reply to comment #12) > > > drwxr-xr-x 2 root root 4096 mai 16 22:18 lib64 > > That's interesting ownership wise. I don't think I created it myself... Should be firebird:firebird ? > Those are stray files, left over by a -bin version of Firebird, possibly. No, sorry, shame on me, they were needed for a try to have a ssh chrooted. I deleted all /opt/firebird/lib, re-emerged firebird, and now, the symlink is created. Really sorry.
No problem I did discover an oddity between ~amd64 and amd64 builds wrt to /opt/firebird/lib64 and lib. Have a hack fix in place. But otherwise glad we found out what was going on there :) Going to close bug now.
Fine. Couldn't you have a look to #175905 please ?
