Trying to compile anjuta-1.2.4 checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib checking for x86_64-pc-linux-gnu-strip... x86_64-pc-linux-gnu-strip checking for correct ltmain.sh version... no *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.20, ltmain.sh = 1.5.18) *** Please run: libtoolize --copy --force # libtool --version ltmain.sh (GNU libtool) 1.5.20 (1.1220.2.287 2005/08/31 18:54:15) Reproducible: Always Steps to Reproduce:
Created attachment 70258 [details, diff] libtool fix Run libtoolsize --force --copy after antoreconf as per http://article.gmane.org/gmane.linux.gentoo.devel/23449/match=gentoo+libtoolize
ooh, aah Glenn McGrath. Didn't know you were a Gentoo user :) Attached patch fixed the problem for me. Thanks.
Im not the cricketer, i do get a few of those comments.
(In reply to comment #2) > ooh, aah Glenn McGrath. Didn't know you were a Gentoo user :) Attached patch > fixed the problem for me. Thanks. Hi :) How did you attach the patch? I tried to alter the anjuta ebuild file manualy, but all I got was an error regarding a filesize missmatch of the ebuild file. Regards, Lars
ebuild /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild digest would fix the file size complaint but it is a temp fix, next emerge will kill it. So either put it in your local portage tree or hope they add it to the normal tree. Side note to anyone watching, elibtoolize ebuild function I think should have fixed this instead of calling libtoolize --copy --force directly
Thanks a lot, Lars
How can this bug be fixed if it is not yet in the portage. In other word, will we see a version 1.2.4.1 or 1.2.5?
I fixed the bug by changing autoreconf with autoreconf --install --force in ebuild Is it correct or better to libtoolize --install --force?
*** Bug 112350 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Created an attachment (id=70258) [edit] > libtool fix > > Run libtoolsize --force --copy after antoreconf as per > http://article.gmane.org/gmane.linux.gentoo.devel/23449/match=gentoo+libtoolize > I tried doing exactly as you said, and I still get the same results. When I go back into the ebuild file where I added the line above, it is missing (after running emerge)? Im really not sure if Im doing this right, but it appears to not be a fix?
how would a user apply this patch in order to compile anjuta? I have read the threads and I understand what the problem is, yet I am vague on how to actually use the fixes provided... Thank you.
After you modify the anjuta ebuild file type 'emerge anjuta' When you run 'emerge sync' the changes you made are lost.
(In reply to comment #12) > After you modify the anjuta ebuild file type 'emerge anjuta' > > When you run 'emerge sync' the changes you made are lost. I didnt run 'emerge sync' I did exactly as you said. I modified the file, then typed 'emerge anjuta'. The only thing I could have done differently is if I modified the wrong file. I modified: /var/tmp/portage/anjuta-1.2.4/build-info/anjuta-1.2.4.ebuild however when after running 'emerge anjuta' the above file that I modified, looks like it did before I modified it. If Im modifying the wrong file pleas let me know.
Abydos-64 anjuta # patch anjuta-1.2.4.ebuild patch.p patching file anjuta-1.2.4.ebuild Hunk #1 FAILED at 44. Hunk #2 FAILED at 44. 2 out of 2 hunks FAILED -- saving rejects to file anjuta-1.2.4.ebuild.rej what did I do wrong?
ok, I got it, for those like me who did not understand right away here is the crystal clear step by step solution: edit /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild in a text editor find this section: sed -i -e "s:packageplugindir=lib:packageplugindir=$(get_libdir):" \ configure.in autoreconf add this line: libtoolize --copy --force || die making: @@ -44,6 +44,7 @@ sed -i -e "s:packageplugindir=lib:packageplugindir=$(get_libdir):" \ configure.in autoreconf libtoolize --copy --force || die then to make it work w/o an error type this: ebuild /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild digest then emerge anjuta
*** Bug 113475 has been marked as a duplicate of this bug. ***
I reply to comment #15: I would better use patch instead of an editor [patch target patchfile] and then ebuild /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild digest By the way: This patch seems to work for me as anjuta is compiling this moment.
I encountered the same problem re-emerging anjuta-1.2.4, while updating to GCC 3.4.4. The correction to the ebuild as suggested in comment #15 indeed makes anjuta emerge properly. Hopefully the ebuild can be updated by the maintainer. Hitting bugs that have been resolved some time ago is always annoying.
*** Bug 114779 has been marked as a duplicate of this bug. ***
How can this bug be open for 2 months? It has a patch and is actually a blocker for anjuta.
Its taken so long to fix this bug its been incorporated into the gtk fix in #115860, for patches to build anjuta go to http://bugs.gentoo.org/show_bug.cgi?id=115680
Thanks for the report and sorry for the delay. Fix commited to CVS.
