confusion on the mandriva bug
Hi,
I posted a bug in the bug tracker few hours ago and it seems that there has been confusion with the post of Lucas Vieites. We are not the same person, but we have (almost) the same bug ! And the same system (Mandriva LE 2005)...
Personally, my crash is the following : __________________________________________________ /usr/bin/.proxy.inkscape: /usr/lib/libpng12.so.0: no version information available (required by /usr/bin/.proxy.inkscape)
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. Segmentation fault ______________________________________________________
Best,
luc estebanez
On Fri, 22 Jul 2005 20:28:44 +0200, estebane-EyLBDkQZtJX+PQtEYt2ulA wrote: posted a bug in the bug tracker few hours ago and it seems that there
has been confusion with the post of Lucas Vieites. We are not the same person, but we have (almost) the same bug ! And the same system (Mandriva LE 2005)...
The binary is dynamically linked to the GTKmm libraries, which is different to how I used to do it.
Aaron, are you using the same specfile I gave you? Could you post it here? The *MM libraries really do need to be statically linked (including libsigc++).
thanks -mike
Mike Hearn wrote:
On Fri, 22 Jul 2005 20:28:44 +0200, estebane-EyLBDkQZtJX+PQtEYt2ulA wrote:
posted a bug in the bug tracker few hours ago and it seems that there has been confusion with the post of Lucas Vieites. We are not the same person, but we have (almost) the same bug ! And the same system (Mandriva LE 2005)...
The binary is dynamically linked to the GTKmm libraries, which is different to how I used to do it.
Aaron, are you using the same specfile I gave you? Could you post it here? The *MM libraries really do need to be statically linked (including libsigc++).
Sure I can post it here. I may have screwed something up but I was pretty sure I only adjusted it to remove the paths that were specific to your system. For the sake of completeness, I have pasted below both the specfile I am using to build and the specfile you originally sent me in that order.
Aaron Spike
# autopackage specfile, (C) 2004 Mike Hearn <mike@...333...>
[Meta] RootName: @inkscape.org/inkscape:$SOFTWAREVERSION ShortName: inkscape DisplayName: Inkscape Vector Graphics Editor Summary: Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw and Visio SoftwareVersion: @VERSION@ Maintainer: The Inkscape team inkscape-devel@lists.sourceforge.net Packager: Aaron Spike <aaron@...749...> AutopackageTarget: 1.0
[Description] Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more.
[BuildPrepare] if [ ! -x configure ]; then ./autogen.sh fi export APBUILD_STATIC="popt gc gccpp" prepareBuild --enable-binreloc --with-gnome-vfs=no
[BuildUnprepare] unprepareBuild
[Imports] echo '*' | import # import everything
[Prepare] require @gnu.org/libstdc++ 3 require @xmlsoft.org/libxml2 2.6 require @xmlsoft.org/libxslt 1.0 require @gtk.org/gtk 2.4 # statically linked for now: require @rpm.org/popt 0.0 # statically linked: require @libsigc.sourceforge.net/libsigc 3 require @libpng.org/libpng 3 # statically linked: require @gtkmm.org/gtkmm2 3 require @zlib.org/zlib 1 # require @xfree86.org/xft 2 # require @freetype.org/freetype 6 # require @freedesktop.org/fontconfig 1
[Install] installExe bin/inkscape bin/inkview installMan 1 man/man1/* installIcon share/pixmaps/inkscape.png installDesktop "Graphics" share/applications/inkscape.desktop
copyFiles --nobackup share/locale $PREFIX/share copyFiles share/inkscape $PREFIX/share # copyFiles lib/inkscape $PREFIX/lib
[Uninstall] uninstallFromLog
==============================================================
# autopackage specfile, (C) 2004 Mike Hearn <mike@...333...>
[Meta] RootName: @inkscape.org/inkscape:$SOFTWAREVERSION ShortName: inkscape DisplayName: Inkscape Vector Graphics Editor Summary: Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw and Visio SoftwareVersion: @VERSION@ Maintainer: The Inkscape team inkscape-devel@lists.sourceforge.net Packager: Mike Hearn <mike@...333...> AutopackageTarget: 1.0
[Description] Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more.
[BuildPrepare] if [ ! -x configure ]; then ./autogen.sh fi export APBUILD_STATIC="popt=$source_dir/autopackage/libpopt.a gc gccpp" export LDFLAGS="-L/home/mike/static/lib" export PKG_CONFIG_PATH=/home/mike/static/lib/pkgconfig prepareBuild --enable-binreloc --with-gnome-vfs=no
[BuildUnprepare] unprepareBuild
[Imports] echo '*' | import # import everything
[Prepare] require @gnu.org/libstdc++ 3 require @xmlsoft.org/libxml2 2.6 require @xmlsoft.org/libxslt 1.0 require @gtk.org/gtk 2.4 # statically linked for now: require @rpm.org/popt 0.0 # statically linked: require @libsigc.sourceforge.net/libsigc 3 require @libpng.org/libpng 3 # statically linked: require @gtkmm.org/gtkmm2 3 require @zlib.org/zlib 1 # require @xfree86.org/xft 2 # require @freetype.org/freetype 6 # require @freedesktop.org/fontconfig 1
[Install] installExe bin/inkscape bin/inkview installMan 1 man/man1/* installIcon share/pixmaps/inkscape.png installDesktop "Graphics" share/applications/inkscape.desktop
copyFiles --nobackup share/locale $PREFIX/share copyFiles share/inkscape $PREFIX/share # copyFiles lib/inkscape $PREFIX/lib
[Uninstall] uninstallFromLog
On Sun, 24 Jul 2005 07:04:09 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
[BuildPrepare] if [ ! -x configure ]; then ./autogen.sh fi export APBUILD_STATIC="popt gc gccpp" prepareBuild --enable-binreloc --with-gnome-vfs=no
[BuildPrepare] if [ ! -x configure ]; then ./autogen.sh fi export APBUILD_STATIC="popt=$source_dir/autopackage/libpopt.a gc gccpp" export LDFLAGS="-L/home/mike/static/lib" export PKG_CONFIG_PATH=/home/mike/static/lib/pkgconfig prepareBuild --enable-binreloc --with-gnome-vfs=no
Ahh, I think that must be it - you removed the LDFLAGS/PKG_CONFIG_PATH variables for the static *mm builds but didn't add them to APBUILD_STATIC. I used custom paths in my old specfile because I didn't have root on the build system, but as you do you can ensure the static versions of GTKmm/sigc are available.
Try changing this line:
export APBUILD_STATIC="popt gc gccpp"
to
export APBUILD_STATIC="popt gc gccpp gtkmm-2.4 gdkmm-2.4 atkmm-1.6 pangomm-1.4 glibmm-2.4 sigc-2.0"
You will need to make sure you have .a files for each of those libraries. If you can get it up in the next couple of hours I can help test it again, otherwise I'll be off for a week. You can contact me at mike@...869... or on the autopackage forums/mailing list.
thanks -mike
Mike Hearn wrote:
Try changing this line:
export APBUILD_STATIC="popt gc gccpp"
to
export APBUILD_STATIC="popt gc gccpp gtkmm-2.4 gdkmm-2.4 atkmm-1.6 pangomm-1.4 glibmm-2.4 sigc-2.0"
You will need to make sure you have .a files for each of those libraries. If you can get it up in the next couple of hours I can help test it again, otherwise I'll be off for a week. You can contact me at mike@...869... or on the autopackage forums/mailing list.
I'm making a new package right now. In the last email I sent you I was trying something like this, but I noticed it didn't make the package size any larger. Could that be because I didn't append version numbers to the library names in that line? How do I know when I need to do that?
Aaron Spike
On Sun, 24 Jul 2005 07:27:41 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
I'm making a new package right now. In the last email I sent you I was trying something like this, but I noticed it didn't make the package size any larger. Could that be because I didn't append version numbers to the library names in that line? How do I know when I need to do that?
OK, here's a useful bit of shell script I use:
function needed() { objdump -x $1 | grep NEEDED; }
Whack that in your ~/.bashrc or something, then you can find out what libraries a binary needs by running "needed `which .proxy.inkscape`", for instance. On my system this gives the following result:
[mike@...628... main]$ needed /usr/bin/.proxy.inkscape NEEDED libpthread.so.0 NEEDED libgtkmm-2.4.so.1 NEEDED libgdkmm-2.4.so.1 NEEDED libatkmm-1.6.so.1 NEEDED libpangomm-1.4.so.1 NEEDED libglibmm-2.4.so.1 NEEDED libgtk-x11-2.0.so.0 NEEDED libgdk-x11-2.0.so.0 NEEDED libgdk_pixbuf-2.0.so.0 NEEDED libxml2.so.2 NEEDED libsigc-2.0.so.0 NEEDED libgthread-2.0.so.0 NEEDED libpng12.so.0 NEEDED libX11.so.6 NEEDED libfontconfig.so.1 NEEDED libpangoft2-1.0.so.0 NEEDED libpango-1.0.so.0 NEEDED libgobject-2.0.so.0 NEEDED libglib-2.0.so.0 NEEDED libfreetype.so.6 NEEDED libz.so.1 NEEDED libstdc++.so.5 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6
Incidentally, it's curious that a proxy file is generated. Normally that's only done when there's a program with that name already in the PATH. But for me there wasn't. Hmm.
Anyway. You can see here that the *mm libraries are dynamically linked. To statically link them, we firstly chop off the leading lib prefix, then drop the .so suffix and anything after that:
libgtkmm-2.4.so.1 -> gtkmm-2.4
We also need to make sure there's a .a file for everything we statically link:
[mike@...628... main]$ file /usr/lib/libgtkmm-2.4.a /usr/lib/libgtkmm-2.4.a: current ar archive
So we can statically link this by putting in gtkmm-2.4
thanks -mike
Mike Hearn wrote:
On Sun, 24 Jul 2005 07:27:41 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
I'm making a new package right now. In the last email I sent you I was trying something like this, but I noticed it didn't make the package size any larger. Could that be because I didn't append version numbers to the library names in that line? How do I know when I need to do that?
OK, here's a useful bit of shell script I use:
function needed() { objdump -x $1 | grep NEEDED; }
Whack that in your ~/.bashrc or something, then you can find out what libraries a binary needs by running "needed `which .proxy.inkscape`", for instance. On my system this gives the following result:
Incidentally, it's curious that a proxy file is generated. Normally that's only done when there's a program with that name already in the PATH. But for me there wasn't. Hmm.
I don't have a .proxy.* file here.
Anyway. You can see here that the *mm libraries are dynamically linked. To statically link them, we firstly chop off the leading lib prefix, then drop the .so suffix and anything after that:
libgtkmm-2.4.so.1 -> gtkmm-2.4
We also need to make sure there's a .a file for everything we statically link:
[mike@...628... main]$ file /usr/lib/libgtkmm-2.4.a /usr/lib/libgtkmm-2.4.a: current ar archive
So we can statically link this by putting in gtkmm-2.4
Excellent tutorial, thank you. I'm almost not confused anymore. So what this all means is that the gtkmm-dev package in Ubuntu doesn't include the *.a files. I guess I need to build that myself then (using apbuild?). That being the case I won't have this package up in the next few hours for you to test. What else do you do when you test the package?
Anything else I should know?
Aaron Spike
On Sun, 24 Jul 2005 08:04:26 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
Excellent tutorial, thank you. I'm almost not confused anymore. So what this all means is that the gtkmm-dev package in Ubuntu doesn't include the *.a files. I guess I need to build that myself then (using apbuild?).
That's crap :( I checked with some guys in #ubuntu and they say the older gtkmm packages *did* ship the .a files, but libgtkmm-2.4-dev doesn't! Weird or what. Especially as the Debian library packaging guide says to ship them.
Yeah, for now I guess compiling GTKmm from the source will do the trick. I'll dig a bit and see if I can find out why Ubuntu is being messed up here.
That being the case I won't have this package up in the next few hours for you to test. What else do you do when you test the package?
Normally I install it onto my system and try it out (after making sure it's "clean", ie no source/cvs compiles of anything lying around). Then I get other people to test it on IRC - but really what you're doing here with asking people to test it is good.
It's also worth running "objdump -x $1 |grep NEEDED" on the final binaries to make sure the dependencies look like what you'd expect.
thanks -mike
Mike Hearn wrote:
On Sun, 24 Jul 2005 08:04:26 -0500, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
Excellent tutorial, thank you. I'm almost not confused anymore. So what this all means is that the gtkmm-dev package in Ubuntu doesn't include the *.a files. I guess I need to build that myself then (using apbuild?).
That's crap :( I checked with some guys in #ubuntu and they say the older gtkmm packages *did* ship the .a files, but libgtkmm-2.4-dev doesn't! Weird or what. Especially as the Debian library packaging guide says to ship them.
Yeah, for now I guess compiling GTKmm from the source will do the trick. I'll dig a bit and see if I can find out why Ubuntu is being messed up here.
I think I need another hint. I found that I was also missing libglibmm-2.4.a, so I built and installed that. But autopackage still doesn't link it in to my package. The rest of gtkmm is working properly now.
Aaron Spike
On Sun, Jul 24, 2005 at 12:44:29PM +0100, Mike Hearn wrote:
Aaron, are you using the same specfile I gave you? Could you post it here? The *MM libraries really do need to be statically linked (including libsigc++).
Here's every step I used to create the static gtkmm libraries (and deps):
http://www.inkscape.org/cgi-bin/wiki.pl?CompilingStatic
participants (4)
-
unknown@example.com
-
Aaron and Sarah Spike
-
Kees Cook
-
Mike Hearn