Anjuta Emerge + Error

Message

Midnight Dream · Post by **Midnight Dream** » Fri Oct 14, 2005 11:14 pm

Ok, so my friend just recently converted over to Gentoo, and we are trying to get Anjuta. Only thing is, on a emerge anjuta, Here is the compile we attempted.

Code: Select all

Madangren matt # emerge anjuta
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-util/anjuta-1.2.4 to /
>>> md5 files   ;-) anjuta-1.2.2-r1.ebuild
>>> md5 files   ;-) anjuta-1.2.2.ebuild
>>> md5 files   ;-) anjuta-1.2.4.ebuild
>>> md5 files   ;-) files/xim_patch.patch
>>> md5 files   ;-) files/digest-anjuta-1.2.2
>>> md5 files   ;-) files/digest-anjuta-1.2.4
>>> md5 files   ;-) files/anjuta-1.2.2-64bit.patch
>>> md5 files   ;-) files/digest-anjuta-1.2.2-r1
>>> md5 src_uri ;-) anjuta-1.2.4.tar.gz
>>> Unpacking source...
>>> Unpacking anjuta-1.2.4.tar.gz to /var/tmp/portage/anjuta-1.2.4/work
configure.in:48: warning: underquoted definition of CHECK_HEADER_DEFINE
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:254: warning: underquoted definition of CHECK_HEADER_DEFINE
configure.in:427: warning: underquoted definition of CHECK_PROTO
/usr/share/aclocal/wxwin.m4:36: warning: underquoted definition of AM_OPTIONS_WXCONFIG
/usr/share/aclocal/wxwin.m4:59: warning: underquoted definition of AM_PATH_WXCONFIG
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO
global-tags/Makefile.am:16: `LDFLAGS' is a user variable, you should not override it;
global-tags/Makefile.am:16: use `AM_LDFLAGS' instead.
>>> Source unpacked.
 * Running elibtoolize in: anjuta-1.2.4
 *   Applying portage-1.5.10.patch ...
 *   Applying sed-1.5.6.patch ...
 * econf: updating anjuta-1.2.4/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating anjuta-1.2.4/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --build=i686-pc-linux-gnu --disable-gtk-doc
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for perl... /usr/bin/perl
checking for XML::Parser... ok
checking for iconv... /usr/bin/iconv
checking for msgfmt... /usr/bin/msgfmt
checking for msgmerge... /usr/bin/msgmerge
checking for xgettext... /usr/bin/xgettext
checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-linux-gnu-gcc accepts -g... yes
checking for i686-pc-linux-gnu-gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of i686-pc-linux-gnu-gcc... gcc3
checking how to run the C preprocessor... i686-pc-linux-gnu-gcc -E
checking for i686-pc-linux-gnu-g++... i686-pc-linux-gnu-g++
checking whether we are using the GNU C++ compiler... yes
checking whether i686-pc-linux-gnu-g++ accepts -g... yes
checking dependency style of i686-pc-linux-gnu-g++... gcc3
checking for library containing strerror... none required
checking for egrep... grep -E
checking for ANSI C header files... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for ld used by i686-pc-linux-gnu-gcc... /usr/i686-pc-linux-gnu/bin/ld
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/i686-pc-linux-gnu-nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... i686-pc-linux-gnu-g++ -E
checking for i686-pc-linux-gnu-g77... i686-pc-linux-gnu-g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether i686-pc-linux-gnu-g77 accepts -g... yes
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/i686-pc-linux-gnu-nm -B output from i686-pc-linux-gnu-gcc object... ok
checking for objdir... .libs
checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar
checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib
checking for i686-pc-linux-gnu-strip... i686-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

if appropriate, please contact the maintainer of this
package (or your distribution) for help.


!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/anjuta-1.2.4/work/anjuta-1.2.4/config.log

!!! ERROR: dev-util/anjuta-1.2.4 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.

And when trying to run libtoolize -c -f, we get

Code: Select all

Madangren matt # libtoolize -c -f
libtoolize: `configure.ac' does not exist
Try `libtoolize --help' for more information.

Any thoughts?

ChrisWhite · Post by **ChrisWhite** » Sat Oct 15, 2005 12:35 am

http://bugs.gentoo.org/show_bug.cgi?id=108674

This is a known issue, how long it's going to take to resolve it is what I'm not certain on. You can always email the assigned contact on the bug to get that information. A patch is provided there to help you out with it.

hkn · Post by **hkn** » Tue Nov 01, 2005 8:44 pm

Could you explain this patch?i dont know where patched it in system.

Code: Select all

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

hkn · Post by **hkn** » Wed Nov 02, 2005 5:12 pm

hkn wrote:Could you explain this patch?i dont know where patched it in system.

Code: Select all

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

i solved my problem.i'll explain that step by step.
#nano /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild
//add line 44--->
//...
autoreconf
libtoolize --copy --force || die
}
pkg-postinst(){
//...
#ebuild /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild digest
#emerge -v anjuta

http://bugs.gentoo.org/show_bug.cgi?id=108674
thanks guys

ercxy · Post by **ercxy** » Thu Nov 03, 2005 5:46 pm

OK.
why is this put into stable branch? if it doesn't even compile...

Phk · Post by **Phk** » Fri Nov 04, 2005 1:07 am

hkn wrote:
hkn wrote:Could you explain this patch?i dont know where patched it in system.
Code: Select all
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
i solved my problem.i'll explain that step by step.
#nano /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild
//add line 44--->
//...
autoreconf
libtoolize --copy --force || die
}
pkg-postinst(){
//...
#ebuild /usr/portage/dev-util/anjuta/anjuta-1.2.4.ebuild digest
#emerge -v anjuta

http://bugs.gentoo.org/show_bug.cgi?id=108674
thanks guys

Excellent... Clap clap clap...

But still i just can't understand why this modification works.....
Could you explain it to me?

If "libtoolize --copy --force" gives an error when run, why tha hell does it run when it's in an ebuild? Has it got something to do with the || die?

Well anyway, thanks man

Cheers,
Phk

ecatmur · Post by **ecatmur** » Fri Nov 04, 2005 2:49 am

When it's in the ebuild, it's being run from within the build directory. You tried to run it from your home directory.

Phk · Post by **Phk** » Fri Nov 04, 2005 1:01 pm

and why the "|| die" ? "or die" ?

ecatmur · Post by **ecatmur** » Fri Nov 04, 2005 2:21 pm

Exactly. The idea is that || is a short-circuiting Boolean operator, so the second command is only run if the first command fails. It's also used in C, Python, and pretty much every grown-up programming language out there (Visual Basic doesn't have short-circuiting Boolean operators, for example, although VB.Net does).

Phk · Post by **Phk** » Fri Nov 04, 2005 3:15 pm

ecatmur wrote:Exactly. The idea is that || is a short-circuiting Boolean operator, so the second command is only run if the first command fails. It's also used in C, Python, and pretty much every grown-up programming language out there (Visual Basic doesn't have short-circuiting Boolean operators, for example, although VB.Net does).

Nice

Thanks for the explain!

by the way, does "die" mean "return 1"? (like "end with error")

Thanks

hkn · Post by **hkn** » Fri Nov 04, 2005 11:29 pm

ecatmur wrote:When it's in the ebuild, it's being run from within the build directory. You tried to run it from your home directory.

you are right.i tried to emerging anjuta in my home directory.moreover i tried other location(/,/usr/,..)it fails.
But it works now(with [bug=]108674[/bug]).
thanks your attendence.i hope,new release libtool will be patched

Code: Select all

Madangren matt # libtoolize -c -f
libtoolize: `configure.ac' does not exist
Try `libtoolize --help' for more information

Phk · Post by **Phk** » Sat Nov 05, 2005 5:57 pm

hkn wrote:
ecatmur wrote:When it's in the ebuild, it's being run from within the build directory. You tried to run it from your home directory.
you are right.i tried to emerging anjuta in my home directory.moreover i tried other location(/,/usr/,..)it fails.
But it works now(with [bug=]108674[/bug]).
thanks your attendence.i hope,new release libtool will be patched
Code: Select all
Madangren matt # libtoolize -c -f
libtoolize: `configure.ac' does not exist
Try `libtoolize --help' for more information

This is a really stupid bug.. it's not common to see a bug like this

ecatmur · Post by **ecatmur** » Sun Nov 06, 2005 1:44 am

Phk wrote: by the way, does "die" mean "return 1"? (like "end with error")

Yep. die is defined in /usr/lib/portage/bin/ebuild.sh:

Code: Select all

alias die='diefunc "$FUNCNAME" "$LINENO" "$?"'
...
diefunc() {
        local funcname="$1" lineno="$2" exitcode="$3"
        shift 3
        echo >&2
        echo "!!! ERROR: $CATEGORY/$PF failed." >&2
        echo "!!! Function $funcname, Line $lineno, Exitcode $exitcode" >&2
        echo "!!! ${*:-(no error message)}" >&2
        echo "!!! If you need support, post the topmost build error, NOT this status message." >&2
        echo >&2
        if [ "${EBUILD_PHASE/depend}" == "${EBUILD_PHASE}" ]; then
                for x in $EBUILD_DEATH_HOOKS; do
                        ${x} "$@" >&2 1>&2
                done
        fi
        exit 1
}

So, 'die "message"' is expanded to 'diefunc "$FUNCNAME" "$LINENO" "$?" "message"' (look up alias in the bash documentation). FUNCNAME and LINENO are special Bash variables that do what you think they do, and $? holds the return value of the previous statement.
Then in diefunc all the usual error messages are printed, and then "exit 1" makes the ebuild exit; emerge then picks up the error value 1 and quits itself.

Phk · Post by **Phk** » Sun Nov 06, 2005 2:53 am

Ahh!! Now i'm fully enlightened!

Thanks man

U seem to know the Force pretty well...

hhehe, congrats!

rsala · Post by **rsala** » Sat Dec 10, 2005 1:34 pm

I too would like to hear the explanation to ercxy's question. What is the rational for marking anjuta stable if it doesn't build? Here it is a month later and the problem still persists. Not to mention the fact that a lot of us are rebuilding our entire machines as part of the compiler upgrade. The last thing I needed was for this stupid bug to kill my `emerge -e world.`

Btw, thanks for the fix. It worked great.

ecatmur · Post by **ecatmur** » Sat Dec 10, 2005 4:46 pm

The person to blame is Philip Walls <malverian@gentoo.org>; he marked it stable without sufficient testing. Email him if you want an explanation.

Phk · Post by **Phk** » Sun Dec 11, 2005 1:56 pm

ecatmur wrote:The person to blame is Philip Walls <malverian@gentoo.org>; he marked it stable without sufficient testing. Email him if you want an explanation.

Lololol: HELLO ***!

WTF IS THIS?

Lol, no problem man, everyone makes mistakes. Thank god there is ecatmur to release some little patches

rsala · Post by **rsala** » Sun Dec 11, 2005 3:04 pm

Yeah, beyond responding to the occasional post, I don't contribute anything to gentoo. So I'm not in a position to {b,f}lame anyone. I'm just surprised that such a simple fix has been sitting out there for so long.

... and regardless of whether an individual contributor dropped the ball, how can a source based distro expect to be taken seriously if they allow packages that don't even build to remain in their stable tree?