build problems on Solaris

[Eschrock1]

I managed to get inkscape 0.44 built under Solaris
Express build 40 (using gcc3.4.3), but needed the
following changes:

1. In 'src/display/bezier-utils.cpp', the code:

   #ifdef HAVE_IEEEFP_H
   # include <ieefp.h>
   #endif

   Should be <ieeefp.h>.

2. In 'src/dom/io/socket.cpp', I needed to include
   <sys/filio.h> in order to get the definition for
   FIONREAD.

3. Under the Solaris <math.h> header, isfinite() and
   friends are only defined if __C99FEATURES__ (a.k.a.
   -std=c99) is specified. But g++ doesn't set this
   #define, and refuses to honor '-std' declarations
   for C++. I worked around this by manually defining
   __C99FEATURES__ in my CPPFLAGS. I'm not convinced
   that this has anything to do with inkscape's build
   process, but thought it was worth mentioning.

- Eric

[Rwst (rwst)]

we have fixed (1) in svn so it will be in 0.44.1 and 0.45.
regarding (2), can you give us a macro defined on your kind
of system? I'm not sure what to do with (3) at the moment.

[Rwst (rwst)]

/wrt (2) see also
http://sourceforge.net/tracker/index.php?func=detail&aid=1370904&group_id=93438&atid=604306

where it is stressed that checking the __sun macro does not
suffice.

[Colin Marquardt (ubuntu-marquardt-home)]

FWIW, I tried under Solaris 8, and I also had to fix some of
the stuff above (looks like you got cleaner solutions). I
have written down my info in
http://wiki.inkscape.org/wiki/index.php/CompilingSunSolaris

[Rwst (rwst)]

the problem in gc.cpp you mention on the Wiki page appears
to be triggered by this code in the Boehm garbage collector:

extern "C" void GC_noop1(GC_word);

which appears to choke your compiler which is odd as gcc
should understand the 'extern "C"' construct, but maybe this
is because it's in a multiline macro. certainly something to
report upstream.

I think a workaround would be to go back to gc-6.6 but who
knows, the compiler appears to be special...

[Bug Importer (bug-importer)]

Thanks Ralf, I reported that to Hans Boehm a few days ago,
no answer yet.

libgc6.6 gives me a slightly different error:

gc.cpp: In function `void Inkscape::GC::<unnamed>::do_init()':
gc.cpp:32: error: ISO C++ forbids declaration of `end' with
no type
gc.cpp:32: error: ISO C++ forbids declaration of `etext'
with no type
gc.cpp:32: error: `GC_noop' undeclared (first use this function)
gc.cpp:32: error: (Each undeclared identifier is reported
only once for each
   function it appears in.)

(this is one reported already for 6.5 by someone else). If
you have more ideas, I'm eager to hear them.

[Colin Marquardt (ubuntu-marquardt-home)]

Ooops, if it wasn't obvious, this last comment was from me.

[Eschrock1 (eschrock1)]

Sorry for the late reply. Good to hear that #1 is fixed.
As for #2, I'm not sure what you mean by a "macro defined on
your kind of system". On Solaris (nevada, at least),
FIONREAD is defined in <sys/filio.h> as:

#define FIONREAD _IOR('f', 127, int) /* get #
bytes to read */

I imagine a feature test for something like HAVE_FILIO_H
would fix it right up.

I'm still trying to track down #3 with some standards gurus
from Solaris kernel development. I figure it's a bug in g++
(for not defining the appropriate macro) or the Solaris
headers (for not doing feature detection correctly). But
probably not Inkscape's fault.

I was able to build all the dependencies (including gc6.7,
not 6.6) without any problems. This on Solaris Nevada
build 42 with gcc and gmake, not Sun Studio.

- Eric

[Bryce Harrington (bryce)]

Originator: NO

eschrock1, could you give an update on this work? We're closing in on the
0.45 release and it would be nice to know if Inkscape 0.45 will build on
Solaris.

[Colin Marquardt (ubuntu-marquardt-home)]

Originator: NO

I am trying this as well, and I can say for now that autogen.sh doesn't
work for me - it uses e.g. /usr/ccs/bin/m4 which doesn't know the --version
option, ./distro doesn't work correctly, grep doesn't support the -e
option.

I'll try now with the configure file from the tarball, one could say that
we don't necessarily need to support Solaris with autogen.sh.

[Colin Marquardt (ubuntu-marquardt-home)]

Originator: NO

With gcc 3.3.2 on Solaris 8, I now get:

In file included from event-log.cpp:15:
util/ucompose.hpp: In member function `std::string
   UStringPrivate::Composition::stringify(T)':
util/ucompose.hpp:130: error: parse error before `=' token
util/ucompose.hpp: In member function `UStringPrivate::Composition&
   UStringPrivate::Composition::arg(const T&) [with T = Glib::ustring]':
event-log.cpp:269: instantiated from `Glib::ustring
String::ucompose(const Glib::ustring&, const T1&, const T2&) [with T1 =
Glib::ustring, T2 = Glib::ustring]'
event-log.cpp:270: instantiated from here
util/ucompose.hpp:174: error: `wstring' undeclared in namespace `std'
gmake[2]: *** [event-log.o] Error 1

http://www.jezuk.co.uk/cgi-bin/view/SAX/news?id=1489 says that some
toolchains on Solaris apparently do not support wstring :/
I might try getting a gcc 4.x, but it'll take a while.

[Colin Marquardt (ubuntu-marquardt-home)]

Originator: NO

FWIW, here is the relevant bug in the GCC bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4764

[vonHalenbach (lustik)]

number 3 seems to be fixed in gcc 4.1.1 . Could someone test if it now works?

[Tom Davidson (tjd-mit)]

Bryce mentions at bug 168969 that he thinks he fixed the std::wstring issue -- yet another reason for someone to have another try with this...

[Alex Valavanis (valavanisalex)]

Marking as "Fix Released", based on earlier comments and lack of further feedback.