If cairo (tried 1.0.0 and 1.0.2) is built on Solaris 9 for SPARC using gcc (tested 3.2.2) without the very rarely used option -mimpure-text to LDFLAGS, the linking fails like this: Text relocation remains referenced against symbol offset in file <unknown> 0x1968 /usr/local/lib/libz.a(inflate.o) <unknown> 0x196c /usr/local/lib/libz.a(inflate.o) <unknown> 0x1970 /usr/local/lib/libz.a(inflate.o) <unknown> 0x1974 /usr/local/lib/libz.a(inflate.o) <unknown> 0x1978 /usr/local/lib/libz.a(inflate.o) <unknown> 0x197c /usr/local/lib/libz.a(inflate.o) <snip> memset 0xb00 /usr/local/lib/libz.a(deflate.o) memset 0x1984 /usr/local/lib/libz.a(deflate.o) .udiv 0x1c4 /usr/local/lib/libz.a(deflate.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libcairo.la' Current working directory /usr/local/src/cairo-1.0.0/src *** Error code 1 make: Fatal error: Command failed for target `install-recursive' This odd error is documented on Solaris for other packages - e.g. http://groups.google.co.uk/group/comp.soft-sys.wxwindows/browse_frm/thread/c7b5ce9a61f75a23/f557930c0a369bb1?lnk=st&q=%22-mimpure-text%22+solaris&rnum=4&hl=en#f557930c0a369bb1 but in the 10+ years I have been running Solaris, it is the first time I have come across it, so it is very rare indeed. So I think it should be documented in the package, as being necessary (or at least may be necessary) on Solaris. I tried compiling with Sun's compiler too (see version below) sparrow /tmp/cairo-1.0.2 % cc -V cc: Sun WorkShop 6 update 2 C 5.3 Patch 111679-14 2004/02/20 usage: cc [ options] files. Use 'cc -flags' for details and it would not link. I expect there's an option on there which will allow a linking, but I don't know what it is and have not investigate. I would add cairo is still failing tests on Solaris, but at least it will compile and link with that option, which I think is only used on Solaris.
Isn't this in fact a matter of position independent code? Is /usr/local/lib/libz.a compiled by you? Can you try to build it as a shared object? Or at least instruct the compiler to generate PIC code (-fPIC/-fpic for gcc).
I'm confused by this bug simply because libtool is meant to isolate us from varied details of how to build shared libraries on all platforms. The "allocatable but non-writable sections" seems highly indicative of an issue with Position-Independent-Code and looks like an issue mixing shared-object code with a non-PIC archive library... Please forgive me if I'm wrong! Try building 1.8.0 and check that the current build system works for you.
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.