Bug 4120 - cairo doesn't build on solaris
Summary: cairo doesn't build on solaris
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 0.9.3
Hardware: SPARC Solaris
: high normal
Assignee: Billy Biggs
QA Contact: cairo-bugs mailing list
URL: http://trs80.ucc.asn.au/gnometinderbo...
Whiteboard:
Keywords:
: 4151 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-17 01:25 UTC by James Andrewartha
Modified: 2007-07-02 13:23 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description James Andrewartha 2005-08-17 01:25:28 UTC
cairo doesn't build on solaris 9 using gcc 3.4, including lots of fun errors
about visibility not supported and big endian not tested:

icstipple.c: In function `_cairo_pixman_transparent_span':
icstipple.c:78: warning: visibility attribute not supported in this
configuration; ignored
ic.c:151:3: warning: #warning "I havn't tested fbCompositeTrans_0888xnx0888() on
big endian yet!"
ic.c: In function `_cairo_pixman_composite_trans_0888xnx0888':
ic.c:1153: warning: 'rd' might be used uninitialized in this function

I think the visibility issues lead to:

/usr/ccs/bin/as: "/var/tmp//cc93Kj2y.s", line 4476: error: invalid operand
/usr/ccs/bin/as: "/var/tmp//cc93Kj2y.s", line 4477: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//cc93Kj2y.s", line 4479: error: redefinition of
symbol "_cairo_pixman_composite"
/usr/ccs/bin/as: "/var/tmp//cc93Kj2y.s", line 5291: error: statement syntax
Comment 1 Billy Biggs 2005-08-18 09:24:36 UTC
I'll take a look at fixing this up.
Comment 2 Owen Taylor 2005-08-20 05:35:12 UTC
*** Bug 4151 has been marked as a duplicate of this bug. ***
Comment 3 Roland Egger 2005-08-21 05:43:42 UTC
You can use a mapfile that declares symbols which should not
be exported.

Mapfile could look like e.g.:
{
  local:
    fftw_no_twiddle_1;
}


Then the linked lib linked with -Wl,-M <mapfile_name>
doesn't export fftw_no_twiddle_1 (hiding fftw_no_twiddle_1)

Perhaps that way of hiding symbols could be better.
Comment 4 Owen Taylor 2005-08-21 06:40:44 UTC
The marking of __attribute__((visbility("hidden")) actually generates
better code, which is the reason for adding it. There's logic in 
GLib's configure.in for detecting whether GCC supports it on a particular
platform that can be reused here.
Comment 5 Roland Egger 2005-08-22 12:28:41 UTC
At the moment I don't understand why hiding without mapfiles
produces better code but I haven't checked the details
and you are probably right.
For me it doesn't matter how it is done to correct it.
I'll just be happy if it works soon with a patch ;)

Comment 6 Carl Worth 2005-08-22 17:15:25 UTC
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
Comment 7 Billy Biggs 2005-08-22 18:50:24 UTC
I removed the big-endian warning since I don't think it was helping.

The use of the visibility attribute is protected like this inslim_internal.h:

#if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)) && defined(__ELF__)

The code from glib just checks whether the visibility attribute is supported at
all, which I guess is a bit more robust.
Comment 8 Roland Egger 2005-08-23 05:37:10 UTC
Maybe I understand a little bit more now. The glib checks in configure
if the compiler supports changing the vissibilty. If it doesn't support
it it will not be used.
So as a dirty temporary work around slim_internal.h could be changed
on Solaris 
from line 50
#if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)) && defined(__ELF__)
to
#if (__GNUC__ > 5 || (__GNUC__ == 5 && __GNUC_MINOR__ >= 3)) && defined(__ELF__)
and
line 8
#if __GNUC__ >= 3 && defined(__ELF__)
to
#if __GNUC__ >= 5 && defined(__ELF__)

I check for __GNUC__ > 5 because it's always false at the moment. 

Of course changing the configure.in like in glib would be the much better
but the symbols stay in both cases visible on Solaris which should be
hopefully no problem. If it's a problem then there's no workaround to
the mapfile solution at the moment.

After changing slim_internal.h I could compile some more files.
The next build error occured in

gcc -DHAVE_CONFIG_H -I. -I. -I.. -D_GNU_SOURCE -I. -I../pixman/src -I../src -
I../src -I/usr/local
/include -I/usr/local/include/libpng12 -I/usr/local/include -
I/usr/local/include/freetype2 -I/usr/
local/include -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -
Wmissing-declaration
s -Wnested-externs -fno-strict-aliasing -O3 -mcpu=ultrasparc -mv8plus -mvis -
funroll-loops -MT cai
ro-test.lo -MD -MP -MF .deps/cairo-test.Tpo -c cairo-test.c  -fPIC -DPIC -
o .libs/cairo-test.o
In file included from /usr/local/include/X11/extensions/Xrender.h:33,
                 from ../src/cairo-xlib-xrender.h:44,
                 from cairo-test.c:357:
/usr/include/X11/Xutil.h:117: error: parse error before "Bool"
/usr/include/X11/Xutil.h:120: error: parse error before "icon_pixmap"
/usr/include/X11/Xutil.h:121: error: parse error before "icon_window"
/usr/include/X11/Xutil.h:123: error: parse error before "icon_mask"
/usr/include/X11/Xutil.h:124: error: parse error before "window_group"
/usr/include/X11/Xutil.h:161: error: parse error before "Atom"

The cairo-xlib-xrender.h includes /usr/local/include/X11/extensions/Xrender.h
and that file includes  <X11/Xutil.h>. On Solaris Xutil.h needs Xlib.h to be
included before Xutil.h.
I changed 
#include <X11/extensions/Xrender.h>
to
#include <X11/Xlib.h>
#include <X11/extensions/Xrender.h>

Afterwards I can build the lib and the next error was in the test
directory

gcc -O3 -mcpu=ultrasparc -mv8plus -mvis -funroll-loops -mcpu=ultrasparc -
mv8plus -mvis -o .libs/imagediff 
imagediff.o  ./.libs/libcairotest.a ../src/.libs/libcairo.so -
L/usr/local/lib /usr/local/lib/libXrender.so -L/usr/local/BerkeleyDB.4.2/lib -
L/usr/local/ssl/lib -L/usr/openwin/lib -L/usr/lib -lX11 -
lpng12 /usr/local/lib/libfontconfig.so -
L/usr/openwin/lib /usr/local/lib/libexpat.so /usr/local/lib/libfreetype.so -lz -
lpthread -lm -R/export/home/admin/opt/graphik/lib -R/usr/local/lib
Undefined                       first referenced
 symbol                             in file
libiconv_open                       /usr/local/lib/libfontconfig.so
libiconv                            /usr/local/lib/libfontconfig.so
ld: fatal: Symbol referencing errors. No output written to .libs/imagediff

So -liconv is needed here. I added -liconv to the Makefile in the test 
directory.
=>
LIBS =  -lm -liconv
Afterwards the build finished and even make install succeeded
Comment 9 John Berger 2005-10-26 09:28:03 UTC
Since the previous poster did not really explain what he did (for those of us
who are not all that experienced with compiling) ...

1. Locate the LDFLAGS line in test/Makefile (I also did this in src/Makefile.in)
2. Add -liconv to the end of the line
3. Run configure even if you already did so
4. Run make clean if you already tried to compile
5. Run make

It will then compile correctly.

This is also used to solve the same problems with other packages as described in
bug 2775.   Basically, if you run into any libiconv "unreferenced symbol" error
regardless of the package that you're trying to compile, this seems to be what
you need to do to fix it.
Comment 10 James Andrewartha 2006-04-23 10:52:11 UTC
Ok, cairo builds successfully now:
http://jhbuild.bxlug.be/builds/2006-04-22-0008/logs/cairo-1-0/

There's still iconv issues, but I worked around them using the technique from
bug 2774 - export LDFLAGS='-L/opt/csw/lib -R/opt/csw/lib /opt/csw/lib/libiconv.so'
Comment 11 Kalle Vahlman 2007-07-02 13:23:12 UTC
According to comment 10, this bug has been fixed. The iconv issue looks like having been fixed too, and in any case is a problem in Fontconfig since Cairo doesn't touch iconv directly.

Thus, marking as FIXED.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.