Summary: | x11-libs/gtk+-3.2.3 - ./.libs/libgtk-3.so: undefined reference to `pango_layout_get_log_attrs_readonly' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Summers <msummers57> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | dev-portage, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build log and environment
MAKEOPTS="V=1 -j1" emerge -1 gtk+ build.log |
Description
Mike Summers
2012-03-22 14:58:52 UTC
Created attachment 306317 [details]
Build log and environment
What versions of dev-libs/atk and x11-libs/pango do you have installed? Do you have local versions of atk and/or pango installed in /usr/local/lib? Do you have sys-devel/crossdev installed? Are you using any sort of customized gcc profile? (In reply to comment #2) > What versions of dev-libs/atk and x11-libs/pango do you have installed? [ebuild R ] dev-libs/atk-2.2.0 USE="introspection nls -doc" 0 kB [ebuild R ] x11-libs/pango-1.29.4 USE="X introspection -debug -doc -test" 0 kB > > Do you have local versions of atk and/or pango installed in /usr/local/lib? No- root@huey ~ # ll /usr/local/lib/*pango* /usr/local/lib/*atk* ls: cannot access /usr/local/lib/*pango*: No such file or directory ls: cannot access /usr/local/lib/*atk*: No such file or directory > > Do you have sys-devel/crossdev installed? No > > Are you using any sort of customized gcc profile? No, I've tried out of the box gcc 4.5.3 & 4.3.6 and both fail. Do I need to recompile everything after moving from 4.3 to 4.5? Can you please attach a more verbose, single-threaded build log? To do so, please run MAKEOPTS="V=1 -j1" emerge -1 gtk+ Created attachment 306457 [details]
MAKEOPTS="V=1 -j1" emerge -1 gtk+ build.log
Thanks. The error seems to happen here:
> libtool: link: i686-pc-linux-gnu-gcc -std=gnu99 -DGDK_PIXBUF_DISABLE_DEPRECATED -O2 -march=i686 -pipe -Wall -Wl,-O1 -Wl,--as-needed -o .libs/gtk-query-immodules-3.0 queryimmodules.o -pthread ./.libs/libgtk-3.so /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gdk/.libs/libgdk-3.so ../gdk/.libs/libgdk-3.so -lXext -lXinerama -lXi -lXrandr -lXcursor -lpangocairo-1.0 -lX11 -lXcomposite -lXdamage -lXfixes -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lm -pthread
> ./.libs/libgtk-3.so: undefined reference to `pango_layout_get_log_attrs_readonly'
> ./.libs/libgtk-3.so: undefined reference to `atk_window_get_type'
I don't see anything wrong with that linking command for gtk-query-immodules-3.0; but perhaps the problem is with the built libgtk-3.so library.
Please give the output of
scanelf -n /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gtk/.libs/libgtk-3.so
and
ldd -d -r /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gtk/.libs/libgtk-3.so
Also, are you by any chance using gold as your linker?
Yes, that's what I thought from the logs. huey ~ # scanelf -n /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gtk/.libs/libgtk-3.so TYPE NEEDED FILE ET_DYN libgdk-3.so.0,libXext.so.6,libXinerama.so.1,libXi.so.6,libXrandr.so.2,libXcursor.so.1,libpangocairo-1.0.so.0,libX11.so.6,libXcomposite.so.1,libXdamage.so.1,libXfixes.so.3,libatk-1.0.so.0,libcairo-gobject.so.2,libcairo.so.2,libgdk_pixbuf-2.0.so.0,libgio-2.0.so.0,libpangoft2-1.0.so.0,libpango-1.0.so.0,libfreetype.so.6,libfontconfig.so.1,libgobject-2.0.so.0,libgmodule-2.0.so.0,libgthread-2.0.so.0,librt.so.1,libglib-2.0.so.0,libm.so.6,libpthread.so.0,libc.so.6 /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gtk/.libs/libgtk-3.so huey ~ # ldd -d -r /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gtk/.libs/libgtk-3.so linux-gate.so.1 => (0xffffe000) libgdk-3.so.0 => /var/tmp/portage/x11-libs/gtk+-3.2.3/work/gtk+-3.2.3/gdk/.libs/libgdk-3.so.0 (0xb7419000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb73f0000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb73ec000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb73dd000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb73d3000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb73c8000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb73bc000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb729c000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7298000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7293000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb728d000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb726f000) libcairo-gobject.so.2 => /usr/lib/libcairo-gobject.so.2 (0xb7268000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb71c0000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb71a2000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb708c000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7063000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7020000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6f94000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6f64000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6f1c000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6f17000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6f11000) librt.so.1 => /lib/librt.so.1 (0xb6f08000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6dfc000) libm.so.6 => /lib/libm.so.6 (0xb6dd5000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6dbb000) libc.so.6 => /lib/libc.so.6 (0xb6c5d000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6c53000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6c38000) libdl.so.2 => /lib/libdl.so.2 (0xb6c34000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6bd4000) libpng15.so.15 => /usr/lib/libpng15.so.15 (0xb6ba8000) libz.so.1 => /lib/libz.so.1 (0xb6b92000) libresolv.so.2 => /lib/libresolv.so.2 (0xb6b7d000) libbz2.so.1 => /lib/libbz2.so.1 (0xb6b6b000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6b40000) libffi.so.5 => /usr/lib/libffi.so.5 (0xb6b38000) /lib/ld-linux.so.2 (0xb786d000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb6b34000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6b2e000) huey ~ # ll /usr/lib/libatk-1.0.so.0 /usr/lib/libpango-1.0.so.0 lrwxrwxrwx 1 root root 23 Mar 20 21:59 /usr/lib/libatk-1.0.so.0 -> libatk-1.0.so.0.20209.1 lrwxrwxrwx 1 root root 24 Mar 20 21:59 /usr/lib/libpango-1.0.so.0 -> libpango-1.0.so.0.2904.0 I don't believe I'm using gold, does this help? root@huey mike # readlink -f /usr/bin/ld /usr/i686-pc-linux-gnu/binutils-bin/2.21.1/ld Thanks for your help. (In reply to comment #7) Everything seems to be in order. And I cannot reproduce the problem on my amd64 systems or figure out how it could occur :/ Other than rebuilding x11-libs/pango and dev-libs/atk on the chance that they are broken somehow, I don't have any suggestions left. @toolchain, perhaps you could take a look at why linking is failing here? It's a puzzle. I've seen this once or twice before and it was related to the gcc version, dropping back to 4.1 usually solved the problem... what gcc are you using? I've rebuilt libatk & libpango using gcc 4.3.6 & 4.5.3 just prior to emerging gtk+ and no help. Thanks again for your time. (In reply to comment #9) > what gcc are you using? 4.5.3-r2 and 4.6.2 (gtk+-3.2.3 successfully builds with both). what does `ld --version` show ? what about: readelf -sW /usr/lib/libpango-1.0.so.0 | grep pango_layout_get_log_attrs readelf -sW /usr/lib/libatk-1.0.so.0 | grep atk_window_get_type root@huey ~ # ld --version GNU ld (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. root@huey ~ # readelf -sW /usr/lib/libpango-1.0.so.0 | grep pango_layout_get_log_attrs 246: 00023d90 126 FUNC GLOBAL DEFAULT 11 pango_layout_get_log_attrs_readonly 253: 00023e10 172 FUNC GLOBAL DEFAULT 11 pango_layout_get_log_attrs root@huey ~ # readelf -sW /usr/lib/libatk-1.0.so.0 | grep atk_window_get_type 274: 00014c20 203 FUNC GLOBAL DEFAULT 11 atk_window_get_type Let's go ahead and close this, I couldn't get it 'fixed' so I did a radical clean-up of the machine: - Minimal make.conf USE flags: USE="alsa apng bash-completion bitmap-fonts cairo evdev gif jpeg nsplugin nvidia pdf png profile svg threads truetype-fonts type1-fonts vim-syntax win32codecs X xcomposite xine xinerama xinetd xorg xvmc -cups -doc -emacs -gs -tiff" - Minimal /etc/portage/package.* settings: /etc/portage/package.keywords www-client/firefox-bin ~x86 www-client/google-chrome ~x86 /etc/portage/package.mask >=x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.unmask /etc/portage/package.use www-client/google-chrome plugins-symlink =app-text/ghostscript-gpl-9.04-r4 cups >=dev-libs/libxml2-2.7.8-r5 python depclean'ed the cruft from world. gtk+-3.2.3 isn't trying to emerge on update so things are all good and stable. Thanks for your time. This popped-up again once gtk+3.2.3 was unmasked. The /usr/lib32 versions of libpango & libatk are older and smaller than the versions in /usr/lib. I un-emerged emul-linux-x86-gtklibs to get rid of the /usr/lib32/ versions of pango & atk, re-ran emerge -auvD world and gtk+3.2.3 built without issue. Why do you have emul packages installed on a x86 system? The best I can tell they were pulled-in at some point by nspluginwrapper. This is invalid then, emul packages are not supposed to be used in x86 Something odd is going on with emerge, nspluginwrapper wants emul-linux-x86-gtklibs: root@huey ~ # emerge -puvD nspluginwrapper [ebuild N *] app-emulation/emul-linux-x86-gtklibs-20120127 USE="-development" 0 kB [ebuild N *] www-plugins/nspluginwrapper-1.4.4-r3 0 kB acroread and adobe-flash say they depend on emul-linux-x86-gtklibs: root@huey ~ # equery depends emul-linux-x86-gtklibs * These packages depend on emul-linux-x86-gtklibs: app-text/acroread-9.5.1 (amd64 ? app-emulation/emul-linux-x86-gtklibs) www-plugins/adobe-flash-11.2.202.228 (>=app-emulation/emul-linux-x86-gtklibs-20100409-r1) However if I emerge them they don't depend on emul-linux-x86-gtklibs: root@huey ~ # emerge -pvD acroread adobe-flash [ebuild R ] www-plugins/adobe-flash-11.2.202.228 USE="sse2check%* (-32bit) (-64bit) -kde (-multilib) -vdpau" 0 kB [ebuild R ] app-text/acroread-9.5.1 USE="nsplugin -cups -ldap -minimal" LINGUAS="en -ja -ko -zh_CN -zh_TW" 0 kB And emul-linux-x86-gtklibs is *NOT* installed: root@huey ~ # emerge -s emul-linux-x86-gtklibs * app-emulation/emul-linux-x86-gtklibs [ Masked ] Latest version available: 20120127 Latest version installed: [ Not Installed ] Size of files: 5,976 kB Errors in ebuilds? I'm out of my portage depth at this point. Also, to clarify, are you saying I should not have any emul packages installed on my x86 system? (In reply to comment #18) > Something odd is going on with emerge, nspluginwrapper wants > emul-linux-x86-gtklibs: nspluginwrapper is amd64 only, check it's KEYWORDS. Probably bug 256259 will interest you (but I guess a patch to current ebuild in that bug is the only way to get it implemented soon) (In reply to comment #19) > Also, to clarify, are you saying I should not have any emul packages > installed on my x86 system? Exactly ;) In general: don't install packages keyworded in amd64 in your x86 system, don't mix different keywords Hmm... I know I didn't set anything with ~amd64, on my x86 system, would: =app-emulation/emul-linux-x86-opengl-20120127 ** =app-emulation/emul-linux-x86-baselibs-20120127 ** pull in the amd64 libs? (In reply to comment #21) yes. that's the point of the '**'. maybe we should additionally mask these packages in the x86 profile ? I'll not be so trusting when emerge makes a recommendation :-) I've un-emerged the emul libs and usr/lib32 is empty. Thanks for the lesson. (In reply to comment #22) > (In reply to comment #21) > > yes. that's the point of the '**'. > > maybe we should additionally mask these packages in the x86 profile ? Maybe we should add explicit "-*" to their KEYWORDS, but I don't know if portage would still try to automatically unmask them :/ (In reply to comment #24) > Maybe we should add explicit "-*" to their KEYWORDS, but I don't know if > portage would still try to automatically unmask them :/ -* in KEYWORDS doesn't do anything. The autounmask behavior is only triggered for unsatisfied dependencies, so if it's pulling in something that you don't want to unmask, you have to look at the parent package that pulled it in and mask that. Umm, ok then |