GNOME Bugzilla – Bug 323553
2.6.22 PLUS 2.6.16 wouldn't compile on AIX 4.3.3
Last modified: 2008-06-19 20:54:24 UTC
Distribution/Version: 4.3.3 I was wanting to compile the 2.6.22 for PHP5 use on an AIX 4.3.3 system w/ VAC 4.4.0.3. My configure was: $ ./configure --prefix=/usr/local This seems to run ok but then when we get to compiling the parser.c it has a lot of 'Operation between types "unsigned char* and "const unsigned char*" is not allowed." '... but I added -w to CFLAGS to quiet those but I'm still left with this error. Running make: Target "all" is up to date. Making all in . source='parser.c' object='parser.lo' libtool=yes DEPDIR=.deps depmode=a ix /bin/sh ./depcomp /bin/sh ./libtool --mode=compile --tag=CC /usr/bin/cc_r -D HAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g -w -c -o parser.lo parser.c /usr/bin/cc_r -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g -w -c -M parser.c -DPIC -o .libs/parser.o "parser.c", line 1381.1: 1506-343 (S) Redeclaration of namePop differs from prev ious declaration on line 504 of "./include/libxml/parserInternals.h". "parser.c", line 2571.1: 1506-343 (S) Redeclaration of xmlParseName differs from previous declaration on line 348 of "./include/libxml/parserInternals.h". "parser.c", line 3986.1: 1506-343 (S) Redeclaration of xmlParsePITarget differs from previous declaration on line 370 of "./include/libxml/parserInternals.h". "parser.c", line 6948.1: 1506-343 (S) Redeclaration of xmlParseAttribute differs from previous declaration on line 420 of "./include/libxml/parserInternals.h". "parser.c", line 7037.1: 1506-343 (S) Redeclaration of xmlParseStartTag differs from previous declaration on line 423 of "./include/libxml/parserInternals.h". "parser.c", line 8728.1: 1506-343 (S) Redeclaration of xmlParseEncodingDecl diff ers from previous declaration on line 440 of "./include/libxml/parserInternals.h ". make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. I looked at where those functions are implemented in parser.c and they look like they appear in the parserInternals.h so I'm not sure why they differ. I'm not really good with C though so it could be obvious and I'm not seeing it. I'll keep looking into it and try somethings and if I find anything I'll let you know. I might try the GNU compiler but I've had problems where one library is compiled with gcc and another with vac cc. I didn't find anything similiar on the mailing list or bug reports. Thanks, Todd
I got it to compile seemly ok but only after I removed the const from the parserInternals.h problem functions. This may likely not be the right way to 'fix' it but it fails only on one test: ## Schemas regression tests Error for ./test/schemas/derivation-ok-extension_0.xml on ./test/schemas/derivat ion-ok-extension_0.xsd failed What was found it the results/schema were these file w/ content. derivation-ok-extension_0_0.err: ./test/schemas/derivation-ok-extension_0.xsd:10: element attribute: Schemas pars er warning : Element '{http://www.w3.org/2001/XMLSchema}attribute': Attribute us e prohibitions are pointless when extending a type. derivation-ok-extension-err_0_0.err: ./test/schemas/derivation-ok-extension-err_0.xsd:9: element attribute: Schemas p arser error : local complex type, attribute decl. 'barA_1': Duplicate attribute use specified. derivation-ok-restriction-2-1-1_0_0.err: ./test/schemas/derivation-ok-restriction-2-1-1_0.xsd:6: element complexType: Sch emas parser error : local complex type: A matching attribute use for the 'requir ed' attribute use 'barB_3' of the base type is missing. ./test/schemas/derivation-ok-restriction-2-1-1_0.xsd:16: element attribute: Sche mas parser error : local complex type, attribute decl. 'barB_1': The 'optional' use is inconsistent with a matching 'required' use of the base type. ./test/schemas/derivation-ok-restriction-2-1-1_0.xsd:23: element attribute: Sche mas parser error : local complex type, attribute decl. 'barC_1': Neither a match ing attribute use, nor a matching wildcard in the base type does exist. ./test/schemas/derivation-ok-restriction-2-1-1_0.xsd:25: element attribute: Sche mas parser error : local complex type, attribute decl. 'barC_2': Neither a match ing attribute use, nor a matching wildcard in the base type does exist. ./test/schemas/derivation-ok-restriction-2-1-1_0.xsd:30: element attribute: Sche mas parser error : local complex type, attribute decl. 'barD_1': Neither a match ing attribute use, nor a matching wildcard in the base type does exist. ./test/schemas/derivation-ok-restriction-2-1-1_0.xsd:32: element attribute: Sche mas parser error : local complex type, attribute decl. 'barD_2': Neither a match ing attribute use, nor a matching wildcard in the base type does exist. derivation-ok-restriction-4-1-err_0_0.err: ./test/schemas/derivation-ok-restriction-4-1-err_0.xsd:33: element complexType: Schemas parser error : complex type 'type.A': The type has an attribute wildcard , but the base type complex type 'base.type.A' does not have one. ./test/schemas/derivation-ok-restriction-4-1-err_0.xsd:45: element complexType: Schemas parser error : complex type 'type.B': The attribute wildcard is not a va lid subset of the wildcard in the base type complex type 'base.type.B'. ./test/schemas/derivation-ok-restriction-4-1-err_0.xsd:57: element complexType: Schemas parser error : complex type 'type.C': The 'process contents' of the attr ibute wildcard is weaker than the one in the base type complex type 'base.type.C '. Thanks
Greetings, I fall on the same problem with 2.6.22 AND 2.6.23 under AIX, compiler is v6???. It appears that the "const" keyword is somewhere defined. The "i" file shows it is replaced by a "", so all declarations/definitions in the parser.c file are completely messed. You can bypass this bug by adding a "#undef const" right after all the include/define declarations, which is line #99 (v2.6.22). There is compiles the parser.c file, and everything after it (samples, ...) Alas, this is not a correction, but a workaround.
Can someone check with a recent version (2.6.26 or CVS head) and report again ? Daniel
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!