Hi, When emerging dev-libs/lam-mpi (6.5.6), a sym link is pointing to something outside of DESTDIR. This causes the resulting installed link to be invalid. I posted this on the forum and they suggested using sed to fix the makefile in the src_unpack function of the ebuild. Here is the incorrect resulting link: /usr/include/mpi++.h -> /var/tmp/portage/lam-mpi 6.5.6/image//usr/include/mpi2c++/mpi++.h So I propose the following fix added to the src_unpack section of the ebuild: cd ${S}/mpi2c++/src/mpi2c++/ mv Makefile.in Makefile.in-orig sed -e "s|\$(LN_S) \$(pkgincludedir)/mpi++.h \ \$(DESTDIR)\$(includedir)/mpi++.h)|(cd \$(DESTDIR)\$(includedir); \ \$(LN_S) mpi2c++/mpi++.h mpi++.h));|" Makefile.in-orig >Makefile.in Also, a newer version of lam is available (6.5.7) which I made an ebuild for using the previous ebuild and adding the above lines. I'm not sure the correct way to go about submitting a newer ebuild. Please advise! thanks, chad
Hi Chad :) Thanks for a report! I tried your fix, unfortunately it did not make any difference on me here :(. Anyway, this type of problem is most easily fixed inside src_install(). I updated the ebuild, please test. I'll close the bug upon successful bug report. As for the new version: please submit the ebuild via bugzilla as described at: http://www.gentoo.org/doc/ebuild-submit.html If the new ebuild is just a renamed 6.5.6 one, then you can just submit the bug saying that you just renamed ebuild and it built and worked Ok. You can assign the bug directly to me. See you around ;). George
Hi George, Thanks for taking the time to talk with me last week. That was really useful for me. I do appreciate it. I tested your fix and it works fine. I just wasn't sure where to apply the fix. I guess as I mess with ebuilds more I will get the hang of it. =) Just a silly question- will the name change to 6.5.6-r1, or is this too small of a change for a revision change? The reason I ask is because I apply binary updates to my beowulf nodes using 'emerge --noreplace', and therefore they won't see it as a new package. Not a big deal at all, I can easily get around it, just curious and wanting to learn. thanks again! chad
Hi Chad. Thanks for testing, and bringing up the question of the revision number. Originally I considered the fix to be quite minor (considering that the only app I tested with this library, namely gromacs, seemed to build) and taking into account that in genereal we are trying to avoid unnecessary recompiles I just corrected the existion version. However, on a second thought I see, that the fix is more important and a general one (touching every install as opposed to just some specific situation) and thus really qualified for the -r1 revision (the main purpose of -rX upping is to force recompiles. Obviously this should be applied only when necessary). I made the necessary update, now your --update or --noreplace should pick it up. I will close the bug for now, if you will see any problems please reopen it. George
