After clean compilation, inkscape dies on startup with no obvious reason. This is the first time I compile inkscape with emerge (earlier I was doing that manualy) so I don't know anything about previous versions. With manul build there was no problem. Except that now I'm using gcc-3.4.3 and glibc-2.3.5. This is what I get running inkscape from shell: vlada@vlada ~ $ inkscape *** glibc detected *** free(): invalid pointer: 0x084996c8 *** Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. emerge --info attached. The other solution I've tried was 'CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer"' but that didn't help. Reproducible: Always Steps to Reproduce: Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5- r0, 2.6.11-ck4 i686) ================================================================= System uname: 2.6.11-ck4 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.6.11 dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.4.3-r4, 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt - falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop- arrays" 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/share/config /usr/lib/X11/xkb / usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce- addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop- arrays" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/ distributions/gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X alsa apm avi berkdb bitmap-fonts cdr crypt cups curl dvd emboss encode esd fam fftw flac foomaticdb fortran gdbm gif gimpprint gphoto2 gpm gstreamer gtk gtk2 guile imagemagick imlib ipv6 jack java jpeg kde ladcca lcms ldap libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline scanner sdl slang soundtouch spell sse ssl svg svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb vorbis wmf xml2 xmms xscreensaver xv zlib" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS, PORTDIR_OVERLAY
Is there anything I can do to help solve this one? Perhaps building glibc with debug flag?! Vlada
Hi, I had this problem, I saw somewhere, not sure where, about a few libraries needing to be compiled with the same gcc as inkscape, so I recompiled libstdc++-v3, but it still crashed. When I ran emerge -auvD inkscape I had three libraries to upgrade dev-libs/libsigc++ dev-cpp/glibmm dev-cpp/gtkmm After glibmm merged inkscape would start. Sorry I can't be clearer on whether or it was the compiling glibmm or the new version that fixed the problem.
You're right! That solved the problem. But, I really think developers should correct this one. I'm leaving it opened for developers to decide whats next step. Thanx again, Vlada
"Hardware" should be changed from "x86" to "all" since I'm having the same problem on my ppc box. $ gdb inkscape GNU gdb 6.2 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-unknown-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/inkscape (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols foun d)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging sy mbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debuggi ng symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no de bugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...( no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found )...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 17375)] *** glibc detected *** free(): invalid pointer: 0x1045e350 *** Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 17375)] 0x0e85f1f0 in kill () from /lib/libc.so.6 (gdb) bt #0 0x0e85f1f0 in kill () from /lib/libc.so.6 #1 0x0eba5318 in pthread_kill () from /lib/libpthread.so.0 #2 0x0eba5354 in raise () from /lib/libpthread.so.0 #3 0x0e85efb0 in raise () from /lib/libc.so.6 #4 0x0e8606e0 in abort () from /lib/libc.so.6 #5 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #6 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #7 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #8 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #9 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #10 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #11 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #12 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #13 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #14 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #15 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #16 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #17 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #18 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 #19 0x0e899cc4 in __libc_malloc_pthread_startup () from /lib/libc.so.6 Previous frame inner to this frame (corrupt stack?) (gdb) kill Kill the program being debugged? (y or n) y (gdb) -------- $ emerge --info Portage 2.0.51.19 (default-linux/ppc/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11 ppc) ================================================================= System uname: 2.6.11 ppc 7447A, altivec supported Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 12 2005, 13:40:52)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.90.0.3-r4 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -mcpu=7400 -maltivec -mabi=altivec" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /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/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -mcpu=7400 -maltivec -mabi=altivec" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks noclean sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.rhnet.is/pub/gentoo" LC_ALL="en_US.utf8" LINGUAS="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://ftp.rhnet.is/gentoo-portage" USE="ppc X aac aalib aim alsa altivec bash-completion berkdb bitmap-fonts bzlib cddb cdparanoia cdr cjk crypt cups curl directfb doc dvd eds emboss encode exif fam flac fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile icq imagemagick imlib innodb ipv6 jabber jpeg jpeg2k kde latex libwww mad matroska motif mozilla mozsvg mp3 mpeg msn mysql ncurses network nls nodrm offensive ogg oggvorbis opengl oss pam pcre pdflib perl png postgres python qt readline rtc ruby samba sdl speex spell ssl svg tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode v4l v4l2 vorbis xine xml xml2 xmms xprint xv xvid yahoo zeroconf zlib linguas_en_US.utf8 userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LDFLAGS
And I can confirm that doing `emerge libsigc++ glibmm` fixes the problem, note that it didn't work until glibmm had finished merging so it's probably the culprit.
Did you just reemerged gtkmm or upgraded to specyficated version?
This is a common problem, and the root cause is a change in gcc's C++ ABI, that causes those three C++ libs to link wrongly with Inkscape. Unfortunately, this is not really something that can be addressed by the Inkscape developers or even by the gcc developers. Ideally, portage should be able to detect the versions of gcc used to compile the different components, and if they don't match, to recompile things as needed.
This bug can probably be closed now...
(In reply to comment #8) > This bug can probably be closed now... Yes, seems so...
*** Bug 112698 has been marked as a duplicate of this bug. ***
*** Bug 113594 has been marked as a duplicate of this bug. ***
*** Bug 119621 has been marked as a duplicate of this bug. ***
