bug-ghostscript
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 9.04.1: build issues


From: Didier LINK
Subject: Re: 9.04.1: build issues
Date: Wed, 4 Jan 2012 15:05:41 +0100


> Hello,

Hello,

>
> Apologies if I am missing something evident.

No problem ;)

>
> Just built 9.04.1 and found the following problems.
>
> 1. There is no local lcms[2] source (it is present in the GPL
> distribution): maybe this has to do with license issues?
>

In the GNUification process I've removed all included source tree from other 
free projects. They are some projects heavily modified by Artifex that need to 
stay in the tree like jasper, but the others are useless (maybe I'm wrong in 
this area but tests are OK on my computer).

> 2. At make time got:
>
> --------------8<---------------------
> ./base/gsicc_create.c:117:55: fatal error: icc34.h: No such file or
> directory
> compilation terminated.
> make[1]: *** [obj/gsicc_create_1.o] Error 1
> make[1]: Leaving directory
> `/home/balducci/tmp/install-us-d/gnu-ghostscript/gnu-ghostscript-9.0
> 4.1'
> --------------8<---------------------
>
> This looks related to lcms[2] missing. However, there is a
> .../toolbin/color/icc_creator/ICC_Creator/icc34.h which works.
> I worked around stuffing it into CFLAGS, but may be the build
> process should be fixed for this in some way
>
> 3. Then got:
>
> --------------8<---------------------
> gcc -m32 -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations
> -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing
> -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H
> -DGX_COLOR_INDEX_TYPE="unsigned long long"
> -I/home/balducci/tmp/install-us-d/gnu-ghostscript/gnu-ghostscript-9.
> 04.1/toolbin/color/icc_creator/ICC_Creator
> -I/usr/include/libpng12 -O2 -Wall -Wstrict-prototypes -Wundef
> -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings
> -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin
> -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long"
> -I/home/balducci/tmp/install-us-d/gnu-ghostscript/gnu-ghostscript-9.
> 04.1/toolbin/color/icc_creator/ICC_Creator
> -I/usr/include/libpng12 -I./base -I./obj/ -Isrc ./base/mkromfs.c -o
> ./obj/aux/mkromfs_1 ./obj/gscdefs.o ./obj/gsmisc.o ./obj/gpmisc.o
> ./obj/gslibctx.o ./obj/gp_getnv.o ./obj/gp_unix.o ./obj/gp_unifs.o
> ./obj/gp_unifn.o ./obj/gp_stdia.o ./obj/gsutil.o -lm -ldl -!
> lm -lidn -rdynamic -ldl -lfontconfig
> /usr/bin/ld: /tmp/ccoqbFsK.o: undefined reference to symbol 'compress'
> /usr/bin/ld: note: 'compress' is defined in DSO /lib/libz.so.1 so try adding 
> it
> to the linker command line
> /lib/libz.so.1: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> make[1]: *** [obj/aux/mkromfs_1] Error 1
> make[1]: Leaving directory
> `/home/balducci/tmp/install-us-d/gnu-ghostscript/gnu-ghostscript-9.0
> 4.1'
> --------------8<---------------------
>
> Apparently a -lz is missing. I don't know if this is due to some
> misconfiguration on my side (but my libz is in a very standard
> place) or it is something which needs to be fixed in the build
> process.
> For me, stuffing -lz into LIBS works around this problem.
>
> 4. Then got:
>
> --------------8<---------------------
> /usr/bin/ld: ./obj/fapi_ft.o: undefined reference to symbol
> 'FT_Matrix_Multiply'
> /usr/bin/ld: note: 'FT_Matrix_Multiply' is defined in DSO
> /usr/lib64/libfreetype.so.6 so try adding it to the linker command line
> /usr/lib64/libfreetype.so.6: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> --------------8<---------------------
>
> DITTO for -lfreetype. Again, appending -lfreetype to LIBS makes the
> build to proceed, but perhaps also this should be fixed in a more
> robust way...
>

I see a little problem in your settings, the compile line begin with : "gcc 
-m32" that is a classical multiarch compilation in 32bits for a 64bits 
plateform. And after the link edition step search for freetype in 64bits 
version ("/usr/lib64/libfreetype.so.6") !?

I think you have mixed a 32bits compilation that misses some 32bits headers 
with a link step in 64bits libraries. Or maybe a versions conflict between 
64bits header and 32bits library.

Can you send the config.log to my email address in attachment if you don't know 
how to solve the issue ? And can you add more informations about your system 
(architecture, compiler, libraries versions, etc etc).

>
> I hope to have been of some use
> and I thank you very much for your valuable work
>
> ciao
> gabriele
>

Thanks for the report, best regards.

Didier

--

Didier Link address@hidden
Jabber : address@hidden
MSN : address@hidden
SIP : address@hidden

Clé GPG : 75BAC9EE


--

Didier Link address@hidden
Jabber : address@hidden
MSN : address@hidden
SIP : address@hidden

Clé GPG : 75BAC9EE






reply via email to

[Prev in Thread] Current Thread [Next in Thread]