| Summary: | gnome-extra/deskbar-applet-2.24.1 fails to build on a libtooll-1 system | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robert Bradbury <robert.bradbury> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, denny.reeh, flameeyes, loki_val, pacho, premek, sep, serkan, superheron, transformatorhuis |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 238650 | ||
|
Description
Robert Bradbury
2008-10-24 14:12:15 UTC
same problem for me. wonderhp dreeh # emerge --info Portage 2.2_rc12 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.26-gentoo-r1-i686-Intel-R-_Core-TM-2_CPU_T7200_@_2.00GHz-with-glibc2.0 Timestamp of tree: Fri, 24 Oct 2008 17:15:02 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r7, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.6.2 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ " LANG="C" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/mozilla /usr/portage/local/myebuilds /usr/portage/local/layman/mozilla" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl acpi alsa apache2 avahi berkdb bzip2 cdr cli cracklib crypt cups dri dvd fam fortran gdbm gnome gpm gtk hal iconv imagemagick ipv6 isdnlog midi mudflap ncurses nls nptl nptlonly opengl openmp pam pcre perl pppd python readline reflection samba session spl ssl sysfs tcpd unicode userlocales x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="fglrx" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS so running cutting edge software on a stable system and surprised by failures ? please try with libtool 2 and others please tell us your version of libtool as well. Gilles, I am not surprised at all by cutting edge software failures. I first learned UNIX at Harvard on one of the first mini-computer (a PDP11/45) installations installed outside of Bell Labs (circa 1974/5). I was the system manager for a time for the largest DEC minicomputer in Manhatten (so much larger than the systems at Bell Labs that Ken Thompson personally came out to install UNIX to make sure it would run). I was the 7th programmer hired by Oracle Corporation and was their UNIX product development manager in the 1980s, during which time I had extensive opportunities diagnosing both hardware and operating system concurrency problems. So it would be *extremely* difficult to assert that I am unfamiliar with problems and solving them. On the other hand I know little or nothing about how to know what versions of "libtool" are installed on my machine with what I would claim is an "up-to-date", bordering on cutting-edge, installation of Gentoo. And thus processes for converting between libtool 1 vs. libtool 2 are unclear to me. I try to keep the installation updated, updating /etc/portage/package.keywords when ~x86 additions seem to be required. I would assert that the current Gentoo/portage "update" process almost requires that people learn python. I am *not* a python programmer. I am a C programmer. I do not want to be a python programmer. Pity the poor person who does not know any programming, C or Python who tries to deal with a Gentoo system (IMO). I do not know how to determine my current version of "libtool" since it was a tool developed long after my UNIX/Linux education had passed. So please, if you make a request for information -- why not explain "how" to do it? And be aware that making such a request may cost the person filing the bug report several hours (= hundreds of $) of time. (Recent requests that I provide an emerge --info require that I shut down my current semi-"working" version of Linux-2.6.26, boot Linux-2.6.27, then run diagnostics, then reboot 2.6.26 to get back to a working installation.) Given the complexity of the browsers, windows and tabs that I normally run that is a several hour operation! I would implore you to make this "concept" known to other Gentoo developers/pseudo-developers. I help to debug Gentoo Linux only in the faint hope that I may eventually have a Linux which does everything I want it to do (many of the components which fail to build, most probably including "deskbar-applet", do not fall under those constraints), so I am being generous with my time. Robert, 1) a little humility goes a long way, bragging about how you are the 7th programmer hired by Oracle, while being very cool and all, will not grant you automatic God status, and turn us into your minions. 2) "so I am being generous with my time", and so are we. We do our best to run a community distribution. Most of us do it on our _free_ time, getting 0 euros for our time. 3) Gilles' comment was still completely correct. Our extensive documentation is _very_ clear about mixing and matching stable and unstable packages. And understanding how to work with the package manager is a key element in how to do so. As for the question at hand, here's how you can do it "emerge --pretend --verbose libtool" or in shorter form "emerge -pv libtool" You'll of course find more information in "man emerge" which you should have no trouble understanding, given your experience with complex software systems. Thanks works with sys-devel/libtool-2.2.6a Thanks for the follow up Denny. Robert, 1) If you just want a stable Gentoo systems, please get rid of all entries in /etc/portage/package.keywords. This file is intended for users who want unstable package _and_ are willing to suffer bugs such as this one. If you just want something that works, it's best not to use it. 2) If you really do want to mix stable and unstable packages, then please add "sys-devel/libtool" to package.keywords. Thanks @base-system, diego hey guys, I'd like to know if there is any problem in adding --force-missing to automake call (for eautoreconf for example) or if we should fix it on an ebuild basis. If this is not done, people using packages generated with libtool-2 on a system with libtool-1 will suffer from the situation described here. (In reply to comment #2) > so running cutting edge software on a stable system and surprised by failures ? > > please try with libtool 2 and others please tell us your version of libtool as > well. > I find this comment strange considering it compiles fine with libtool 1.5.26 What it doesn't compile fine with is that libtool that is put in the source root directory. emerge deskbar-applet;cd /var/tmp/portage/gnome-extra/deskbar-applet-2.24.1/work/deskbar-applet-2.24.1;rm libtool; ln -s $(which libtool) libtool;make liferaft ~ # libtool --version ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I don't know what that libtool in the root of the source directory is, it claims to be 1.5.26 but someone clearly messed with it and I don't see the point as the app compiles just fine with a unmodified 1.5.26. Rémi, points taken. I would comment that I have no interest in "minions" as I generally like to do things for myself. And I like the Gentoo distribution because it is balanced between having to do nothing and having to do everything. I would however genuinely like to see a distribution which worked on my hardware (which is a pretty standard issue HP Pavilion a630n). And my ill-will is not directed at the Gentoo participants so much as the people who develop the Intel drivers (kernel & X-server) [1], some of whom I believe work for Intel, who seem to be more interested in supporting their latest and greatest graphics hardware rather than their 5 y.o. graphics hardware. But in my experience "desupporting" old hardware seems to be something Intel tends to do. If one needs my emerge --info, it is attached to Bug #243820. My libtool --version yields: ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) 1. Re: Bug #243830 and Bug #243844. I upgrade the sys-devel/libtool to most recent version (2.2.6a) and this solve the problem. (In reply to comment #9) > Rémi, points taken. I would comment that I have no interest in "minions" as I > generally like to do things for myself. And I like the Gentoo distribution > because it is balanced between having to do nothing and having to do > everything. I would however genuinely like to see a distribution which worked > on my hardware (which is a pretty standard issue HP Pavilion a630n). And my > ill-will is not directed at the Gentoo participants so much as the people who > develop the Intel drivers (kernel & X-server) [1], some of whom I believe work > for Intel, who seem to be more interested in supporting their latest and > greatest graphics hardware rather than their 5 y.o. graphics hardware. But in > my experience "desupporting" old hardware seems to be something Intel tends to > do. > > If one needs my emerge --info, it is attached to Bug #243820. > > My libtool --version yields: > ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) > > 1. Re: Bug #243830 and Bug #243844. > i seem to recall --force-missing overriding too many files, so it would not be a good idea for global usage I will confirm that upgrading libtool, e.g. adding sys-devel/libtool ~x86 to /etc/portage/package.keywords and emerging libtool (upgrading it to 2.2.6a) followed by deskbar-applet appears to work. So there may be a problem with various developers/testers working with complex (and different) mixtures of packages. (I for example have no idea how many packages would need to be downgraded if I threw out my package.keywords -- but I suspect it would be very many.) I'm afraid that unless libtool2 is already stable by the time we get to GNOME-2.24 stabilization (extremely unlikely due to the impact on many packages and many not working with libtool2 in stable versions), we still need to fix this to work with libtool-1. Is anyone reading comments. it WORKS with libtool1 The problem is that configure takes the installed libtool and patches it, but this configure patch isn't compatible with libtool1, only libtool2. doing emerge and letting it break and THEN replace the created libtool with a symlink to the system libtool1 and this program compiles just fine. (In reply to comment #14) > Is anyone reading comments. Yes we are. > it WORKS with libtool1 We *know* > The problem is that configure takes the installed libtool and patches it, but > this configure patch isn't compatible with libtool1, only libtool2. That's because it is _supposed_ to use the libtool that's shipped with the tarball, that's the intention. > doing emerge and letting it break and THEN replace the created libtool with a > symlink to the system libtool1 and this program compiles just fine. Again, that's _wrong_. That's not a proper fix. The issue here is that the shipped libtool is 2.x and we're rerunning autoreconf with libtool 1.x. The proper fix is to remove all traces of libtool 2.x before running autoreconf, or telling autoreconf to _really_ overwrite everything (--force-override, like Mike suggested). Thanks (In reply to comment #15) > (In reply to comment #14) > > Is anyone reading comments. > > Yes we are. Sure doesn't seem that way since people keeps saying it doesn't work with libtool1. > > it WORKS with libtool1 > > We *know* Then why are people claiming it doesn't. > > doing emerge and letting it break and THEN replace the created libtool with a > > symlink to the system libtool1 and this program compiles just fine. > > Again, that's _wrong_. That's not a proper fix. Who said it was a fix, it was a ILLUSTRATION on how to test that it can be compiled with libtool1 because this thread seems to KEEP claiming it's not possible. To me it looked like the dev was just dumping on the thread starter, and basing assumptions on incorrect information. I'm still not convinced that the issue is completely understood by anyone. Considering that no special modified libtool is needed to compile it at all, maybe it's just some old legacy code that everyone has forgotten what does and that isn't needed anymore. My point was that if it doesn't compile with libtool-1 at the present ebuild state, then we still probably need to fix it, whatever the issues is, as libtool2 probably won't be stable on time. The main point was the bug reopening. This bug is a bug until a stable toolchain can't emerge deskbar-applet-2.24 in its existing ebuild form. However technically we have some 3 weeks to investigate it in detail, as it isn't going stable yet before some time, and it seems to emerge with ~arch toolchain. The problem is that this package includes its own m4 files for libtool. If you delete them, it will automagically use system files, solving the problem. On the line before eautoreconf, do this: rm m4/lt* m4/libtool* (In reply to comment #18) yes that's mostly what have been said in comment #6 and #7, thanks +1 for making this ebuild work without toolchain upgrades. We've all been through a couple of these situations where some packages will try to pull in newer versions of a system tool, and it ends up becoming a project unto itself to stabilize that system tool and fix the breakage in its wake. IMHO, the best fix is to temporarily neuter this package's included libtool, so that it works with system libtool-1, and to add a note on Bug #212763, which is tracking libtool-2 breakage. *** Bug 248781 has been marked as a duplicate of this bug. *** fixed without a bump for 2.24.2. Thanks for reporting. |
