As of today (10/30/2006) I'm forced to rebuild xine-lib due to new -xmms flag and it failed due to following error: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../include -I../../src -I../../src/xine-engine -I../../src/xine-engine -I../../src/xine-utils -I../../src/input -I../../src/input -I../../lib -I../../lib -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNDEBUG -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -march=k8 -O2 -pipe -frename-registers -ffunction-sections -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute -Wstrict-aliasing=2 -c gdkpixbuf.c -fPIC -DPIC -o .libs/xineplug_decode_gdk_pixbuf_la-gdkpixbuf.o mkdir: cannot create directory `.libs': File exists x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../include -I../../src -I../../src/xine-engine -I../../src/xine-engine -I../../src/xine-utils -I../../src/input -I../../src/input -I../../lib -I../../lib -I/usr/include -march=k8 -O2 -pipe -fweb -ftracers -Wall -pthread -DNDEBUG -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -march=k8 -O2 -pipe -frename-registers -ffunction-sections -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute -Wstrict-aliasing=2 -c image.c -fPIC -DPIC -o .libs/xineplug_decode_image_la-image.o cc1: error: unrecognized command line option "-ftracers" make[3]: *** [xineplug_decode_image_la-image.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/var/tmp/portage/xine-lib-1.1.2-r2/work/xine-lib-1.1.2/src/libxinevdec' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/xine-lib-1.1.2-r2/work/xine-lib-1.1.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/xine-lib-1.1.2-r2/work/xine-lib-1.1.2' make: *** [all] Error 2 !!! ERROR: media-libs/xine-lib-1.1.2-r2 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile xine-lib-1.1.2-r2.ebuild, line 231: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. emerge --info Portage 2.1.1-r1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 x86_64) ================================================================= System uname: 2.6.17-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.5 Last Sync: Mon, 30 Oct 2006 19:00:02 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] 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-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -fweb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /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/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe -fweb" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache distcc distlocks metadata-transfer sandbox sfperms strict userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en it" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X a52 aac alsa arts audiofile avi berkdb bitmap-fonts bluetooth bzip2 cairo cli cracklib crypt cscope cups dlloader dri dvd dvdr elibc_glibc encode esd fam flac fortran gdbm gif gpm gtk gtk2 iconv imagemagick imlib input_devices_keyboard input_devices_mouse input_devices_vmmouse isdnlog jpeg kde kernel_linux libg++ linguas_en linguas_it mad matroska mbox mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre pdf perl png ppds pppd python qt3 qt4 readline reflection samba sdl session spell spl ssl subversion svg tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_nv video_cards_nvidia video_cards_vesa video_cards_vga video_cards_vmware vorbis xine xorg xpm xprint xscreensaver xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY btw, i tried (as suggested in the forums) also without -fweb (CFLAGS) and distcc (FEATURES) the main thing is that there is a -ftracers switch that is not set in /etc/make.conf and i dont know where else it might be set. Last time i emerged xine-lib (oct 8th) there was no problem, so... what happened? thanks
There's not a single mention of ftracers in the source code or patches. Post the output of 'grep -Rni ftracers /etc/portage'
I forgot to add: i already grep'd for ftracers in /etc and there is no 'trace' (excuse the pun :)) of it, while it is present in all Makefile of /var/tmp/portage/xine-lib-1.1.2-r2 Sandstorm:~# grep -Rni ftracers /etc/portage Sandstorm:~# grep -Rni ftracers /var/tmp/portage/ /var/tmp/portage/xine-lib-1.1.2-r2/work/xine-lib-1.1.2/include/Makefile:416:WAND_CFLAGS = -march=k8 -O2 -pipe -fweb -ftracers -Wall -pthread ... etc.
Since no news so far i'll add an extra bit of info i found: the only place i have -ftracers is in the WAND_CFLAGS Sandstorm:/var/tmp/portage/xine-lib-1.1.2-r2/work/xine-lib-1.1.2# grep tracers * Makefile:WAND_CFLAGS = -march=k8 -O2 -pipe -fweb -ftracers -Wall -pthread config.log:WAND_CFLAGS='-march=k8 -O2 -pipe -fweb -ftracers -Wall -pthread' config.status:s,@WAND_CFLAGS@,|#_!!_#|-march=k8 -O2 -pipe -fweb -ftracers -Wall -pthread,g this seems to belong to /usr/bin/Wand-config that is part of ImageMagick-6.2.9.5 and if i type Wand-config --cflags the result is: Sandstorm:/var/tmp/portage/xine-lib-1.1.2-r2/work/xine-lib-1.1.2# Wand-config --cflags -march=k8 -O2 -pipe -fweb -ftracers -Wall -pthread what gives? i am really puzzled
ok, i got it solved deleting imagemagick use flag from xine-lib, but still dont know why Wand-config should set the wrong CFLAGS, you might want to investigate now you should be able to reproduce the bug.
Thanks for investigating the issue.
WAND_CFLAGS injects the CFLAGS used during compile. You probably used "-ftracers" on your imagemagick build. Anyway, to work around this same issue, xine-lib-1.1.3_pre20061112 uses pkg-config to find imagemagick.
I have a little more info to share, i eventually figured that ImageMagick was giving trouble and fixed it by hand (thanks anyway Diego :-) ). Then I tried to re-emerge imagemagick but still faced problems with -ftracers. There were many places that were sharing this '-ftracers' most notably a few /usr/bin/*-config scripts: changing those and re-emerging perl as well did the trick and I managed to upgrade ImageMagick as well. Hope this helps.
I'm closing this bug as it looks like a local issue and it works for the reporter now.
No, it's not a local issue. The compile failure was a local issue, the bug here is not local. The bug is that Wand-config reports the CFLAGS used for building imagemagick as the CFLAGS to use to build anything else using ImageMagick. This is wrong. Wand-config should only reports those flags (-I*, -pthread, -L*, -l*) that are used to build against ImageMagick, not the CFLAGS used to build it. Similar issues happens/happened with MySQL; these are bugs, not local issue. The effects of these bugs are different: - code that shouldn't be built with optimisations will be built with optimisations; - code that shouldn't be built with debug info will be built with debug info; - if the CFLAGS used for building ImageMagick were wrong, it will break anything that uses Wand-config. The original report was for the third case, which is a local issue; but the bug remains and should be fixed.
(In reply to comment #8) > I'm closing this bug as it looks like a local issue and it works for the > reporter now. > Still an issue with 6.3.3. too: betelgeuse@pena /usr/portage/media-gfx $ Wand-config --cflags -O2 -march=nocona -pipe -fomit-frame-pointer -Wall -W -pthread betelgeuse@pena /usr/portage/media-gfx $ Wand-config --ldflags -L/usr/lib -Wl,--as-needed -lfreetype -lz Should not have my CFLAGS and LDFLAGS here.
Still same crap with 6.3.5.10; has anyone reported this upstream yet?
(In reply to comment #11) > Still same crap with 6.3.5.10; has anyone reported this upstream yet? http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=10379 should be fixed in media-gfx/imagemagick-6.3.7.9
