Compiliation of dev-cpp/commoncpp2-1.5.7 fails with this error: /bin/sh ../libtool --tag=CXX --mode=link i686-pc-linux-gnu-g++ -I../src -DCCXX_EXPORT_LIBRARY -D_GNU_SOURCE -I../include -march=athlon-tbird -O2 -pipe -version-in fo 0:7 -release 1.5 -o libccext2.la -rpath /usr/lib numbers.lo zstream.lo socketport.lo url.lo xml.lo persist.lo engine.lo digest.lo cmdoptns.lo date.lo md5.lo unix .lo network.lo serial.lo urlstring.lo tokenizer.lo mime.lo ssl.lo -lrt -pthread ../src/libccgnu2.la -lz libtool: link: cannot find the library `../src/libccgnu2.la' or unhandled argument `../src/libccgnu2.la' make[1]: *** [libccext2.la] Error 1 make[1]: *** Waiting for unfinished jobs.... If I switch into $WORKDIR and repeat by hand "make" the linking will pass. I thing this is problem with parallel building (-j2). Reproducible: Always Steps to Reproduce: USE="gnutls ipv6" emerge =dev-cpp/commoncpp2-1.5.7 Portage 2.1.2.7 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r3 i686) ================================================================= System uname: 2.6.21-gentoo-r3 i686 AMD Duron(tm) processor Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 17 Jun 2007 16:20:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-tbird -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.fi.muni.cz/pub/linux/gentoo/" LANG="cs_CZ.UTF-8" LINGUAS="cs en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow a52 aac acl acpi alsa audiofile avi berkdb bitmap-fonts bzip2 caps cdparanoia cjk cli cracklib crypt cups dri esd ffmpeg flac fortran ftp gd gdbm gif gnutls gpm gtk gtk2 iconv icq idn imagemagick imap imlib ipv6 irc isdnlog jabber java javascript jpeg lcms libg++ live lm_sensors matroska mbox midi mikmod mime mmap mmx mng motif mp3 mpeg mudflap nas ncurses nls nodrm nptl nptlonly ogg openmp pam pcre pdf perl plotutils png posix ppds pppd python readline real recode reflection rss samba sasl sdl session sharedmem sndfile sockets speex spell spl ssl svg sysvipc tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts ucs2 ucs4 unicode usb vorbis win32codecs x86 xml xml2 xorg xosd xpm xsl xv xvid zlib" ALSA_CARDS="snd_via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="cs en" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 122364 [details, diff] commoncpp2-1.5.7-r1.ebuild Appends -j1 to emake in src_compile(). This fixes the problem. Tested on my system.
Confirming the problem, and that MAKEOPTS=-j1 fixes it. I didn't test the ebuild patch as I came to the conclusion it was a parallel make problem before going to file a bug and finding this one, but MAKEOPTS=-j1 definitely fixed it here. Duncan
I have MAKEOPTS="-j3" in /etc/make.conf since i'm using distcc, and linking failure occurs. I tried: MAKEOPTS=-j1 emerge -v dev-cpp/commoncpp2 and it works perfectly.
BTW, previous versions merged fine without -j restrictions that I ran into, anyway, so the problem appears to be new to this version. Perhaps whatever upstream (or the ebuild handling, I noticed autoreconf handling changed in the ebuild, but don't know enough about it to know if that would cause the issue or not) changed in the make files could be fixed so parallel compile jobs works once again? With multi-cores the path forward, it's definitely a shame to be creating more single-job compile restrictions, and given it worked before, this one should have been caught early enough that finding and fixing the issue shouldn't be difficult, if it's done before too many additional changes pile on. So if someone has the skills to fix it right, rather than just working around it with -j1, now would be the time to do it, and I'm sure Gentoo users at least will be thanking you for some time to come. =8^)
I made some tests and it seems that problem is introduced with 1.5.7-as-needed.patch patch. It links libccgnu2 to libccext2, but doesn't express this new dependency. During building ccgnu2 and ccext2 are built in parallel but ccext2 is smaller, its compiliation finishes sooner but in final step it requires ccgnu2 which has not build yet. The difference between 1.5.1-r1 and 1.5.7 is that @BASE_LIB@ is ../src/libccgnu2.la now and therefore it expands to nonempty linking argument. I have a questions: Whi is ccgnu2 linked to ccext2? Is it necessary? And if it is, how to express the dependency in src/Makefile.am? As I can now, the old library and the new one buid and run fine without explicit linking. My suggestion is to ommit following part from 1.5.7-as-needed.patch patch: diff -Naur commoncpp2-1.5.7.orig/configure.ac commoncpp2-1.5.7/configure.ac --- commoncpp2-1.5.7.orig/configure.ac 2007-06-16 15:23:05.000000000 +0200 +++ commoncpp2-1.5.7/configure.ac 2007-06-16 15:24:39.000000000 +0200 @@ -357,6 +357,9 @@ darwin*) MODULE_FLAGS="-dynamic -bundle -undefined suppress -flat_namespace -read_only_relocs suppress" ;; +linux*) + BASE_LIB="../src/libccgnu2.la" + ;; esac AC_SUBST(COMMON_FLAGS)
The problem is that applications which try to link ccext2 statically will fail with unresolved symbols even if they link in ccgnu2 as well. The solution I already have here is to add "libccext2_la_DEPENDENCY = libccgnu2.la" to src/Makefile.am as well which solves the parallel build problem. But then libtool re-links libccext2.la during installation, which isn't optimal.
Interresting. I compiled the package with ommited @BASE_LIB@, I took test/digest.cpp end do an excercise: $ g++ -c -o digest.o digest.cpp $ g++ -o digest-dynamic digest.o -lccext2 -lccgnu2 $ g++ -o digest-static digest.o --static -lccext2 $ file digest-* digest-dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped digest-static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, not stripped The only problem I found is pkg-config --static libcc{gnu,ext}2 that return nothing. OTOH, pkg-config --libs works well.
I had this same problem also on amd64. I emerged it with: MAKEOPTS="-j1" emerge commoncpp2 and everything compiled fine. Was this the proper thing to do for now, or will this mess something up? I tried reading through everyones posts here, but it was a little confusing to me.
(In reply to comment #8) > I had this same problem also on amd64. I emerged it with: > MAKEOPTS="-j1" emerge commoncpp2 > and everything compiled fine. Was this the proper thing to do for now, or will > this mess something up? > If you can afford to give parallel building up, then it will be the right fix for you. But it doesn't fix the reason. It fixes only symptoms. Especially users of compile farm will get angry :( > I tried reading through everyones posts here, but it was a little confusing to > me. > I'm sorry for my English. Tiziano (comment #6) said, he has problem to link static ccext2 to his application. Therefore he (and ebuild) links at first ccgnu2 to ccext2 (this is the difference to previous ebuild version) which solves his application linking problem. He doesn't express dependency in Makefile because libtool would try to relink the library. I tried reproduce his bug (create static ccext2 without ccgnu2 and the link it to application) without success. So it seems we have a bug introduced by a fix of another bug which I can't reproduce. I think Tiziano should provide more details.
It's not a problem with static linking, but with dynamic.
(In reply to comment #10) > It's not a problem with static linking, but with dynamic. > During emerge. And the problem is caused due to the as_needed patch. And the patch is used because of static linking to application after emerge: > The problem is that applications which try to link ccext2 statically will fail > with unresolved symbols even if they link in ccgnu2 as well. Or maybe I didn't catch the real problem. As I said omitting the problematic part of the patch makes parallel emerge possible and dynamic and then static linking library to application (i.e. after emerge) works for me too.
@Petr: Well, the as-needed problem is a problem of dynamic linking. The patch had a bug which is correct now (thanks to Flameeyes).
