FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 12-26-2011, 05:23 PM
Alex Schuster
 
Default Build problems due to invalid libtool arguments

Hi there!

I'm currently upgrading my little sister's PC from an x86 Sempron to an
x86_64 AMDS A6 processor. So Gentoo is being installed from scratch.

But some packages fail to build. I filed a bug [1] for
media-libs/libggi-2.2.2, but a similar problem is happening for
pygtksourceview now, and I do not find a simple workaround.

The problem is that in the libtool linking phase the arguments "/usr/bin
/usr/sbin /bin /sbin" are given along the libraries and library paths. I
have no idea why this happens, and how to solve this. Something must be
wrong on my system. But what? For libggi, emerging with USE=-aalib sort
of solved this. But I have no idea what to do about pygtksourceview. As
all gthe KDE stuff seems to depend on this, I cannot continue

Here's the end of the build log. Look at the line I marked with a (***).

libtool: link: echo "{ global:" > .libs/libggi.ver
libtool: link: cat ./EXPSYMS | sed -e "s/(.*)/1;/" >> .libs/libggi.ver
libtool: link: echo "local: *; };" >> .libs/libggi.ver
libtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/builtins.o
.libs/colormap.o .libs/db.o .libs/dl.o .libs/events.o .libs/ext.o
.libs/gc.o .libs/init.o .libs/internal.o .libs/mode.o .libs/probe.o
.libs/stubs.o .libs/swar.o .libs/unix.o .libs/visual.o
-Wl,--whole-archive ../display/auto/.libs/libauto.a
../default/stubs/.libs/libstubs.a
../default/pseudo_stubs/.libs/libpseudo_stubs.a
../default/color/.libs/libcolor.a ../default/text_16/.libs/libtext_16.a
../default/text_32/.libs/libtext_32.a
../default/linear_1/.libs/liblinear_1.a
../default/linear_16/.libs/liblinear_16.a
../default/linear_1_r/.libs/liblinear_1_r.a
../default/linear_2/.libs/liblinear_2.a
../default/linear_24/.libs/liblinear_24.a
../default/linear_32/.libs/liblinear_32.a
../default/linear_4/.libs/liblinear_4.a
../default/linear_4_r/.libs/liblinear_4_r.a
../default/linear_8/.libs/liblinear_8.a
../default/planar/.libs/libplanar.a ../default/ilbm/.libs/libilbm.a
../default/iplanar_2p/.libs/libiplanar_2p.a
../default/fbdev/mga/2164w/.libs/libm2164w.a
../default/fbdev/mga/g400/.libs/libmga_g400.a
../default/fbdev/ati/mach64/.libs/libmach64.a
../display/aa/.libs/libaa.a ../display/fbdev/.libs/libfbdev.a
../display/file/.libs/libfile.a ../display/ipc/.libs/libipc.a
../display/linvtsw/.libs/liblinvtsw.a
../display/mansync/.libs/libmansync.a
../display/memory/.libs/libmemory.a
../display/monotext/.libs/libmonotext.a
../display/multi/.libs/libmulti.a ../display/palemu/.libs/libpalemu.a
../display/sub/.libs/libsub.a ../display/tele/.libs/libtele.a
../display/terminfo/.libs/libterminfo.a ../display/tile/.libs/libtile.a
../display/trueemu/.libs/libtrueemu.a ../display/vcsa/.libs/libvcsa.a
../display/X/.libs/libx.a
../display/X/helper/dbe/.libs/libhelper_x_dbe.a
../display/X/helper/dga/.libs/libhelper_x_dga.a
../display/X/helper/evi/.libs/libhelper_x_evi.a
../display/X/helper/shm/.libs/libhelper_x_shm.a
../display/X/helper/vidmode/.libs/libhelper_x_vidmode.a
-Wl,--no-whole-archive -L/usr/lib /usr/lib64/libaa.so /usr/bin (***)
/usr/sbin /bin /sbin -lm -lncurses -lXxf86vm /usr/lib64/libgii.so
-L/usr/lib64 -lX11 -lXxf86dga -lXext /usr/lib64/libgg.so -ldl -lpthread
-lc -march=native -msse -msse2 -msse3 -m3dnow -Wl,-O1 -Wl,--as-needed
-Wl,-soname -Wl,libggi.so.2 -Wl,-version-script -Wl,.libs/libggi.ver -o
.libs/libggi.so.2.0.2
/usr/bin: file not recognized: Is a directory


leela / # emerge --info libggi
/usr/lib64/portage/pym/portage/package/ebuild/config.py:353:
UserWarning: 'cache.metadata_overlay.database' is deprecated:
/etc/portage/modules
(user_auxdbmodule, modules_file))
Portage 2.2.0_alpha83 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.3,
glibc-2.13-r4, 3.0.13-std241-amd64 x86_64)
================================================== ===============
System Settings
================================================== ===============
System uname:
Linux-3.0.13-std241-amd64-x86_64-AMD_A6-3500_APU_with_Radeon-tm-_HD_Graphics-with-gentoo-2.0.3
Timestamp of tree: Sun, 25 Dec 2011 22:15:01 +0000
app-shells/bash: 4.1_p9
dev-java/java-config: 2.1.11-r3
dev-lang/python: 2.7.2-r3, 3.1.4-r3
dev-util/cmake: 2.8.6-r4
dev-util/pkgconfig: 0.26
sys-apps/baselayout: 2.0.3
sys-apps/openrc: 0.9.4
sys-apps/sandbox: 2.5
sys-devel/autoconf: 2.13, 2.68
sys-devel/automake: 1.11.1
sys-devel/binutils: 2.21.1-r1
sys-devel/gcc: 4.5.3-r1
sys-devel/gcc-config: 1.4.1-r1
sys-devel/libtool: 2.4-r1
sys-devel/make: 3.82-r1
sys-kernel/linux-headers: 2.6.39 (virtual/os-headers)
sys-libs/glibc: 2.13-r4
Repositories: gentoo zugaina local
Installed sets:
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -msse -msse2 -msse3 -m3dnow -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/openvpn/easy-rsa"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /usr/share/X11/xkb"
CXXFLAGS="-march=native -msse -msse2 -msse3 -m3dnow -pipe"
DISTDIR="/var/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps y --keep-going --load-average=3.5"
FEATURES="assume-digests binpkg-logs buildsyspkg collision-protect
distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch userpriv usersandbox"
FFLAGS=""
GENTOO_MIRRORS="rsync://mirror.netcologne.de/gentoo/
ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
http://91.121.124.139/gentoo-distfiles/
http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="de"
MAKEOPTS="-j4"
PKGDIR="/var/portage/packages"
PORTAGE_CONFIGROOT="/"
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/portage/tmp"
PORTDIR="/var/portage/tree"
PORTDIR_OVERLAY="/var/portage/layman/zugaina /var/portage/local"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dnow X a52 aac aalib acl acpi aim alsa amd64 apm audiofile
bash-completion berkdb bluetooth branding bzip2 cairo cdda cddb cdr cli
consolekit cracklib crypt cups cxx dbus declarative dga dio dri dts dvd
dvdr dvdread emboss encode exif fam fbcon ffmpeg firefox flac foomaticdb
ftp gd gdbm gdu ggi gif gimp gphoto2 gpm gtk handbook iconv imagemagick
imlib ipv6 jabber java javascript jpeg jpeg2k kde kipi lame lcms ldap
libnotify lm_sensors mad mikmod mime mmx mng modules motif mozbranding
mp3 mp4 mpeg mplayer msn mudflap multilib musicbrainz ncurses nls nptl
nptlonly nsplugin ogg openal opengl openmp oss pam pango pcre pdf phonon
plasma png policykit ppds pppd qt3support qt4 quicktime readline recode
samba scanner sdl semantic-desktop session sid sndfile sox speex spell
sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype udev
unicode usb v4l videos visualization vorbis wma wmf x264 xcb xcomposite
xine xinerama xml xorg xscreensaver xulrunner xv xvid zlib"
ALSA_CARDS="es1371" 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 authn_alias authn_anon
authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache cgi
cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id userdir
usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage
tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df
interface irq load memory rrdtool swap syslog" ELIBC="glibc"
GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt
gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore
rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx"
INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de"
PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU"
VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2
ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq
steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL,
PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

================================================== ===============
Package Settings
================================================== ===============

media-libs/libggi-2.2.2 was built with the following:
USE="X (consolekit) fbcon mmx (multilib) (policykit) (-3dfx) -aalib
-debug -directfb (-svga) (-vis)"

Any ideas about this?

[1] http://bugs.gentoo.org/show_bug.cgi?id=396083

Wonko
 
Old 12-26-2011, 09:57 PM
Alex Schuster
 
Default Build problems due to invalid libtool arguments

I wrote:

> The problem is that in the libtool linking phase the arguments "/usr/bin
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> have no idea why this happens, and how to solve this. Something must be
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> of solved this. But I have no idea what to do about pygtksourceview. As
> all gthe KDE stuff seems to depend on this, I cannot continue

I found a workaround, after looking more closely to the emerge -t
output. pygtksourceview is needed when git is built only with the gtk
USE flag. So I can continue, but it just happened again with
dev-db/libiodbc, whatever this is, and whatever this may depend on.
There is something wrong on this system, and I have no idea where to look.

Wonko
 
Old 12-27-2011, 12:15 AM
Pandu Poluan
 
Default Build problems due to invalid libtool arguments

On Dec 27, 2011 6:01 AM, "Alex Schuster" <wonko@wonkology.org> wrote:

>

> I wrote:

>

> > The problem is that in the libtool linking phase the arguments "/usr/bin

> > /usr/sbin /bin /sbin" are given along the libraries and library paths. I

> > have no idea why this happens, and how to solve this. Something must be

> > wrong on my system. But what? For libggi, emerging with USE=-aalib sort

> > of solved this. But I have no idea what to do about pygtksourceview. As

> > all gthe KDE stuff seems to depend on this, I cannot continue

>

> I found a workaround, after looking more closely to the emerge -t

> output. pygtksourceview is needed when git is built only with the gtk

> USE flag. So I can continue, but it just happened again with

> dev-db/libiodbc, whatever this is, and whatever this may depend on.

> There is something wrong on this system, and I have no idea where to look.

>


Have you tried revdep-rebuild? python-updater?


Rgds,
 
Old 12-27-2011, 12:53 AM
Alex Schuster
 
Default Build problems due to invalid libtool arguments

Pandu Poluan writes:

> On Dec 27, 2011 6:01 AM, "Alex Schuster" <wonko@wonkology.org
> <mailto:wonko@wonkology.org>> wrote:
>>
>> I wrote:
>>
>> > The problem is that in the libtool linking phase the arguments "/usr/bin
>> > /usr/sbin /bin /sbin" are given along the libraries and library paths. I
>> > have no idea why this happens, and how to solve this. Something must be
>> > wrong on my system. But what? For libggi, emerging with USE=-aalib sort
>> > of solved this. But I have no idea what to do about pygtksourceview. As
>> > all gthe KDE stuff seems to depend on this, I cannot continue

The problem seems to happen deep in the libtool script in the build
directory, where a variable deplibs is set to "/sbin /bin /usr/sbin
/usr/bin/usr/lib64/libaa.so ...", but I do not yet know why and where in
those 7700 lines of code that happens, a 'libtool=' occurs 121 times
there. Gotta go to bed for now

> Have you tried revdep-rebuild? python-updater?

No. When I do, all is consistent, and python-updater does not find much,
mostly things that are not even installed yet.

Now I try another of those things that are supposed to fix all kind of
weird problems, emerge -e @world. I changed the CFLAGS a little, and I
had forgotten to add sse2 to the USE flags, so I just build everything
again this night. But I don't expect this to help with my problem.

Wonko
 
Old 12-27-2011, 07:08 AM
"Walter Dnes"
 
Default Build problems due to invalid libtool arguments

On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote
> Hi there!
>
> I'm currently upgrading my little sister's PC from an x86 Sempron to an
> x86_64 AMDS A6 processor. So Gentoo is being installed from scratch.
>
> But some packages fail to build. I filed a bug [1] for
> media-libs/libggi-2.2.2, but a similar problem is happening for
> pygtksourceview now, and I do not find a simple workaround.
>
> The problem is that in the libtool linking phase the arguments "/usr/bin
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> have no idea why this happens, and how to solve this. Something must be
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> of solved this. But I have no idea what to do about pygtksourceview. As
> all gthe KDE stuff seems to depend on this, I cannot continue

I notice that you have 'MAKEOPTS="-j4"'. You wouldn't believe how
many problems you can solve by changing to 'MAKEOPTS="-j1"'. Yes, the
build process may take a bit longer, but the final executable runs just
as fast. Change to 'MAKEOPTS="-j1"' and see what happens.

The concept of parallel jobs is nice in theory, and you can *USUALLY*
get away with it. The problem is that if a job tries to use an
intermediate file before it's fully created, or if the "destructor"
(file deletion) does it's thing before the scratch file has been used,
things get very fouled up. My attitude is that the first time you spend
hours trying to trace down a non-replicatable bug, you will lose more
time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'.

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 12-27-2011, 09:10 AM
Alex Schuster
 
Default Build problems due to invalid libtool arguments

Walter Dnes writes:

> On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote

>> The problem is that in the libtool linking phase the arguments "/usr/bin
>> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
>> have no idea why this happens, and how to solve this. Something must be
>> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
>> of solved this. But I have no idea what to do about pygtksourceview. As
>> all gthe KDE stuff seems to depend on this, I cannot continue
>
> I notice that you have 'MAKEOPTS="-j4"'. You wouldn't believe how
> many problems you can solve by changing to 'MAKEOPTS="-j1"'. Yes, the
> build process may take a bit longer, but the final executable runs just
> as fast. Change to 'MAKEOPTS="-j1"' and see what happens.

Good idea, I also had some weird side effects from that in the past.
Although not that reproducible. I see this with libggi, libiodbc,
gtksourceview and gettext, at least.

I still get the same error. And the emerge -e also did not clean things up.

My next idea would be to compare the build logs on that and on my own
machine, maybe I spot a difference. Or to analyze the libtool script
deeper. Before I give up and install Ubuntu...

Wonko
 
Old 12-27-2011, 01:21 PM
James
 
Default Build problems due to invalid libtool arguments

Alex Schuster <wonko <at> wonkology.org> writes:


> > as fast. Change to 'MAKEOPTS="-j1"' and see what happens.

+1


> I still get the same error. And the emerge -e also did not clean things up.

Yep. Sometimes on setting up a new system, I lower the bar on what I install,
resync the system and a day or 2 later, complete the install.


My little catch all, after hacking at the system is:

env-update && source /etc/profile && etc-update && eix-update

Run it often and resync every 12 hours too.

Also check your profile.


On lib tool, see if you have this script and run it:

fix_libtool_files.sh 3.3.4

Not sure where I found that puppy, but hopefully it fixes your
issues with libtool.


Just shots in the dark, YMMV!


James
 
Old 12-27-2011, 01:37 PM
Michael Mol
 
Default Build problems due to invalid libtool arguments

Walter Dnes wrote:

On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote
I notice that you have 'MAKEOPTS="-j4"'. You wouldn't believe how
many problems you can solve by changing to 'MAKEOPTS="-j1"'. Yes, the
build process may take a bit longer, but the final executable runs just
as fast. Change to 'MAKEOPTS="-j1"' and see what happens.

The concept of parallel jobs is nice in theory, and you can *USUALLY*
get away with it. The problem is that if a job tries to use an
intermediate file before it's fully created, or if the "destructor"
(file deletion) does it's thing before the scratch file has been used,
things get very fouled up. My attitude is that the first time you spend
hours trying to trace down a non-replicatable bug, you will lose more
time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'.


While I agree poking the MAKEOPTS is a good idea, I'd like to point out
my own experience with parallel builds.


IME, running with emerge "--keep-going", and then running "emerge
--resume --keep-going" once or twice *afterward* typically solves any
problem I had on my first pass. I suspect unspecified dependencies are
usually to blame.
 
Old 12-27-2011, 03:10 PM
Dale
 
Default Build problems due to invalid libtool arguments

Michael Mol wrote:

Walter Dnes wrote:

On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote
I notice that you have 'MAKEOPTS="-j4"'. You wouldn't believe how
many problems you can solve by changing to 'MAKEOPTS="-j1"'. Yes, the
build process may take a bit longer, but the final executable runs just
as fast. Change to 'MAKEOPTS="-j1"' and see what happens.

The concept of parallel jobs is nice in theory, and you can *USUALLY*
get away with it. The problem is that if a job tries to use an
intermediate file before it's fully created, or if the "destructor"
(file deletion) does it's thing before the scratch file has been used,
things get very fouled up. My attitude is that the first time you spend
hours trying to trace down a non-replicatable bug, you will lose more
time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'.


While I agree poking the MAKEOPTS is a good idea, I'd like to point
out my own experience with parallel builds.


IME, running with emerge "--keep-going", and then running "emerge
--resume --keep-going" once or twice *afterward* typically solves any
problem I had on my first pass. I suspect unspecified dependencies are
usually to blame.





That's my experience too. It is even rare that I run into that. I
would imagine that some builds are more complex than others so if it
does fail, trying it with -j1 would make sense. It's better than
waiting for a fix that may not happen for a while at least.


I think the parallel options on both fronts is getting better.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
 
Old 12-27-2011, 03:32 PM
Alex Schuster
 
Default Build problems due to invalid libtool arguments

I wrote:

> The problem is that in the libtool linking phase the arguments "/usr/bin
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I
> have no idea why this happens, and how to solve this. Something must be
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort
> of solved this. But I have no idea what to do about pygtksourceview. As
> all gthe KDE stuff seems to depend on this, I cannot continue

And the solution is <ta-daaah>: unset path

I am using systemrescuecd, which sets a 'path' environment variable.
This variable is being used in the libtool script, without being cleared
first.

Makes me feel a little stupid. I filed a bug report for a package that
built without problems on my other system. I looked a bugs.gentoo.org,
but did not search the web much for keywords like 'libtool' and
'/usr/bin /usr/sbin /bin /sbin', which would have found a few mentions
of this problem. And I wasted too much time debugging and trying to
understand the libtool script.

I filed a bug for autoconf:
https://bugs.gentoo.org/show_bug.cgi?id=396213

Wonko
 

Thread Tools




All times are GMT. The time now is 09:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org