Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

When emerging netpbm I encounter the following error-message:

-----
In file included from mallocvar.h:13,
                 from shhopt.c:32:
/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/pm_config.h:2:1: unterminated
#ifndef
echo '#include <inttypes.h>' >>pm_config.h || (rm -f pm_config.h || false)
echo "#define HAVE_INT64 1" >>pm_config.h || (rm -f pm_config.h || false)
echo '/* pm_config.h.in FOLLOWS ... */' >>pm_config.h || (rm -f pm_config.h ||
false)
cat /var/tmp/portage/netpbm-10.31/work/netpbm-10.31/pm_config.in.h
>>pm_config.h || (rm -f pm_config.h || false)
/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/buildtools/endiangen
>>pm_config.h || (rm -f pm_config.h || false)
echo '#endif' >>pm_config.h || (rm -f pm_config.h || false)
make[2]: Leaving directory `/var/tmp/portage/netpbm-10.31/work/netpbm-10.31'
make -C util/ -f
/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/lib/util/Makefile \
        SRCDIR=/var/tmp/portage/netpbm-10.31/work/netpbm-10.31
BUILDDIR=/var/tmp/portage/netpbm-10.31/work/netpbm-10.31 nstring.o
make[2]: Entering directory
`/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/lib/util'
i686-pc-linux-gnu-gcc -c -I /var/tmp/portage/netpbm-10.31/work/netpbm-10.31 -O2
-march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -ftracer -pipe -Wall
-fPIC   -o nstring.o nstring.c
shhopt.c: In function `parse_long_option':
shhopt.c:697: warning: 'arg' might be used uninitialized in this function
make[2]: *** [shhopt.o] Error 1
make[2]: Leaving directory
`/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/lib/util'
make[1]: *** [util/shhopt.o] Error 2
make[1]: *** Waiting for unfinished jobs....
nstring.c: In function `asnprintfN':
nstring.c:950: warning: 'str' might be used uninitialized in this function
nstring.c: In function `vasnprintfN':
nstring.c:977: warning: 'str' might be used uninitialized in this function
make[2]: Leaving directory
`/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/lib/util'
make[1]: Leaving directory
`/var/tmp/portage/netpbm-10.31/work/netpbm-10.31/lib'
make: *** [lib/all] Error 2

!!! ERROR: media-libs/netpbm-10.31 failed.
!!! Function src_compile, Line 558, Exitcode 2
!!! emake failed
!!! If you need support, post the topmost build error, NOT this status message.

-----
My make info:
-----
System uname: 2.6.14-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz
Gentoo Base System version 1.12.0_pre12
ccache version 2.4 [disabled]
dev-lang/python:     2.3.5, 2.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -ftracer
-pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -ftracer
-pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X a52 aac acpi alsa apache2 apm arts audiofile bash-completion berkdb
bidi bitmap-fonts bootsplash browserplugin bzip2 cdda cdio cdparanoia cdr crypt
css cups curl custom-cflags dts dv dvd dvdr dvdread eds emoticon encode escreen
esd exif expat fam fame fb fbcon ffmpeg flac font-server foomaticdb fortran
freetype gdbm gif glut gnutls gpm gstreamer gtk gtk2 httpd idn imagemagick
imlib java jpeg lcms libg++ libwww live lm_sensors mad matroska mikmod mjpeg
mmx mmx2 mng motif mp3 mpeg mpeg4 mplayer mysql ncurses nls nptl nsplugin
nvidia ogg oggvorbis opengl oss pam pcre pdflib perl pic png ppds python qt
quicktime rar readline real sdl spell sse sse2 ssl stream subtitles subversion
svga tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb vcd
vcdimager vlm vorbis win32codecs wxwindows xine xml xml2 xmms xv xvid xvmc zlib
elibc_glibc kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS

emerge it with MAKEOPTS=-j1 to workaround the bug

Changing to MAKEOPTS=j1 indeed makes that emerge finishes. 
Thanks for the suggestion.

OK, commited to portage patch which should fix compile problems in parallel

patch didnt fix the issue, just made it less prevalent

netpbm-10.32 on amd64 displays the same behavior.

*** Bug 124380 has been marked as a duplicate of this bug. ***

Same error here for 10.32 ~x86. Couldn't -j1 opt be set directly into the
ebuild?

*** Bug 124396 has been marked as a duplicate of this bug. ***

*** Bug 124423 has been marked as a duplicate of this bug. ***

Same problem here, on ~x86. MAKEOPTS="-j1" fixed it. Also, just met 2 people on
IRC with same problem.

Should be in ebuild. IMO.

*** Bug 124437 has been marked as a duplicate of this bug. ***

*** Bug 124439 has been marked as a duplicate of this bug. ***

The issue still exists in 10.32, as others have recently posted.  Forcing a
non-parallel make, via MAKEOPTS, fixed it.  Please fix.

you seem to be confused

forcing MAKEOPTS to -j1 is not a fix, it's a hack

(In reply to comment #14)
> you seem to be confused
> 
> forcing MAKEOPTS to -j1 is not a fix, it's a hack
> 

Yes, ugly hack, but this I found in mplayer ebuild:

        # we run into problems if -jN > -j1
        # see #86245
        MAKEOPTS="${MAKEOPTS} -j1"

just because other devs utilize hacks doesnt mean it's correct ;)

Created an attachment (id=80978) [details]
netpbm-10.32-parallel.patch

This patch is not an adaptation of the netpbm-10.31-parallel.patch.
Instead I tried to track down the reason for the missing dep.
Main reason of course is some weird makefile design where makefiles from the
inner directories execute rules in the root dir as well.

The dependency on inttypes_netpbm.h resultet from importinc and comes from
Makefile.common which is included by different makefiles. The rule to provide
this file is only present in the toplevel GNUmakefile, so the other files have
trouble satisfying this rule. I went with the design of the rest of the files
and added a rule to call the root makefile to provide this file.

I think I also fixed a bug in the difference between BUILDDIR and SRCDIR, but
as those are the same on Gentoo builds I don't know for sure, nor do I
particularly care. I'ts included in the patch, wether it would work (better)
for different environments is for someone else to test.

So far I had one successful compile. I think I will try to compile it in a loop
several times, but I'd be happy if others would test this as well.

Created an attachment (id=80981) [details]
Patch to the netpbm-10.32.ebuild

This patches the ebuild to include attachment #80978 [details]. It also moves several
configuration things from src_unpack to src_compile where they belong IMHO.

And talking about hacks: I alway thought that the hack would usually be to
provide an argument to emake as in "emake -j1". Modifying MAKEOPTS seems even
worse than that. Hopefully we can do without a hack on this one soon.

Created an attachment (id=80995) [details]
netpbm-10.32-parallel.patch v2

I still got errors every now and then. Fixed one, got another one, and decided
this was no fun at all... :-(

Now I simply added a dep on importinc to the recursive calls for target all. So
importinc (which combines all the troublemakers so far) is called before any
serious compilation is done. This would be a problem if you were to compile
only the contents of a single directory in a virgin source tree, but who would
do this in parallel? For the whole tree, starting with the top level
GNUmakefile, the deps should hopefully be correct now. At least I got 20 clean
compiles in a row. :-)

In any case, perhaps autotooling the whole affair would be the best approach.
Unfortunately I've never worked with autotools so far, so someone else is
probably better in converting this whole thing.

Patch works for me too.

I suppose this is good enough for now, added patch to cvs. Thanks! Please push
it upstream.

Folks: please reopen this bug if it is still a problem.

*** Bug 124476 has been marked as a duplicate of this bug. ***