A recent 'emerge -u world' has removed gal-0.19 (libgal.so.19) from my system and upgraded it to gal-0.20 (libgal.so.20). gnucash and evolution fail to start since they cannot load libgal.so.19. It seems that gnucash and evolution need to depend on gal-0.19. You can work around this by creating a symbolic link from /usr/lib/libgal.so.19 to /usr/lib/libgal.so.20. This appears to work, but since I have no idea what libgal does and what the changes were, I don't know how horrible an idea this is. There are rumblings in the forums of other gnome applications failing as well.
foser, recently we made a fix for aspell (because apps compiled against aspell-0.50.1 had to be recompiled for aspell-0.50.2 etc), which nullifies this issue. it might apply in this case. basically: inherit libtool and in src_compile(): elibtoolize --reverse-deps
Well, the libgal-0.20 ebuild should make a libgal-0.19.so symlink of its own. So this case is covered in the ebuild, try re-emerging. Not sure why it didn't work right away for you. Can you find out where it goes wrong (if the problem persists).
I'm an ebuild novice, so bear with me. I think you are referring to these lines in the gal-0.20.ebuild: local fullname="$(realpath ${D}/usr/lib/libgal.so)" dosym ${fullname##*/} /usr/lib/libgal.so.$((${PV##*.}-1)) I think that this properly creates the libgal.so -> libgal.so.20.0.0 link. However, in the example case of gnucash, the program was built linking to libgal.so.19. The gnucash ebuild only requires >=gal-0.13-r1, so after gal-0.20 is installed, libgal.so.19 is cleaned/removed. Voila, you have a broken gnucash. After gnucash broke following my 'emerge -u world', I rebuilt gnucash. gnucash now attempts to load both libgal.so.19 _and_ libgal.so.20. Either gnucash should just link to libgal.so, or libgal.so.19 and libgal.so.20 should be added to its ebuild dependencies (in my somewhat uneducated opinion).
As i said, the 0.20 ebuild should create a 0.19 link to 0.20 (it does, the lines you mention should do that). If the 0.19 is removed and you rebuild, it just cannot link to 0.19 . But you shouldn't need to rebuild, cause the links should be there. gnucash can't be linked to the same lib twice. Why do you think it does that, how did you find out ?
I think that the link that is created is from libgal.so to libgal.so.20 (leaving libgal.so.19 linked to libgal.so.19.3 before it is removed). As for gnucash's linking: $ ldd /usr/bin/gnucash | grep gal libgal.so.20 => /usr/lib/libgal.so.20 (0x404f6000) libgal.so.19 => not found is what I'm seeing right now. I'm rebuilding gnucash right now to make sure I haven't lost my mind.
I'm not gonna say the same thing thrice. You made the libgal.so.19link yourself, did you remove it as well ?
Yes, I removed the link I created. And it _is_ possible to build gnucash linked to libgal.so.19 and libgal.so.20. After more investigation, libgtkhtml.so is linked to libgal.so.19: $ ldd /usr/lib/libgtkhtml.so | grep gal libgal.so.19 => not found When gnucash is rebuilt, some part of it is clearly linking to libgal.so.20, but libgtkhtml.so (and possibly others) is still linked to libgal.so.19. When all is said and done, gnucash is linked to both libgal.so.19 and libgal.so.20. A post in the forums says that re-emerging gtkhtml doesn't help, so I don't really know what's going on. No need to get snippy... This is a real problem I'm just trying to help solve.
Yup i know gtkhmtl is linked to it as wel. Clean out libgtkhtml, gnucash and gal. In that case there shouldn't be any 0.19 traces left.
Yes, re-emerging gtkhtml did the trick. Now gtkhtml and gnucash are rid of libgal.so.19, and everything works. I only have a vague understanding of portage, so I have no idea how this should be dealt with in the ebuilds. It seems that if gal is updated, gtkhtml should be rebuilt, but I don't see any way to specify that in portage. The only thing that I can see is locking gtkhtml to gal-0.19 so that when gal gets updated to gal-0.20, gal-0.19 sticks around for gtkhtml to use. And for people who want gtkhtml with gal-0.20, there can be a newer gtkhtml ebuild that uses gal-0.20. Again, this could be totally wrong, but I thought I'd throw it out there.
Your case is just a bit special. In most cases the link to libgal.so.19 does get made and people don't have to worry about rebuilding. I don't say its a clean way to do things, but it generally works. And binding gtkhtml to a specific version of libgal is imo not a good idea, cause it isn't dependant on this specific version : it works just as well with another version. I'll leave things as they are, can't think of anything better right now. I'm glad it worked out for you.
In an attempt to figure out what was happening with my symbolic link, I tried re-emerging 19, then 20. When I emerged 20, I noticed what I think is the root of all of my problems: /usr/sbin/ebuild.sh: realpath: command not found Where does realpath come from? The link is not made since the fullname is blank when dosym is called. There are at least a few people with the same problem: http://forums.gentoo.org/viewtopic.php?t=19674&highlight=libgal http://forums.gentoo.org/viewtopic.php?t=17286&highlight=libgal Whatever installs realpath should be added to the DEPEND (or else realpath shouldn't be used).
Turns out readline is only provided by blackdown-j{dk,re}. Making java a dep didn't sound like a good idea to me, so i added some python code that should do the same. The new version is masked as gal-0.20-r1 , please test if this fixes the problem. Good job on noticing it btw.
readline=realpath .. bleh where was i with my thoughts.
Got the s/readline/realpath thing :-). I emerged the gal-0.20-r1 ebuild, and it correctly created the link. Good work.
Thanks for your help :) Unmasking new gal revision and closing.
