When I try to run Eterm, I get the result: Eterm: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory I suspect the problem to occur in one of the dependancies of Eterm, but I'm unable to determine what package is the actual source of the problem. So I report the problem here in hope that we can redirect the question to the apropriate ebuild maintainers. This is of course easily fixed by emerging the library in question, namely dev-libs/libpcre. Reproducible: Always Steps to Reproduce: Clean out dev-libs/libpcre Actual Results: Eterm: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory I suspect my USE flag settings play some crucial role in this. USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg kde libg++ mad mikmod mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib directfb alsa berkdb slang readline arts aalib nas svga tcltk java ruby mysql postgres X sdl tcpd pam libwww ssl perl python esd imlib oggvorbis gtk qt motif opengl mozilla 3ds acl acpi acpi4linux amd apache2 bots canna curl dedicated dga dnd doc dvd emacs evo exiscan exiscan-acl faad flash foreign-package freewnn gb gd ginac gmtfull gmthigh gmtsuppl gmttria gtk2 ipv6 jikes ladcca lcms leim libgda maildir matroska md5sum moznocompose moznoirc moznomail mpi mule music odbc offensive parse-clocks samba slp sse tiff wxwindows Xaw3d xinerama xml -gpm -gnome -gdbm"
libast links against libpcre and thus eterm links against libpcre ... but this only happens if you have libpcre on your system ... you must have had libpcre on your system at some point, emerge libast/eterm, then later unmerged libpcre ...
So what you're saying is that this problem should be adressed by the people in charge x11-libs/libast? I looked up the metadata.xml file. And ther maintainer there is also you. Shouldn't x11-libs/libast have a dependency to dev-libs/libpcre then?
what i'm saying is you had libpcre on your system, then you emerge libast/eterm, then you removed libpcre, and BAM eterm stopped working thus the 'bug' is user generated and cant really be accounted for
I'm a little afraid of being to quarrelsome, so you just say so if you find this discussion unrewarding. It's after all a minor bug, that we both know how to workaround. I'm in no way denying that I removed libcre, but that's because I was running depclean. Now, it's my opinion that also depclean should work fine within the system, so something is wrong when it's broken. (Of course I ran it at my own peril after receiving so explisit warnings, but still it's intended to work.) Basically what you are saying is that 'libast' finds 'libcre' on the system during it's configure run, and thereby decides to link with it? If this is the case, a run time dependecy has been created from within the build, this dependency is of course not static, but rather what I would call a "dynamic dependency". I would say that it's a valid claim that some form of dependency is created upon this occurence. I suspect your response to this would be something along the lines of: This is a sort of dependency, that isn't supported by portage. So basically what we are dealing with is a design flaw (not a bug) in the portage system? - And some kind of field like a "post build dependancy" should have been created. Do you agree? I'm sorry for putting words in your mouth, just trying to speed up the discussion a little bit ;)
you never mentioned that you ran depclean :) to me, it sounded like you ran `emerge unmerge libpcre` and then filed a bug when things broke ... i added libpcre as an optional DEPEND to libast so in the future, depclean shouldnt try to remove it on you
fixz0red
Hmm, had I run 'emerge unmerge libpcre' and filed a bug, I should have my head decapitated ;) It's not the first time I've neglected to tell things, and caused misunderstandings, sorry for that. Anyway, I was on a little run to verify all my former bugs, and I couldn't see that the fix was applied.
weird, the file was still sitting in my CVS but never had been committed ... sorry about that
Well then it seems like depclean no longer opts to remove libinc. I'm happy :) Closing this bug now.
