Compiling Inkscape CVS on Solaris 2.8
Hi,
I'm trying to compile inkscape-20040527 with gcc (GCC) 3.3.2 on a SunOS foo 5.8 Generic_108528-22 sun4u sparc SUNW,Sun-Fire-V240 machine.
I had to fix a few things:
Use <inttypes.h>, not <stdint.h> in src/display/sp-canvas.h, src/livarot/DblLinked.h, src/livarot/LivarotDefs.h, src/livarot/AVL.h, src/livarot/Shape.h, src/livarot/ShapeUtils.h, src/livarot/Ligne.h (see http://www.lns.cornell.edu/public/COMP/info/autoconf/Header-Portability.html)
Replace round() with rint() according to http://news.gw.com/freebsd.gnome/1237 in src/object-edit.cpp, src/spiral-context.cpp
fabsf() was undeclared (I just put in "fabs()", not sure if this is correct) in src/sp-shape.cpp (see http://gcc.gnu.org/ml/java/2001-01/msg00465.html).
I could make a patch for these changes if wanted.
Now, with the following error, I assume it happens because the Makefile is using Solaris' as instead of GNU's "gas":
In file included from style.h:19, from sp-typeset-kplayout.cpp:26: sp-marker.h: In member function `SPMarker* SPMarkerReference::getObject() const ': sp-marker.h:94: warning: cast from `SPObject*' to `SPMarker*' increases required alignment of target type In file included from sp-typeset-kplayout.cpp:30: sp-use.h: In member function `SPItem* SPUseReference::getObject() const': sp-use.h:25: warning: cast from `SPObject*' to `SPItem*' increases required alignment of target type sp-typeset-kplayout.cpp: In function `void sp_typeset_rekplayout(SPTypeset*)': sp-typeset-kplayout.cpp:325: warning: cast from `GTypeInstance*' to `SPTypeset* ' increases required alignment of target type /usr/ccs/bin/as: "/var/tmp//ccUeTaeq.s", line 5631: error: constant value must be between -4096 and 4095 gmake: *** [sp-typeset-kplayout.o] Error 1
(I include some of the warnings I get for virtually every file for good measure :)
I have stopped here for today since I didn't find the "as" call immediately; I hope the above is helpful for portabilty. Hints about the as/gas problem are appreciated.
Cheers, Colin
On Mon, 2004-06-07 at 15:48, Colin Marquardt wrote:
I had to fix a few things:
Use <inttypes.h>, not <stdint.h> in src/display/sp-canvas.h, src/livarot/DblLinked.h, src/livarot/LivarotDefs.h, src/livarot/AVL.h, src/livarot/Shape.h, src/livarot/ShapeUtils.h, src/livarot/Ligne.h (see http://www.lns.cornell.edu/public/COMP/info/autoconf/Header-Portability.html)
Done in CVS.
Replace round() with rint() according to http://news.gw.com/freebsd.gnome/1237 in src/object-edit.cpp, src/spiral-context.cpp
I've replaced these with the sp_round() macro in use elsewhere (for consistency).
fabsf() was undeclared (I just put in "fabs()", not sure if this is correct) in src/sp-shape.cpp (see http://gcc.gnu.org/ml/java/2001-01/msg00465.html).
The extra precision shouldn't hurt. Done.
I could make a patch for these changes if wanted.
If you find any more such issues, please do. ^_^ (sorry to deprive you of the opportunity this time around TT)
I really appreciate the effort and research you invested in this. ^_^
(I'll write about the remainder of the warnings in my next email)
-mental
On Mon, 2004-06-07 at 15:48, Colin Marquardt wrote:
Now, with the following error, I assume it happens because the Makefile is using Solaris' as instead of GNU's "gas":
In file included from style.h:19, from sp-typeset-kplayout.cpp:26: sp-marker.h: In member function `SPMarker* SPMarkerReference::getObject() const ': sp-marker.h:94: warning: cast from `SPObject*' to `SPMarker*' increases required alignment of target type In file included from sp-typeset-kplayout.cpp:30: sp-use.h: In member function `SPItem* SPUseReference::getObject() const': sp-use.h:25: warning: cast from `SPObject*' to `SPItem*' increases required alignment of target type sp-typeset-kplayout.cpp: In function `void sp_typeset_rekplayout(SPTypeset*)': sp-typeset-kplayout.cpp:325: warning: cast from `GTypeInstance*' to `SPTypeset* ' increases required alignment of target type
Egh. Alignment issues on Sparc could be a pain. Hopefully e.g. SPObject and SPItem do not really have such different alignment requirements (for individually allocated structures).
(it might be instructive to see what Glib/Gtk has to do in order to compile cleanly on this platform, since I would naively expect it to generate the same warnings)
Those warnings are not the result of the choice of assembler, anyway.
/usr/ccs/bin/as: "/var/tmp//ccUeTaeq.s", line 5631: error: constant value must be between -4096 and 4095 gmake: *** [sp-typeset-kplayout.o] Error 1
This one likely is, though I've no clue about its specifics. Can you paste some of the generated assembly?
I have stopped here for today since I didn't find the "as" call immediately; I hope the above is helpful for portabilty. Hints about the as/gas problem are appreciated.
Can you force it to use gas and see if things work otherwise?
-mental
(thanks for you answers)
MenTaLguY <mental@...3...> writes:
On Mon, 2004-06-07 at 15:48, Colin Marquardt wrote:
Now, with the following error, I assume it happens because the Makefile is using Solaris' as instead of GNU's "gas":
In file included from style.h:19, from sp-typeset-kplayout.cpp:26: sp-marker.h: In member function `SPMarker* SPMarkerReference::getObject() const ': sp-marker.h:94: warning: cast from `SPObject*' to `SPMarker*' increases required alignment of target type In file included from sp-typeset-kplayout.cpp:30: sp-use.h: In member function `SPItem* SPUseReference::getObject() const': sp-use.h:25: warning: cast from `SPObject*' to `SPItem*' increases required alignment of target type sp-typeset-kplayout.cpp: In function `void sp_typeset_rekplayout(SPTypeset*)': sp-typeset-kplayout.cpp:325: warning: cast from `GTypeInstance*' to `SPTypeset* ' increases required alignment of target type
Egh. Alignment issues on Sparc could be a pain. Hopefully e.g. SPObject and SPItem do not really have such different alignment requirements (for individually allocated structures).
(it might be instructive to see what Glib/Gtk has to do in order to compile cleanly on this platform, since I would naively expect it to generate the same warnings)
I don't remember seeing such warnings when compiling glib, gtk+ or gtkmm etc., indeed.
/usr/ccs/bin/as: "/var/tmp//ccUeTaeq.s", line 5631: error: constant value must be between -4096 and 4095 gmake: *** [sp-typeset-kplayout.o] Error 1
This one likely is, though I've no clue about its specifics. Can you paste some of the generated assembly?
The assembly seems to be generated only temporary, I haven't succeeded in capturing it.
I have stopped here for today since I didn't find the "as" call immediately; I hope the above is helpful for portabilty. Hints about the as/gas problem are appreciated.
Can you force it to use gas and see if things work otherwise?
The assembler executable seems to be a compile time option for gcc, and gcc was provided by the system, so I couldn't easily change that (maybe it's a run time option for gcc as well though, I didn't check).
Well, I got this file to compile, and that was by running the gcc invocation by hand, with the "-O2" option removed - this made the error go away.
My current state of affairs is documented in the Wiki: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape at the end.
It lists some more necessary changes in addition to the ones from my first mail (that you fixed in CVS as you wrote). As written there, I'm stuck here:
In file included from /home/foo/Tools/include/X11/extensions/Xrender.h:33, from /home/foo/Tools/include/X11/Xft/Xft.h:47, from libnrtype/nr-type-xft.cpp:16: /usr/openwin/include/X11/Xutil.h:56: warning: ignoring #pragma ident /usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is not defined as a type. /usr/openwin/include/X11/Xutil.h:120: error: 'Pixmap' is used as a type, but is not defined as a type. /usr/openwin/include/X11/Xutil.h:121: error: 'Window' is used as a type, but is not defined as a type. [...]
I had simply installed libxrender as it was missing, and it compiled cleanly. That was probably a bit simpleminded... :)
I'm not an admin on that machine, and I guess me switching to XFree86 is out of the question. Any other possibilities?
I'll be away until Sunday with little connectivity - I'll try to check the mailing list and the Wiki every once in a while though.
Cheers, Colin
On Wed, 2004-06-09 at 14:42, Colin Marquardt wrote:
/usr/ccs/bin/as: "/var/tmp//ccUeTaeq.s", line 5631: error: constant value must be between -4096 and 4095 gmake: *** [sp-typeset-kplayout.o] Error 1
This one likely is, though I've no clue about its specifics. Can you paste some of the generated assembly?
The assembly seems to be generated only temporary, I haven't succeeded in capturing it.
Try the -save-temps option; it should preserve all of the intermediate files (the assembly should be in sp-typeset-kplayout.s).
I have stopped here for today since I didn't find the "as" call immediately; I hope the above is helpful for portabilty. Hints about the as/gas problem are appreciated.
Can you force it to use gas and see if things work otherwise?
The assembler executable seems to be a compile time option for gcc, and gcc was provided by the system, so I couldn't easily change that (maybe it's a run time option for gcc as well though, I didn't check).
I just checked; there is apparently no commandline option for it. :/
We will have to see what we can do to make 'as' work.
Well, I got this file to compile, and that was by running the gcc invocation by hand, with the "-O2" option removed - this made the error go away.
Hmm. I guess gcc tries something too clever for 'as' when optimization is enabled. It's probably a specific optimzation that we can turn off if we can determine which one is triggering the problem.
My current state of affairs is documented in the Wiki: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape at the end.
It lists some more necessary changes in addition to the ones from my first mail (that you fixed in CVS as you wrote).
Could you please prepare a patch for the various floating-point things?
In file included from /home/foo/Tools/include/X11/extensions/Xrender.h:33, from /home/foo/Tools/include/X11/Xft/Xft.h:47, from libnrtype/nr-type-xft.cpp:16: /usr/openwin/include/X11/Xutil.h:56: warning: ignoring #pragma ident /usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is not defined as a type. /usr/openwin/include/X11/Xutil.h:120: error: 'Pixmap' is used as a type, but is not defined as a type. /usr/openwin/include/X11/Xutil.h:121: error: 'Window' is used as a type, but is not defined as a type. [...]
I'm not an admin on that machine, and I guess me switching to XFree86 is out of the question. Any other possibilities?
Most likely you will need to include another X11 header before including Xft.h (XFree86's Xutil.h probably includes it automatically, whereas Solaris' does not).
So, that one should simply be a matter of adding the right #includes.
I am guessing X11/X.h and X11/Xdefs.h should be sufficient.
-mental
/usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is [...]
Most likely you will need to include another X11 header before including Xft.h (XFree86's Xutil.h probably includes it automatically, whereas Solaris' does not).
If there's no documentation saying what header needs to be #included before Xutil.h, then please consider filing a bug report with the provider of that Xutil.h file. Also consider filing a bug report against Xft, especially if it can be handled relatively unobtrusively (without #if).
pjrm.
Peter Moulder <Peter.Moulder@...38...> writes:
/usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is [...]
Most likely you will need to include another X11 header before including Xft.h (XFree86's Xutil.h probably includes it automatically, whereas Solaris' does not).
If there's no documentation saying what header needs to be #included before Xutil.h, then please consider filing a bug report with the provider of that Xutil.h file. Also consider filing a bug report against Xft, especially if it can be handled relatively unobtrusively (without #if).
Xutil.h told me to include <X11/Xlib.h> - should I report that against Xft then? I'm not sure if it could do harm to always include it...
Cheers, Colin
On Mon, 2004-06-14 at 18:36, Colin Marquardt wrote:
Peter Moulder <Peter.Moulder@...38...> writes:
/usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is [...]
Most likely you will need to include another X11 header before including Xft.h (XFree86's Xutil.h probably includes it automatically, whereas Solaris' does not).
If there's no documentation saying what header needs to be #included before Xutil.h, then please consider filing a bug report with the provider of that Xutil.h file. Also consider filing a bug report against Xft, especially if it can be handled relatively unobtrusively (without #if).
Xutil.h told me to include <X11/Xlib.h> - should I report that against Xft then? I'm not sure if it could do harm to always include it...
In this case I think it should be entirely safe for us to do.
Depending on whether these headers are historically properly armored, it may or may not be safe for Xft to do themselves.
So, fix it in Inkscape, and file a bug with Xft to do with as they will.
(actually, this may soon no longer be an issue, I think the new pango work is removing the usage of Xft altogether)
-mental
Hi,
first of all, I have Inkscape running under Solaris 2.8! Yay! :)
MenTaLguY <mental@...3...> writes:
On Wed, 2004-06-09 at 14:42, Colin Marquardt wrote:
/usr/ccs/bin/as: "/var/tmp//ccUeTaeq.s", line 5631: error: constant value must be between -4096 and 4095 gmake: *** [sp-typeset-kplayout.o] Error 1
This one likely is, though I've no clue about its specifics. Can you paste some of the generated assembly?
The assembly seems to be generated only temporary, I haven't succeeded in capturing it.
Try the -save-temps option; it should preserve all of the intermediate files (the assembly should be in sp-typeset-kplayout.s).
Did that, the result is at http://buug.de/~colin/sp-typeset-kplayout.s.bz2 (~100k, unpacked 600k)
FWIW, the section in question is
,---- | .LLEHB10: | call %g1, 0 | add %o7, (.LL171-.-4), %o7 `----
(the line with "add" is 5631)
,---- | $ /usr/ccs/bin/as -V | /usr/ccs/bin/as: Sun WorkShop 6 99/08/18 `----
Could you please prepare a patch for the various floating-point things?
Will do. I am pretty busy at work, but I'll try to have that by tomorrow.
In file included from /home/foo/Tools/include/X11/extensions/Xrender.h:33, from /home/foo/Tools/include/X11/Xft/Xft.h:47, from libnrtype/nr-type-xft.cpp:16: /usr/openwin/include/X11/Xutil.h:56: warning: ignoring #pragma ident /usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is not defined as a type. /usr/openwin/include/X11/Xutil.h:120: error: 'Pixmap' is used as a type, but is not defined as a type. /usr/openwin/include/X11/Xutil.h:121: error: 'Window' is used as a type, but is not defined as a type. [...]
I'm not an admin on that machine, and I guess me switching to XFree86 is out of the question. Any other possibilities?
Most likely you will need to include another X11 header before including Xft.h (XFree86's Xutil.h probably includes it automatically, whereas Solaris' does not).
So, that one should simply be a matter of adding the right #includes.
I am guessing X11/X.h and X11/Xdefs.h should be sufficient.
Right. The header of that file said
,---- | #pragma ident "@(#)Xutil.h 1.2 00/07/05 SMI" | | /* You must include <X11/Xlib.h> before including this file */ `----
so I did that, and all was fine. Cool.
I tweaked some more things as documented in the wiki, and in the end, Inkscape was running. Very nice.
I now produced a patch and applied it to the current CVS snapshot. It is still a painful thing to compile - starting with the autogen.sh run. Do you want me to report all things I encounter step by step?
Appended is a first part. I think I have already patched configure.in to use "ggrep" instead of Solaris' own "grep". I also defined AC_CONFIG_HEADERS instead of AM_CONFIG_HEADER. Unfortunately, I'm totally illiterate when it comes to the autotools...
Cheers, Colin
$ ./autogen.sh --prefix=/home/marquardt/Tools/ --includedir=/home/marquardt/Tools/include CPPFLAGS=-I/home/marquardt/Tools/include ============================================================================= When you report a trouble about building CVS version of inkscape, Please report following information about distro and tools version, too.
--1. distribution------------------------------------------------------------ ./distro: : cannot execute ./distro: syntax error at line 2: `emacs-21.3^V,¼§ unexpected egrep: syntax error Solaris 8
--2. tools------------------------------------------------------------------- which m4: /usr/ccs/bin/m4 m4: bad option: --version which autoconf: /home/marquardt/Tools/bin//autoconf autoconf (GNU Autoconf) 2.59 which autoheader: /home/marquardt/Tools/bin//autoheader autoheader (GNU Autoconf) 2.59 which automake: /home/marquardt/Tools/bin//automake automake (GNU automake) 1.8.3 which automake-1.7: no automake-1.7 in ... ./tools-version.sh: automake-1.7: not found which aclocal: /home/marquardt/Tools/bin//aclocal aclocal (GNU automake) 1.8.3 which aclocal-1.7: no aclocal-1.7 in ... ./tools-version.sh: aclocal-1.7: not found which intltoolize: /home/marquardt/Tools/bin//intltoolize intltoolize (GNU intltool) 0.30 which gettextize: /opt/sfw/bin/gettextize /opt/sfw/bin/gettextize (GNU gettext) 0.10.35 which libtoolize: no libtoolize in ... ./tools-version.sh: libtoolize: not found
--3. environment variables--------------------------------------------------- [...]
=============================================================================
I am testing that you have the required versions of libtool, autoconf, automake, glib-gettextize and intltoolize. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information...
-n checking for autoconf >= 2.52 ... yes (version 2.59) -n checking for automake >= 1.7 ... yes (version 1.8.3) -n checking for glib-gettextize >= 2.0.0 ... yes (version 2.4.2) -n checking for intltool >= 0.17 ... yes (version 0.30) ./autogen.sh: !: not found configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, configure.in: that aclocal.m4 is present in the top-level directory, configure.in: and that aclocal.m4 was recently regenerated (using aclocal). src/Makefile_insert:10: PLATFORM_WIN32 does not appear in AM_CONDITIONAL src/Makefile.am:17: `src/Makefile_insert' included from here src/Makefile_insert:15: INKJAR does not appear in AM_CONDITIONAL src/Makefile.am:17: `src/Makefile_insert' included from here src/extension/internal/Makefile_insert:16: USE_GNOME_PRINT does not appear in AM_CONDITIONAL src/Makefile.am:22: `src/extension/internal/Makefile_insert' included from here src/libnr/Makefile_insert:8: USE_MMX does not appear in AM_CONDITIONAL src/Makefile.am:25: `src/libnr/Makefile_insert' included from here src/libnrtype/Makefile_insert:8: USE_XFT does not appear in AM_CONDITIONAL src/Makefile.am:26: `src/libnrtype/Makefile_insert' included from here src/libnrtype/Makefile_insert:14: PLATFORM_WIN32 does not appear in AM_CONDITIONAL src/Makefile.am:26: `src/libnrtype/Makefile_insert' included from here src/Makefile.am: Assembler source seen but `CCAS' is undefined src/Makefile.am: src/Makefile.am: The usual way to define `CCAS' is to add `AM_PROG_AS' src/Makefile.am: to `configure.in' and run `aclocal' and `autoconf' again. src/Makefile.am: Assembler source seen but `CCASFLAGS' is undefined src/Makefile.am: src/Makefile.am: The usual way to define `CCASFLAGS' is to add `AM_PROG_AS' src/Makefile.am: to `configure.in' and run `aclocal' and `autoconf' again. /home/marquardt/Tools//share/automake-1.8/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /home/marquardt/Tools//share/automake-1.8/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL configure.in:7: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:17: error: possibly undefined macro: AM_PROG_CC_STDC configure.in:18: error: possibly undefined macro: AM_PROG_AS configure.in:26: error: possibly undefined macro: AC_PROG_LIBTOOL configure.in:59: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT configure.in:94: error: possibly undefined macro: AM_CONDITIONAL ./autogen.sh: libtoolize: not found Copying file po/Makefile.in.in
Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/marquardt/Tools//share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/.
$ ./configure --prefix=/home/marquardt/Tools/ --includedir=/home/marquardt/Tools/include CPPFLAGS=-I/home/marquardt/Tools/include checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 ./configure: AM_INIT_AUTOMAKE: command not found checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for library containing strerror... none required checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes ./configure: AM_PROG_CC_STDC: command not found ./configure: AM_PROG_AS: command not found checking how to run the C++ preprocessor... g++ -E checking for egrep... egrep checking for ANSI C header files... yes checking for ranlib... ranlib ./configure: AC_PROG_LIBTOOL: command not found checking GNU compiler version... 3.3.2 ./configure: AM_GLIB_GNU_GETTEXT: command not found checking for pkg-config... /home/marquardt/Tools/bin//pkg-config checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking for png_read_info in -lpng... yes checking png.h usability... yes checking png.h presence... yes checking for png.h... yes checking for freetype-config... /home/marquardt/Tools/bin//freetype-config checking for Win32 platform... no ./configure: line 3381: syntax error near unexpected token `AM_CONDITIONAL(PLATFORM_WIN32,' ./configure: line 3381: `AM_CONDITIONAL(PLATFORM_WIN32, test "$platform_win32" = "yes")'
On Mon, 2004-06-14 at 17:58, Colin Marquardt wrote:
Did that, the result is at http://buug.de/~colin/sp-typeset-kplayout.s.bz2 (~100k, unpacked 600k)
FWIW, the section in question is
,---- | .LLEHB10: | call %g1, 0 | add %o7, (.LL171-.-4), %o7 `----
(the line with "add" is 5631)
Hmm, that second argument to "add" looks really weird to me, though my assembly is admittedly rather rusty.
Anyone else know what that second argument means? (it looks like some kind of indirect addressing to me, but...)
Will do. I am pretty busy at work, but I'll try to have that by tomorrow.
Thanks~
I now produced a patch and applied it to the current CVS snapshot. It is still a painful thing to compile - starting with the autogen.sh run. Do you want me to report all things I encounter step by step?
Yes, please. Keep documenting this on the Wiki also, of course.
Appended is a first part. I think I have already patched configure.in to use "ggrep" instead of Solaris' own "grep". I also defined AC_CONFIG_HEADERS instead of AM_CONFIG_HEADER. Unfortunately, I'm totally illiterate when it comes to the autotools...
Unfortunately I think we do want to use AM_CONFIG_HEADER in this case. Have to look further into why it's not working out here.
Not having a working egrep is a bit frustrating, but perhaps something we can work around more neatly ... I don't think we absolutely need to use an extended regexp here, even if the equivalent standard regexp is more complex.
I'll have to look at the further errors later, since it's late and I'm about out of energy for the night.
-mental
MenTaLguY <mental@...3...> writes:
On Mon, 2004-06-14 at 17:58, Colin Marquardt wrote:
It is still a painful thing to compile - starting with the autogen.sh run. Do you want me to report all things I encounter step by step?
Yes, please. Keep documenting this on the Wiki also, of course.
Okay, here we go:
,---- | if ! $ACLOCAL $ACLOCAL_FLAGS; then `----
as used in autogen.sh seems to be a bashism. Using bash in the shebang line, I get:
$ ./autogen.sh --prefix=/home/foo/Tools/ --includedir=/home/foo/Tools/include CPPFLAGS=-I/home/foo/Tools/include
I am testing that you have the required versions of libtool, autoconf, automake, glib-gettextize and intltoolize. This test is not foolproof, so if anything goes wrong, see the file HACKING for more information...
checking for autoconf >= 2.52 ... yes (version 2.59) checking for automake >= 1.7 ... yes (version 1.8.3) checking for glib-gettextize >= 2.0.0 ... yes (version 2.4.2) checking for intltool >= 0.17 ... yes (version 0.30) /home/foo/Tools//share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal /home/foo/Tools//share/aclocal/libart.m4:11: warning: underquoted definition of AM_PATH_LIBART src/Makefile.am:35: library used but `RANLIB' is undefined src/Makefile.am:35: src/Makefile.am:35: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB' src/Makefile.am:35: to `configure.in' and run `autoconf' again. ./autogen.sh: libtoolize: command not found Copying file po/Makefile.in.in
Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/foo/Tools//share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/.
Looks like a unified context diff. done
(I pruned the reporting stuff.)
That looked fairly okay so far, and I ran configure.
Isn't there a way to easily compile without intltool? I get ,---- | configure: error: XML::Parser perl module is required for intltool `----
and installing additional Perl modules is a pain here (especially if the installed Perl version is old).
I got around it by commenting out
,---- | intltoolize --copy --force --automake `----
in autogen.sh and
,---- | AC_PROG_INTLTOOL(0.22) `----
in configure.in.
Ah, and this left some line like "@INTLTOOL_...@" near the end of the Makefile which I commented out too.
Next thing was:
[...] rm -f libinkpre.a ar cru libinkpre.a arc-context.o attributes.o color.o desktop-affine.o desktop.o desktop-events.o desktop-handles.o desktop-snap.o dir-util.o document.o document-undo.o draw-context.o dropper-context.o dyna-draw-context.o event-context.o extract-uri.o file.o geom.o help.o inkscape.o inkscape-stock.o interface.o knot.o knotholder.o marker-status.o mod360.o node-context.o nodepath.o object-edit.o object-ui.o path-chemistry.o prefix.o prefs-utils.o print.o rect-context.o rubberband.o satisfied-guide-cns.o select-context.o selection-chemistry.o selection.o select-toolbar.o seltrans.o selcue.o seltrans-handles.o shortcuts.o slideshow.o sp-anchor.o sp-animation.o sp-chars.o sp-clippath.o sp-cursor.o sp-defs.o sp-ellipse.o sp-gradient.o sp-guide.o sp-image.o spiral-context.o sp-item.o sp-item-group.o sp-item-notify-moveto.o sp-item-rm-unsatisfied-cns.o sp-item-transform.o sp-item-update-cns.o sp-line.o splivarot.o sp-marker.o sp-mask.o sp-metrics.o sp-namedview.o sp-object.o sp-object-gro up .o sp-object-repr.o sp-offset.o sp-paint-server.o sp-path.o sp-pattern.o sp-polygon.o sp-polyline.o sp-rect.o sp-root.o sp-shape.o sp-spiral.o sp-star.o sp-symbol.o sp-text.o sp-typeset.o sp-typeset-layout.o sp-typeset-kplayout.o sp-typeset-utils.o sp-use.o star-context.o streams-gzip.o streams-handles.o streams-zlib.o streams-jar.o style.o svg-view.o text-context.o toolbox.o tools-switch.o uri.o uri-references.o verbs.o version.o view.o zoom-context.o libinkpre.a /bin/bash: ./libinkpre.a: Permission denied gmake[2]: *** [libinkpre.a] Error 126 gmake[2]: Leaving directory `/home/foo/Tools/inkscape-20040612_patched/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/foo/Tools/inkscape-20040612_patched' gmake: *** [all] Error 2
Looked in the Makefile, and it seems like $RANLIB is empty (as it said in the autogen.sh run). I just uncommented AC_PROG_RANLIB, reran all this again, and it worked. Any ideas why it's not picking up ranlib?
Next thing:
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/home/foo/Tools/include/gtk-2.0 -I/home/foo/Tools//lib/gtk-2.0/include -I/home/foo/Tools//include/atk-1.0 -I/home/foo/Tools//include/pango-1.0 -I/home/foo/Tools//include -I/home/foo/Tools//include/freetype2 -I/usr/openwin/include -I/home/foo/Tools//include/glib-2.0 -I/home/foo/Tools//lib/glib-2.0/include -I/home/foo/Tools/include/libxml2 -I/home/foo/Tools//lib/sigc++-1.2/include -I/home/foo/Tools//include/sigc++-1.2 -I/home/foo/Tools//include/gtkmm-2.4 -I/home/foo/Tools//lib/gtkmm-2.4/include -I/home/foo/Tools//include/glibmm-2.4 -I/home/foo/Tools//lib/glibmm-2.4/include -I/home/foo/Tools//include/gdkmm-2.4 -I/home/foo/Tools//lib/gdkmm-2.4/include -I/home/foo/Tools//include/pangomm-1.4 -I/home/foo/Tools//include/atkmm-1.6 -I/home/foo/Tools//include/sigc++-2.0 -I/home/foo/Tools//lib/sigc++-2.0/include -I/home/foo/T ools/include -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cpp; \ then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi main.cpp: In function `int main(int, const char**)': main.cpp:180: error: `bind_textdomain_codeset' undeclared (first use this function) main.cpp:180: error: (Each undeclared identifier is reported only once for each function it appears in.) main.cpp:230: error: `fpresetsticky' undeclared (first use this function) main.cpp: In function `int sp_main_gui(int, const char**)': main.cpp:251: error: `bind_textdomain_codeset' undeclared (first use this function) main.cpp: In function `int sp_main_console(int, const char**)': main.cpp:335: error: `bind_textdomain_codeset' undeclared (first use this function) gmake[2]: *** [main.o] Error 1 gmake[2]: Leaving directory `/home/foo/Tools/inkscape-20040612_patched/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/foo/Tools/inkscape-20040612_patched' gmake: *** [all] Error 2
I just defined bind_textdomain_codeset on my own (also had to do it in inkview.cpp). Is this resulting from my crude intltool surgery?
I just uncommented the fpresetsticky line and the one after it.
Unfortunately I think we do want to use AM_CONFIG_HEADER in this case. Have to look further into why it's not working out here.
Hmm, I don't see this error now... maybe it was a bashism too? Though I cannot see why/how... Need to check.
Cheers, Colin
On Tue, 2004-06-15 at 16:12, Colin Marquardt wrote:
MenTaLguY <mental@...3...> writes:
Could you please prepare a patch for the various floating-point things?
Attached. There will probably some rejects where you already fixed stuff.
Cheers, Colin
Sorry for the delay; I've been kinda buried this week.
I tried applying the patch, but my system seems to be lacking an ieeefp.h. Is there a more portable equivalent?
-mental
participants (3)
-
Colin Marquardt -
MenTaLguY -
Peter Moulder