Compiling of xine-lib-1.1.2_pre20060328-r5 fails with the following error: i686-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 -DXINE_COMPILE -fvisibility=hidden -DNDEBUG -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -DENABLE_IPV6 -march=pentium3 -O2 -pipe -frename-registers -ffunction-sections -c audio_none_out.c -fPIC -DPIC -o .libs/xineplug_ao_out_none_la-audio_none_out.o cc1: error: unrecognized option `-fvisibility=hidden' make[3]: *** [xineplug_ao_out_none_la-audio_none_out.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/xine-lib-1.1.2_pre20060328-r5/work/xine-lib-1.1.2cvs/src/audio_out' make[2]: *** [all-recursive] Error 1
emerge --info, please...
Portage 2.1_pre10-r2 (default-linux/x86/2006.0, gcc-3.3.6, glibc-2.3.6-r3, 2.6.16-gentoo-r4 i686) ================================================================= System uname: 2.6.16-gentoo-r4 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.14 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 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 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -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/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 16bit X a52 aac acpi alsa amarok apache2 asf avi berkdb bitmap-fonts bittorrent bl cairo cardbus cdparanoia cli commercial crypt css cups dga dillo dlloader dri dvb dvd dvdr dvdread dxr3 encode esd exif expat fam fits foomaticdb gdbm geoip gif gimp gimpprint gpm gstreamer gtk gtk2 h323 hal hbci imap imlib insecure-drivers ipv6 irda jabber java javascript jpeg jpeg2k kcal kde kdeenablefinal kexi kqemu libg++ libwww mad madwifi matroska mp3 mpeg mpeg2 mplayer mysql ncurses netbeans nls nptl nsplugin ntlm ogg ole opengl oss pam pcmcia pdf pdflib php png pnp ppds python qt quicktime readline real reflection samba scanner sdl session spell spl spreadsheet sql sse ssl svg theora thumbnail tidy tiff truetype truetype-fonts type1-fonts udev underscores unicode usb v4l vcd video_cards_savage vidix vorbis wifi win32codecs xine xinerama xml xorg xv xvmc yahoo zeo zlib zvbi elibc_glibc kernel_linux linguas_de userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS
http://www.gentoo.org/doc/en/gcc-upgrading.xml Your gcc version is outdated and unsupported.
*** Bug 132526 has been marked as a duplicate of this bug. ***
*** Bug 132542 has been marked as a duplicate of this bug. ***
*** Bug 132730 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > http://www.gentoo.org/doc/en/gcc-upgrading.xml > > Your gcc version is outdated and unsupported. > If gcc-3.3.6 is outdated and unsupported, why is it (along with gcc-3.3.5-r1 and gcc-3.3.5.20050130-r1) still unmasked in portage?
*** Bug 133216 has been marked as a duplicate of this bug. ***
*** Bug 134289 has been marked as a duplicate of this bug. ***
> > If gcc-3.3.6 is outdated and unsupported, why is it (along with gcc-3.3.5-r1 > and gcc-3.3.5.20050130-r1) still unmasked in portage? > 3.3.6 is no longer masked by ~x86. It is stable but this xine-lib is ~x86. So I guess it's time to upgrade to 3.4.x and recompile my entire system. I think i'm going to have to invest in that antec laptop cooler.
*** Bug 136295 has been marked as a duplicate of this bug. ***
*** Bug 136412 has been marked as a duplicate of this bug. ***
*** Bug 136485 has been marked as a duplicate of this bug. ***
*** Bug 136515 has been marked as a duplicate of this bug. ***
*** Bug 136537 has been marked as a duplicate of this bug. ***
*** Bug 136542 has been marked as a duplicate of this bug. ***
*** Bug 136567 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > http://www.gentoo.org/doc/en/gcc-upgrading.xml > > Your gcc version is outdated and unsupported. I don't understand: both gcc 3.3.6 & 3.4.6 are stable. Doesn't that mean one can use either in a fully stable system ("x86")? You seem to be saying that although 3.3.6 is stable, only 3.4.6 is considered "compiler-du-jour" with respect to system of only stable packages. As a matter of Gentoo policy, is it the case that as soon as a new version of gcc becomes stable, that all other earlier (but still stable) versions no longer are guaranteed to be usable to run a system with only stable packages? So when gcc 4.1 becomes stable, for example, instantly 3.4.x falls out of favor, producing possibly broken packages? Further, any issues that may crop up such as the `-fvisibility=hidden' one here won't be considered bugs, and the user of the then-obsolete 3.4.x gcc has to deal with searching forums/buglist/etc, even though it's supposedly a fully stable sytem? Basically, how is one supposed to set up a stable system in that case and automagically stay updated, or at least be informed that gcc is obsolete? Maybe there's a period of time when both new and less recent versions of gcc are both favored in stable systems, but then later the older version is considered obsolete. I don't object to that, except that the portage has to be told about it, so that the user can be explicitly notified of its obsolescence and therefore know that she has to upgrade the system GCC via gcc-config. For example, packages that are no longer supported on the older compiler should specifically indicate that in their ebuilds, no? I couldn't quite tell from GCC upgrade guide how one is supposed to know that a particular compiler is considered obsolete (analogous to portage profiles becoming obsolete), beyond indirectly noting strange compiler errors such as the one here. In this light I suggest that the xine-lib ebuild be changed to reflect its dependency on the newer gcc 3.4.6. Somehow the ebuild itself needs to say: "Please use gcc-config to upgrade your system C compiler to 3.4.0 or greater; your current complier 3.3.x is no longer supported in stable systems.", or some such. I'm no expert at this, and I image you all have better ideas for accomplishing this goal; I'm just looking for a plain-vanilla, very conservative/stable/no-nonsense system with few/no surprises. Thanks for all your help; I'm sorry if I appear ungrateful for all your great work.
*** Bug 137066 has been marked as a duplicate of this bug. ***
this is marked as resolve,d but the issue isn't actaully resolved. you still need to manually switch gcc-config , and there's no message telling you to do do.
(In reply to comment #20) > this is marked as resolve,d but the issue isn't actaully resolved. you still > need to manually switch gcc-config , and there's no message telling you to do > do. http://www.gentoo.org/doc/en/gcc-upgrading.xml
I agree with Jonas (Comment #18) and Ian (Comment #20), basically. In my oppinion this bug shouldn't be closed/invalid, as long as emerging stable software fails with an error. Either new xine-lib should depend on gcc 3.4.* (I'm not familiar with portage dependency policies, but such dependency wouldn't look good anyway), or emerge should produce at least a warning, like Jakub says: "http://www.gentoo.org/doc/en/gcc-upgrading.xml Your gcc version is outdated and unsupported.". I guess there are more bugs like this one comming soon. Judging by the number of duplicates I think it's worth solving it in a system way somehow.
(In reply to comment #22) > Either new xine-lib should depend on gcc 3.4.* Won't do any good, you can have 3.4.x (or any higher version) already installed but until you switch to it, it will still bomb out. How about that the people here finally follow the guide and upgrade their gcc, instead of making noise? We can't support gcc versions that are completely unsupported uptream.
(In reply to comment #23) > How about that the people > here finally follow the guide and upgrade their gcc, instead of making noise? You need to tell people! How can they know? They are users, not C++ developers. At least an announcement in the GWN must be made to make people upgrade their GCC version (which is non-trivial for non developers; see guide). Then the old GCC version must be masked to reflect its deprecated status.
Personally I don't think even a notice in GWN will 'fix' this issue. When you upgrade GCC it might tell you that you now need to read the gcc upgrade guide, but if GCC is part of a larger upgrade, you wouldn't see this notice (I'm sure there's a bug about this already noted with emerge - enotices might as well not exist for anything other then the last package merged). emerge should warn you each and everytime you use it that there is a newer version of GCC installed and that you should upgrade. Until this is the case, people will keep reporting bugs that aren't bugs.
*** Bug 137511 has been marked as a duplicate of this bug. ***
*** Bug 137870 has been marked as a duplicate of this bug. ***
*** Bug 138172 has been marked as a duplicate of this bug. ***
*** Bug 139887 has been marked as a duplicate of this bug. ***
Some comments recommend an upgrade to gcc 3.4.x as a workaround. I think this is not sufficient because the option -fvisibility was added in gcc 4.x. Besides, I would also opt for reopening the bug, because the entire issue seems to be a bug in the configure test, see the discussion in http://bugs.gentoo.org/show_bug.cgi?id=139887. I have manually fixed the configure macro, and everything works fine so far, with gcc 3.3.6.
