Inkscape

[Armagon]

Update: Feb 27, 2006

I've got inkscape compiled and packaged up.  See post 18

-------------------------------------------------------------------------

Greetings.  

I thought inkscape ( http://www.inkscape.org/ ) would be great to run on the Z.  I even tried version 0.38 under OZ/GPE.  Unfortunately, 1) I didn't like GPE as much as pdaXrom, 2) the toolbars don't all fit on the screen on my C1000, 3) it was slow, and 4) it didn't have the latest and greatest features.

I thought I could resolve the issues by 1) (cross-)compiling for pdaXrom, 2) resizing the toolbar icon art, 3) hoping the floating-point emulation would help, and look into reducing the rendering quality, and 4) by compiling version 0.43.

Despite being a C++ programmer, I'm new to building (and especially cross-compiling) under linux [and I'd really like to thank the person who put up cross-compiler how-to at http://mail.pdaxrom.org/contrib/docs/cross-compiler.html ].

I downloaded the tarball source packages that inkscape said it needed [see http://wiki.inkscape.org/wiki/index.php/CompilingInkscape ] and built Boehm-GC and libSigc++.  I had problems with GlibMM (and haven't tried GtkMM yet).  They seem to be relying on the PKG_CONFIG_PATH environment variable, which I thought I set appropriately...

What is worse, though, is the other dependancies:  

configure: error: Package requirements (sigc++-2.0 >= 2.0.0 glib-2.0 >= 2.8.0 gobject-2.0 >= 2.8.0 gmodule-2.0 >= 2.8.0) were not met.

It appears to me, by looking at this list of everything available at the pdaXrom site ( http://mail.pdaxrom.org/contrib/list.txt ), that glib is at version 1.2, and that gobject, and gmodule are currently unavailable.

So, am I just better off forgetting about trying to compile inkscape?  I get the impression that a whole bunch of gnome libraries need to be compiles, and balk at the thought.

Or, is there some miraculous developer out there to whom these tasks do not seem insurmountable?  Or is it not as bad as it seems to me?

Thanks for your insights,
Armagon

[desertrat]

I thought inkscape ( http://www.inkscape.org/ ) would be great to run on the Z.  I even tried version 0.38 under OZ/GPE.  Unfortunately, 1) I didn't like GPE as much as pdaXrom, 2) the toolbars don't all fit on the screen on my C1000, 3) it was slow, and 4) it didn't have the latest and greatest features.

You can try running the Debian version. I did once and found it too slow, plus it and its dependencies used at least 57MB, so I uninstalled it

-- cheers

[pgas]

note that the list on the contrib site list only the contributed packages
here:
http://mail.pdaxrom.org/1.1.0beta1/Zaurus-7x0-860/feed/
you'll find:
glib2_2.8.1-1_armv5tel.ipk

[Armagon]

I thought inkscape ( http://www.inkscape.org/ ) would be great to run on the Z.  I even tried version 0.38 under OZ/GPE.  Unfortunately, 1) I didn't like GPE as much as pdaXrom, 2) the toolbars don't all fit on the screen on my C1000, 3) it was slow, and 4) it didn't have the latest and greatest features.

You can try running the Debian version. I did once and found it too slow, plus it and its dependencies used at least 57MB, so I uninstalled it

-- cheers
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115205\"][{POST_SNAPBACK}][/a][/div]

Wow.  That is a bit much.

How did you like Pocket Debian?

[Armagon]

note that the list on the contrib site list only the contributed packages

Oh.  Thanks for letting me know.

here:
http://mail.pdaxrom.org/1.1.0beta1/Zaurus-7x0-860/feed/
you'll find:
glib2_2.8.1-1_armv5tel.ipk
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115209\"][{POST_SNAPBACK}][/a][/div]

Excellent.

I should add that I really don't have much time, and will only be working on this on and off, slowly ...  (Sigh)

[koen]

If you are cross compiling you'll probably need this patch: http://dominion.kabel.utwente.nl/koen/pda/...ion-check.patch
That's all I needed to crosscompile it.

[Armagon]

If you are cross compiling you'll probably need this patch: http://dominion.kabel.utwente.nl/koen/pda/...ion-check.patch
That's all I needed to crosscompile it.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Thank you so much, koen, I really appreciate that.

I dare say that my hopes were high with the statement "that's all I needed to crosscompile it", and with a name of "no-boehm-version-check.patch" -- I thought that might be all that I'd need and I could miraculously avoid having to compile and link in a whole bunch of libraries. [Yes, I see now that I was wrong.]

I freshly extracted the inkscape-0.43 source, and applied the patch.  Then I tried to configure it:

./configure --host=armv5tel-cacko-linux --build=i686-linux --prefix=$HOME/Zaurus/Cross/install

the configuration went along for a while, and terminated with:

configure: error: libgc (the Boehm Conservative Collector) 6.4+, is needed to compile inkscape -- [a href=\"http://www.hpl.hp.com/personal/Hans_Boehm/gc]http://www.hpl.hp.com/personal/Hans_Boehm/gc[/url]

Ah.  Thus I see the need for the patch.  I tried applying the patch again, but patch asked me what on earth I was thinking -- the file was already patched.

I tried with a slightly different command line, as the dependancies I have built are in $HOME/Zaurus/Cross/install:

CPPFLAGS=-I$HOME/Zaurus/Cross/install/include LDFLAGS=-L$HOME/Zaurus/Cross/install/lib ./configure --host=armv5tel-cacko-linux --build=i686-linux --prefix=$HOME/Zaurus/Cross/install

 
This time I got a little bit further, with:

checking gc.h usability... yes
checking gc.h presence... yes
checking for gc.h... yes
checking for GC_init in -lgc... no
checking for GC_malloc in -lgc... yes
checking libgc version 6.4+... configure: error: cannot run test program while cross compiling
See `config.log' for more details.

I looked at the config.log, especially near the end, and I couldn't make out anything there that had to do with the error, aside from the actual error message on line 1045. [I have attached the file to this post.]

I 'kompare'd the patched configure.ac to a pristine copy, and the patch looks good to me (although this is the first time I've ever looked at an autoconfiguration file.)

Any thoughts?

Thank you,
Armagon

[pgas]

the configure.ac is used to generate the configure script.
So you probably need to either recreate the configure script
or patch directly the configure script that comes with the sources.

http://www.gnu.org/software/autoconf/manua...f_13.html#SEC13

[Armagon]

the configure.ac is used to generate the configure script.
So you probably need to either recreate the configure script
or patch directly the configure script that comes with the sources.

http://www.gnu.org/software/autoconf/manua...f_13.html#SEC13
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115672\"][{POST_SNAPBACK}][/a][/div]

Oh.  Thanks pgas.  It hadn't occured to me that I'd need to recreate the configure script.  [Talk about getting a crash-course in cross-compiling -- ./configure doesn't automagically recreate itself.  Hmm...  Of course not -- I am a programmer -- I really should've known better.]

I tried:

autoconf

and got:

autom4te: need GNU m4 1.4 or later: /opt/native/i686/3.4.5-2.2.5/bin/m4

performing "which" on autoconf, autom4te, and m4, I got:

/opt/cross/arm/3.4.5-xscale-softvfp/bin/autoconf
/opt/cross/arm/3.4.5-xscale-softvfp/bin/autom4te
/usr/bin/m4

I was all set to upgrade my version of m4, but saw that the error occured while looking for an m4 in the native sdk (in /opt/native/i686/3.4.5-2.2.5/bin/m4), while I am using the cross-sdk.

Is there any way I can fix this, or should I just go on to pgas' next suggestion, and try patching the configure file itself?

Oh, and BTW, how do you do a meaningful forum search for 'm4'?  I got a whole bunch of hits that didn't look useful (and only one hit came up for 'autom4te').

Thanks,
Armagon

[desertrat]

I was all set to upgrade my version of m4, but saw that the error occured while looking for an m4 in the native sdk (in /opt/native/i686/3.4.5-2.2.5/bin/m4), while I am using the cross-sdk.

Is there any way I can fix this, or should I just go on to pgas' next suggestion, and try patching the configure file itself?

Strange, see my bug report and quick fix here:

http://www.pdaxrom.org/buglist.php?doactio...owbug&bugid=352

-- cheers

[Armagon]

Strange, see my bug report and quick fix here:

http://www.pdaxrom.org/buglist.php?doactio...owbug&bugid=352

-- cheers
[div align=\"right\"][a href=\"index.php?act=findpost&pid=115803\"][{POST_SNAPBACK}][/a][/div]

Thank you, desertrat:

M4=`which m4` autoconf

worked like a charm.

Ah.  And now, I just need to compile a whole bunch of dependancies:

configure: error: Package requirements (gdkmm-2.4  glibmm-2.4  gtkmm-2.4  gtk+-2.0 >= 2.4.0  libxml-2.0 >= 2.6.0  libxslt >= 1.0.15  sigc++-2.0 >= 2.0.3    gthread-2.0 >= 2.0) were not

Well, maybe "just" isn't quite the right word.  No wonder it took 57 MB for dependancies under pocket debian ...

Thank you so much -- I am certainly getting closer.
Amagon

[Armagon]

Way back in my first post, I said:

They seem to be relying on the PKG_CONFIG_PATH environment variable, which I thought I set appropriately...[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Boy, was I wrong.

So, for anyone else new to cross-compiling:

[a href=\"http://pkgconfig.freedesktop.org/wiki/FrontPage]pkg-config[/url] is a helper tool used when compiling applications and libraries. It helps you insert the correct compiler options on the command line so an application can use  gcc -o test test.c `pkg-config --libs --cflags glib-2.0`  for instance, rather than hard-coding values on where to find glib (or other libraries).

pkg-config does a lot of tedious work for you, to make it easier to compile something that uses libraries.  It uses .pc files, which (somehow) tell it where to find things.  However, you must tell it where to find the .pc files.  The PKG_CONFIG_PATH environment variable specifies this.  When you execute runsdk.sh, the smart people behind pdaXrom make it set that path to find all the libraries in the SDK.

If you compile some of your own libraries to link to, you need to add them to the path!  In my case, I'm installing cross-compiled modules into ~/Zaurus/Cross/install.  So, I need to do this after starting the sdk, if I want to configure or make anything that uses libraries I've compiled:

Code: [Select]

export PKG_CONFIG_PATH=~/Zaurus/Cross/install/lib/pkgconfig:$PKG_CONFIG_PATH

And lo! it works!  I'm able to compile and link with libraries!

Armagon

[koen]

Code: [Select]

export PKG_CONFIG_PATH=~/Zaurus/Cross/install/lib/pkgconfig:$PKG_CONFIG_PATH

And lo! it works!  I'm able to compile and link with libraries!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=116083\"][{POST_SNAPBACK}][/a][/div]

You might want to leave out the $PKG_CONFIG_PATH at the end, because that usually points to the .pc files for the host (e.g. x86 stuff).

[Armagon]

You might want to leave out the $PKG_CONFIG_PATH at the end, because that usually points to the .pc files for the host (e.g. x86 stuff).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=116116\"][{POST_SNAPBACK}][/a][/div]

That would definitely mess things up!

I just double checked, and get these results:

$ echo $PKG_CONFIG_PATH

$ /opt/cross/arm/3.4.5-xscale-softvfp/runsdk.sh
Type exit for leave armv5tel-cacko-linux cross environment.
$ echo $PKG_CONFIG_PATH
/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/lib/pkgconfig

Fortunately, on my machine, it did not include any paths to x86 libraries.  Presuming that that is the case for everybody, I believe it is important to append the original path, so that the SDK's libraries can be linked.  

Thanks,
Armagon

Edit: I just did one more test where I changed the PKG_CONFIG_PATH before running the SDK.  After initializing the SDK, the path contained the SDK's library path, and nothing else.

[macwiz]

Er... for those of us who are non-techies and would just like to draw with this application, is there any way you could build an ipk? It would be a really good app to have running on the Z.

I'd be asking for Scribus next, of course!

Thanks