From noreply at sourceforge.net Tue May 1 18:57:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 May 2007 09:57:16 -0700 Subject: [Expat-bugs] [ expat-Patches-1709457 ] Installer patch Message-ID: Patches item #1709457, was opened at 2007-04-28 21:17 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1709457&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Installer patch Initial Comment: * No installs to "Program Files" not drive root * Uninstall entry name made more usual * Update to version 2.0.1 Sebastian ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-29 20:59 Message: Logged In: YES user_id=290026 Originator: NO Patch applied in expat.iss rev. 1.21. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-28 21:18 Message: Logged In: YES user_id=1022691 Originator: NO -No +Now Forgot to login... Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1709457&group_id=10127 From noreply at sourceforge.net Tue May 1 18:57:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 May 2007 09:57:28 -0700 Subject: [Expat-bugs] [ expat-Patches-1709443 ] xmlwf manpage patch Message-ID: Patches item #1709443, was opened at 2007-04-28 19:42 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1709443&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sebastian Pipping (hartwork) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf manpage patch Initial Comment: "the the" -> "the" "postitions" -> "positions" ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-29 20:54 Message: Logged In: YES user_id=290026 Originator: NO Patch applied in xmlwf.1 rev. 1.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1709443&group_id=10127 From noreply at sourceforge.net Tue May 1 19:09:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 May 2007 10:09:29 -0700 Subject: [Expat-bugs] [ expat-Patches-1709419 ] Small xmlwf patch Message-ID: Patches item #1709419, was opened at 2007-04-29 00:20 Message generated for change (Settings changed) made by hartwork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1709419&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sebastian Pipping (hartwork) Assigned to: Nobody/Anonymous (nobody) Summary: Small xmlwf patch Initial Comment: Searching for (back)slashes in "STDIN" cannot succeed: two function calls can be saved. See patch for details. NOTE: The patch is not related to the bug I reported recently. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-30 02:51 Message: Logged In: YES user_id=290026 Originator: NO Path applied (with some extensions). See xmlwf.c rev. 1.73. Please test on Win32, Cygwin and Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1709419&group_id=10127 From noreply at sourceforge.net Tue May 1 19:26:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 May 2007 10:26:39 -0700 Subject: [Expat-bugs] [ expat-Bugs-1709402 ] xmlwf without parameters gives exception Message-ID: Bugs item #1709402, was opened at 2007-04-28 23:34 Message generated for change (Comment added) made by hartwork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1709402&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sebastian Pipping (hartwork) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf without parameters gives exception Initial Comment: I compiled xmlwf from CVS head with vs2k5 and when I run it without any parameters the debugger stops at line 767 which holds the code > parser = XML_ParserCreate(encoding); The error message is: > Unhandled exception at 0x10001cfb in xmlwf.exe: > 0xC0000005: Access violation reading location 0x00000024. I run Windows Server 2003 SP2 here. Sebastian ---------------------------------------------------------------------- >Comment By: Sebastian Pipping (hartwork) Date: 2007-05-01 19:26 Message: Logged In: YES user_id=1022691 Originator: YES It turned out this was a path problem. XMLWF simply could not find the DLL since it was neither located in the same directory nor in the search path. Sebastian ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-29 01:55 Message: Logged In: YES user_id=1022691 Originator: YES I zipped my project files to compare for you. These files are in, I hope that's all: ./examples/elements.vcproj ./examples/outline.vcproj ./lib/expat.vcproj ./lib/expat_static.vcproj ./lib/expatw.vcproj ./lib/expatw_static.vcproj ./xmlwf/xmlwf.vcproj ./expat.sln find . -name '*.vcproj' -or -name 'expat.sln' | zip -@ -9 expat_vs2k5.zip Sebastian File Added: expat_vs2k5.zip ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-29 01:36 Message: Logged In: YES user_id=290026 Originator: NO If you send me your solution and project files, I'll compare them with mine. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-29 00:37 Message: Logged In: YES user_id=1022691 Originator: YES I the Cygwin built does not have this problem. I did a clean rebuild with vs2k5 again - still the same. Sebastian ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 23:54 Message: Logged In: YES user_id=290026 Originator: NO I have no problems here - it just waits for input (reads from stdin, as it is supposed to). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1709402&group_id=10127 From noreply at sourceforge.net Wed May 2 14:55:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 May 2007 05:55:48 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 12:25 Message generated for change (Comment added) made by pipping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 11:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 2 15:08:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 May 2007 06:08:39 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 12:25 Message generated for change (Comment added) made by wiesmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- >Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 15:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 11:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 2 15:17:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 May 2007 06:17:06 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 12:25 Message generated for change (Comment added) made by pipping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 15:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 11:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 2 15:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 May 2007 06:20:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 12:25 Message generated for change (Comment added) made by pipping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 15:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 11:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 2 20:55:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 May 2007 11:55:25 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 12:25 Message generated for change (Comment added) made by hartwork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 20:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 15:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 11:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Sat May 5 03:01:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 May 2007 18:01:00 -0700 Subject: [Expat-bugs] [ expat-Bugs-1485066 ] MacOS X: tries to find libexpat.1.5.0.dylib in build Message-ID: Bugs item #1485066, was opened at 2006-05-09 17:48 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1485066&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: MacOS X: tries to find libexpat.1.5.0.dylib in build Initial Comment: System: Mac G4 running MacOS X 10.4.6 Expat downloaded from CVS in last hour. buildconfig.sh step worked OK ./configure worked OK make failed with message that ./.libs/libexpat.1.5.0.dylib not found configure and make output attached below (I hope). This was the 2nd try of running ./configure, hence the exat_config.h is unchanged remark. make is gmake 3.80 Sincerely Peter Stockwell Dept of Biochemistry, University of Otago, New Zealand. peter at sanger.otago.ac.nz ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-04 21:01 Message: Logged In: YES user_id=290026 Originator: NO Cloing this issue - it does not appear to be a bug and there was no follow-up. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 14:48 Message: Logged In: YES user_id=290026 Originator: NO I just used a tarball built with fairly recent versions of libtool and autoconf and it built fine on Mac OSX 10.2. However, I needed full rights for the target directory (--prefix), otherwise I got a similar error as described above on make check. Maybe the user did not have full rights for the build directory. I am inclined to close this issue as not a bug. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-26 08:31 Message: Logged In: YES user_id=290026 I am not sure we have any Mac experts on our team. Did you figure it out in the meantime? If it is a bug in our build process, would you be able to supply a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1485066&group_id=10127 From noreply at sourceforge.net Sat May 5 03:25:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 May 2007 18:25:23 -0700 Subject: [Expat-bugs] [ expat-Bugs-1632466 ] Error when I do make for expat2.0.0 Message-ID: Bugs item #1632466, was opened at 2007-01-10 10:13 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1632466&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Error when I do make for expat2.0.0 Initial Comment: # PATH=/usr/ccs/bin:$PATH make /bin/bash ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -DXML_UNICODE -o lib/xmlparse.lo -c lib/xmlparse.c /bin/bash ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -DXML_UNICODE -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -DXML_UNICODE -o lib/xmlrole.lo -c lib/xmlrole.c /bin/bash ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -DXML_UNICODE -no-undefined -version-info 6:0:5 -rpath /usr/local/lib/perl5/site_perl/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ld: fatal: library -lgcc_s: not found ld: fatal: library -lgcc_s: not found ld: fatal: File processing errors. No output written to .libs/libexpat.so.1.5.0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libexpat.la' ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-04 21:25 Message: Logged In: YES user_id=290026 Originator: NO What platform is this on? Have you been able to fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1632466&group_id=10127 From noreply at sourceforge.net Sat May 5 19:27:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 May 2007 10:27:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 08:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-13 19:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 16:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 13:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 12:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 15:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 14:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Sat May 5 19:28:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 May 2007 10:28:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-1613457 ] Makefile.in problem on NETBSD 3.1 Message-ID: Bugs item #1613457, was opened at 2006-12-11 14:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1613457&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Makefile.in problem on NETBSD 3.1 Initial Comment: After running the configure script, then trying to run make, it errors out: squallbsr at karasu2 [~/source/expat-2.0.0]$ make make: "/Users/squallbsr/source/expat-2.0.0/Makefile" line 47: Need an operator make: "/Users/squallbsr/source/expat-2.0.0/Makefile" line 49: Need an operator make: Fatal errors encountered -- cannot continue This can be fixed by adjusting the ifndef INSTALL_ROOT section around lines 47-49 in Makefile.in I changed it to: INSTALL_ROOT ?= $(DESTDIR) which worked on NetBSD and for my application, this of course would need more testing as all I wanted was for expat to complile, not install. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:28 Message: Logged In: YES user_id=290026 Originator: NO In an attempt to make Makefile.in more compatible across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: davidharpe (davidharpe) Date: 2007-01-02 14:23 Message: Logged In: YES user_id=1681745 Originator: NO I had the same problem on FreeBSD. Change lines 47-49 to: .ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) .endif (note the leading period) Seems to work fine. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:27 Message: Logged In: YES user_id=290026 Originator: NO Well, I thought about it, and "?=" seems acceptable. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. I'll change that accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-12 14:32 Message: Logged In: YES user_id=290026 Originator: NO Apparently - after doing a Goole search - Solaris as well as BSD Make have issues with the "ifndef" syntax. Is there a way to keep the logic with another syntax? It looks as if "?=" does not have exactly the same logic. ---------------------------------------------------------------------- Comment By: Bryan Rehbein (squallbsr) Date: 2006-12-11 14:54 Message: Logged In: YES user_id=950269 Originator: NO Bug reported by: br39290 at squall.us ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1613457&group_id=10127 From noreply at sourceforge.net Sat May 5 19:29:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 May 2007 10:29:17 -0700 Subject: [Expat-bugs] [ expat-Bugs-1618673 ] expat 2.0.0 compile problem on SCO-Unix 5.0.5 Message-ID: Bugs item #1618673, was opened at 2006-12-19 05:02 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1618673&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Third-party Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat 2.0.0 compile problem on SCO-Unix 5.0.5 Initial Comment: Message from mstabile at metsogeda.it ---------------------------------- Hi, I'm trying to compile your expat 2.0.0 on a sco5.0.5 server but i'm facing with some problems. first: in Makefile.in INSTALL_ROOT ?= $(DESTDIR) or previous ifndef ... sentence don't work . It work (It doesn't give "Must be a separator on rules line 47 (bu39)." message) only with INSTALL_ROOT = $(DESTDIR) Second and hardest problem is: executing make I get an error. with debug mode the message is: ..... + eval cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/ xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.s o -Wl,-R,/usr/local/lib + cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/xmlwf .o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.so -Wl, -R,/usr/local/lib command line: fatal error: illegal value for -R: /usr/local/lib + exit 1 *** Error code 1 (bu21) > -------------- executing cc in debug mode i get cc: 'ld' '-Ra,XPG4PLUS,elf' '-Y' 'P,/usr/ccs/lib:/lib:/usr/lib' '/usr/ccs/lib/c rt1.o' '/usr/ccs/lib/values-Xa.o' '-o' 'xmlwf/.libs/xmlwf' 'xmlwf/xmlwf.o' 'xmlw f/xmlfile.o' 'xmlwf/codepage.o' 'xmlwf/readfilemap.o' './.libs/libexpat.so' '-R' '/usr/local/lib' '-Qy' '-lcrypt' '-lgen' '-lc' '/usr/ccs/lib/crtn.o' cc: process: /usr/ccs/bin/elf/ld command line: fatal error: illegal value for -R: /usr/local/lib So the problem is the -R parameter passed to ld command that does not allow /usr/local/lib as argument as you can see from these part of ld man --------- ....... -Rarg[,arg,...] Set runtime-behavior characteristics. The option accepts a comma-separated list of arguments. Note that there is no space between -R and its arguments. Each argument is one of the accepted values for the -a, -b, or -X flags of cc(CP), and should match the flags used when the objects were compiled. The default is -Rxpg4plus,elf,a for the ELF ld, and -Rxpg4plus,coff,a for the COFF ld. The ELF ld ignores -Rcoff and -Ribcs2; the COFF ld ignores -Relf. Multiple -R arguments may be given; the last argument of each type ( -a, -b, or -X) is the one used. For example, -Ransi,a -Rxpg4,coff is equivalent to -Rxpg4,coff,a. ........ So, I belive some ld parameter must be changed but what? TIA , I hope you can send me the solution ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:29 Message: Logged In: YES user_id=290026 Originator: NO For part of this issue: In an attempt to make Makefile.in more compatible across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-19 13:48 Message: Logged In: YES user_id=290026 Originator: NO When I made the Expat 2.0 tarball I used libtool 1.5.22. Is that new enough? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-19 10:43 Message: Logged In: YES user_id=3066 Originator: NO > All our Unix build experts have been unresponsive for a while. Sadly, that's me. I've never used SCO Unix myself. Whether a new libtool fixes this problem, I don't know. If anyone can verify that, we can see about using an updated libtool. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-19 10:30 Message: Logged In: YES user_id=290026 Originator: NO All our Unix build experts have been unresponsive for a while. I am not sure I can really help you there. I can only recommend to search Google for problems with ld on SCO. And, in the spirit of support for OpenSource projects, why don't you ditch SCO in favour of Linux? :-) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-12-19 05:26 Message: Logged In: NO Message from mstabile at metsogeda.it ----------------------------------- Command cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.so -Wl,-L,/usr/local/lib seems to work and create xmlwf/.libs/xmlwf How libtool should be changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1618673&group_id=10127 From noreply at sourceforge.net Sun May 6 17:58:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 08:58:08 -0700 Subject: [Expat-bugs] [ expat-Patches-1643316 ] Build issues on Symbian and BREW Message-ID: Patches item #1643316, was opened at 2007-01-24 04:23 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1643316&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build Control >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Build issues on Symbian and BREW Initial Comment: e-mail: uriah at mobiletornado.com Expat version: 1.95.8 Hello, My company is developing a cross-platform application which uses Expat, among other 3rd Party libraries. The above two (cellular) platforms impose a limitation that applications may not have global writeable data. Therefore, I had to make some small changes to Expat source code - mainly adding 'const' to static arrays (which are not written to anyway). Also, I've disabled MSC_EXTENSIONS for Symbian (when compiling to an emulator it uses MSVC) in addition to other platforms. Finally, I had some trouble with VC6 project files generated by the Symbian SDK, so I modified xmltok_impl.c and xmltok_ns.c to prevent it from trying to compile them, don't know if this is so important... Attached is a source control report of the changes I've made. Regards, Uriah ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:58 Message: Logged In: YES user_id=290026 Originator: NO Re-categorized this as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1643316&group_id=10127 From noreply at sourceforge.net Sun May 6 18:00:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 09:00:20 -0700 Subject: [Expat-bugs] [ expat-Bugs-1657749 ] Makefile is incomplete for C++ compile Message-ID: Bugs item #1657749, was opened at 2007-02-12 02:00 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1657749&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Makefile is incomplete for C++ compile Initial Comment: The Makefile that is generated needs a .SUFFIX entry in order to compile the tests/runtestspp program. I simply copied the .c.o suffix entry to .cpp.o as follows: .cpp.o: $(CXXCOMPILE) -o $@ -c $< This allowed the C++ tests to build and execute properly. Feel free to contact me at t.ledford at insightbb.com Thanks. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 12:00 Message: Logged In: YES user_id=290026 Originator: NO Closing this as fixed, no negative feedback from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-02-12 09:12 Message: Logged In: YES user_id=290026 Originator: NO I think that is already fixed like that in CVS. Could you please verify? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1657749&group_id=10127 From noreply at sourceforge.net Sun May 6 18:01:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 09:01:26 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 16:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 12:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 22:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 19:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 11:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Sun May 6 18:02:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 09:02:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Feature Request Status: Open >Resolution: Postponed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 12:02 Message: Logged In: YES user_id=290026 Originator: NO Changed resolution to "Postponed" for Expat 3 (if there ever is one). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-02-04 14:47 Message: Logged In: YES user_id=290026 Just a note, so that I don't forget: XML_ParserReset will currently also clear the paramEntityParsing member. This is also one of the settings one may not want to be reset. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 10:26 Message: Logged In: YES user_id=290026 You are correct about anything else - the example was just for illustration purposes. I think we agree on all aspects here. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:09 Message: Logged In: YES user_id=3066 I'd drop the "anything else" bit, and add XML_ASPECT_ALL = MAX_UINT or something like that. The problem with "anything else" is that it's semantics change (or we need a new "anything else" value) as soon as an additional aspect is introducted. Each bit should correspond to a well-defined bit of state, and that mapping should never change. If some aspect represented by a bit needs to be broken out into separate aspects in the future, the new aspects should receive their own bit, and the original bit should continue to deal with all parts of that aspect. There should also be a define that contains all the known aspects, but nothing else. That can be used to determine if any aspects are indicated which are not known; this should probably be treated as an error by the library, and get reported without making any changes. Sounds like we're agreed on making this an Expat 3 change. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:32 Message: Logged In: YES user_id=290026 I totally agree with your conceptual separation between re-initializing internal state and clearing user settings. Changing how the latter behaves is mostly a matter of convenience, I agree as well. IMO, the bulk of applications would benefit from having user settings *not* cleared, but there are others with the opposite requirements. So, I vote for modifying XML_ParserReset() for the first release after 2.0. I also suggest that we define the "aspects" parameter type as a set of bit flags, so that the user can easily combine various options. E.g. (one of several possible mappings): XML_ASPECT_NONE = 0; XML_ASPECT_USERDATA = 1; XML_ASPECT_CONTENTHANDLERS = 2; XML_ASPECT_OTHERHANDLERS = 4; XML_ASPECT_ANYTHINGELSE = 8; etc. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:06 Message: Logged In: YES user_id=3066 Either adding it now or after works for me, but after probably makes more sense given that we're trying to wrap up a stable 2.0. My own suspicion is that the cost of re-initializing a parser should be thought of as two separate parts: re-initializing the parse state within Expat, and re-initializing the user-provided information (callbacks and user-data). The parse state involves a whole pile of memory structures that the user has no direct access to (or control over the cost of re-initialization), and the user-provided information is most a collection of pointers for which the initialization cost is dominated by the function call overhead. This leads me to think that there's no substantial performance benefit in this for most applications, but there may be substantial benefit for apps running on embedded processors. It would be interesting to know if Sebastian's application is running in an embedded environment, and if not, what the motivation for the original question might be. If the motivation is not efficiency but convenience, then it can certainly wait for Expat 3. FTR, the original post that generated this tracker issue can be found in the expat-discuss mailing list archives: http://mail.libexpat.org/pipermail/expat-discuss/2005-January/001726.html ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-26 22:08 Message: Logged In: YES user_id=290026 Your last suggestion seems reasonable. What about this - let's wait until after Expat 2.0, as the subsequent releases won't be backwards compatible anyway. Then we can simply add the "aspects" parameter to the existing XML_ParserReset() function without having to worry about compatibility. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Sun May 6 18:03:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 09:03:43 -0700 Subject: [Expat-bugs] [ expat-Bugs-968631 ] no flag to control 64 or 32 bit libraries built Message-ID: Bugs item #968631, was opened at 2004-06-08 00:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=968631&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: no flag to control 64 or 32 bit libraries built Initial Comment: I need to build expat libraries for a number of 64 bit platforms, including aix 5.1 64 bit. There appears to be no setting when configuring the make process to force a 64 bit output for the built libraries. email: john.fairhall at oz.quest.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 12:03 Message: Logged In: YES user_id=290026 Originator: NO Maybe Fred can do something about this - if even necessary? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=968631&group_id=10127 From noreply at sourceforge.net Sun May 6 18:06:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 09:06:19 -0700 Subject: [Expat-bugs] [ expat-Patches-1643316 ] Build issues on Symbian and BREW Message-ID: Patches item #1643316, was opened at 2007-01-24 10:23 Message generated for change (Comment added) made by hartwork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1643316&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Build issues on Symbian and BREW Initial Comment: e-mail: uriah at mobiletornado.com Expat version: 1.95.8 Hello, My company is developing a cross-platform application which uses Expat, among other 3rd Party libraries. The above two (cellular) platforms impose a limitation that applications may not have global writeable data. Therefore, I had to make some small changes to Expat source code - mainly adding 'const' to static arrays (which are not written to anyway). Also, I've disabled MSC_EXTENSIONS for Symbian (when compiling to an emulator it uses MSVC) in addition to other platforms. Finally, I had some trouble with VC6 project files generated by the Symbian SDK, so I modified xmltok_impl.c and xmltok_ns.c to prevent it from trying to compile them, don't know if this is so important... Attached is a source control report of the changes I've made. Regards, Uriah ---------------------------------------------------------------------- >Comment By: Sebastian Pipping (hartwork) Date: 2007-05-06 18:06 Message: Logged In: YES user_id=1022691 Originator: NO About and : The latest CVS head does not have this problem anymore, so applying this part of the patch can only break things instead heal. Sebastian ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 17:58 Message: Logged In: YES user_id=290026 Originator: NO Re-categorized this as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1643316&group_id=10127 From noreply at sourceforge.net Mon May 7 00:10:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 May 2007 15:10:23 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 15:31 Message generated for change (Comment added) made by klemscot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Scott Klement (klemscot) Date: 2007-05-06 17:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 21:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 18:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 10:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Mon May 7 09:26:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 00:26:38 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 15:31 Message generated for change (Comment added) made by klemscot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 17:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 21:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 18:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 10:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Mon May 7 09:30:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 00:30:16 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 15:31 Message generated for change (Comment added) made by klemscot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:30 Message: Logged In: YES user_id=223473 Originator: YES Ooops. Sorry about the duplicate comment! Here's a patch (Unified Diff) that solves the problem for me. --- /home/klemscot/as400/expat-2.0.0.orig/lib/ascii.h Tue Nov 12 15:45:57 2002 +++ ./ascii.h Mon May 7 01:25:36 2007 @@ -83,3 +83,10 @@ #define ASCII_LSQB 0x5B #define ASCII_RSQB 0x5D #define ASCII_UNDERSCORE 0x5F +#define ASCII_LPAREN 0x28 +#define ASCII_RPAREN 0x29 +#define ASCII_FF 0x0C +#define ASCII_SLASH 0x2F +#define ASCII_HASH 0x23 +#define ASCII_PIPE 0x7C +#define ASCII_COMMA 0x2C --- /home/klemscot/as400/expat-2.0.0.orig/lib/xmlparse.c Fri Dec 23 08:45:27 2005 +++ ./xmlparse.c Mon May 7 01:21:55 2007 @@ -5,6 +5,7 @@ #include #include /* memset(), memcpy() */ #include +#include #define XML_BUILDING_EXPAT 1 @@ -665,10 +666,12 @@ } static const XML_Char implicitContext[] = { - 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_x, ASCII_m, ASCII_l, ASCII_EQUALS, ASCII_h, ASCII_t, ASCII_t, ASCII_p, + ASCII_COLON, ASCII_SLASH, ASCII_SLASH, ASCII_w, ASCII_w, ASCII_w, + ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, ASCII_o, ASCII_r, ASCII_g, + ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, ASCII_SLASH, ASCII_1, ASCII_9, + ASCII_9, ASCII_8, ASCII_SLASH, ASCII_n, ASCII_a, ASCII_m, ASCII_e, + ASCII_s, ASCII_p, ASCII_a, ASCII_c, ASCII_e, '\0' }; XML_Parser XMLCALL @@ -761,7 +764,7 @@ unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; - namespaceSeparator = '!'; + namespaceSeparator = ASCII_EXCL; ns = XML_FALSE; ns_triplets = XML_FALSE; @@ -2806,7 +2809,7 @@ return XML_ERROR_NO_MEMORY; uriHash = CHAR_HASH(uriHash, c); } - while (*s++ != XML_T(':')) + while (*s++ != XML_T(ASCII_COLON)) ; do { /* copies null terminator */ const XML_Char c = *s; @@ -2880,7 +2883,7 @@ if (!binding) return XML_ERROR_UNBOUND_PREFIX; localPart = tagNamePtr->str; - while (*localPart++ != XML_T(':')) + while (*localPart++ != XML_T(ASCII_COLON)) ; } else if (dtd->defaultPrefix.binding) { @@ -2935,17 +2938,21 @@ const XML_Char *uri, BINDING **bindingsPtr) { static const XML_Char xmlNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, + ASCII_SLASH, ASCII_1, ASCII_9, ASCII_9, ASCII_8, ASCII_SLASH, + ASCII_n, ASCII_a, ASCII_m, ASCII_e, ASCII_s, ASCII_p, ASCII_a, ASCII_c, + ASCII_e, '\0' }; static const int xmlLen = (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; static const XML_Char xmlnsNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_2, ASCII_0, ASCII_0, + ASCII_0, ASCII_SLASH, ASCII_x, ASCII_m, ASCII_l, ASCII_n, ASCII_s, + ASCII_SLASH, '\0' }; static const int xmlnsLen = (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; @@ -2962,13 +2969,13 @@ return XML_ERROR_UNDECLARING_PREFIX; if (prefix->name - && prefix->name[0] == XML_T('x') - && prefix->name[1] == XML_T('m') - && prefix->name[2] == XML_T('l')) { + && prefix->name[0] == XML_T(ASCII_x) + && prefix->name[1] == XML_T(ASCII_m) + && prefix->name[2] == XML_T(ASCII_l)) { /* Not allowed to bind xmlns */ - if (prefix->name[3] == XML_T('n') - && prefix->name[4] == XML_T('s') + if (prefix->name[3] == XML_T(ASCII_n) + && prefix->name[4] == XML_T(ASCII_s) && prefix->name[5] == XML_T('\0')) return XML_ERROR_RESERVED_PREFIX_XMLNS; @@ -3628,23 +3635,30 @@ XML_Bool haveMore) { #ifdef XML_DTD - static const XML_Char externalSubsetName[] = { '#' , '\0' }; + static const XML_Char externalSubsetName[] = { ASCII_HASH , '\0' }; #endif /* XML_DTD */ - static const XML_Char atypeCDATA[] = { 'C', 'D', 'A', 'T', 'A', '\0' }; - static const XML_Char atypeID[] = { 'I', 'D', '\0' }; - static const XML_Char atypeIDREF[] = { 'I', 'D', 'R', 'E', 'F', '\0' }; - static const XML_Char atypeIDREFS[] = { 'I', 'D', 'R', 'E', 'F', 'S', '\0' }; - static const XML_Char atypeENTITY[] = { 'E', 'N', 'T', 'I', 'T', 'Y', '\0' }; + static const XML_Char atypeCDATA[] = { ASCII_C, ASCII_D, ASCII_A, ASCII_T, + ASCII_A, '\0' }; + static const XML_Char atypeID[] = { ASCII_I, ASCII_D, '\0' }; + static const XML_Char atypeIDREF[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, '\0' }; + static const XML_Char atypeIDREFS[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, ASCII_S, '\0' }; + static const XML_Char atypeENTITY[] = { ASCII_E, ASCII_N, ASCII_T, ASCII_I, + ASCII_T, ASCII_Y, '\0' }; static const XML_Char atypeENTITIES[] = - { 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S', '\0' }; + { ASCII_E, ASCII_N, ASCII_T, ASCII_I, ASCII_T, ASCII_I, ASCII_E, + ASCII_S, '\0' }; static const XML_Char atypeNMTOKEN[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, '\0' }; static const XML_Char atypeNMTOKENS[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, + ASCII_S, '\0' }; static const XML_Char notationPrefix[] = { - 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N', '(', '\0' }; - static const XML_Char enumValueSep[] = { '|', '\0' }; - static const XML_Char enumValueStart[] = { '(', '\0' }; + ASCII_N, ASCII_O, ASCII_T, ASCII_A, ASCII_T, ASCII_I, ASCII_O, ASCII_N, + ASCII_LPAREN, '\0' }; + static const XML_Char enumValueSep[] = { ASCII_PIPE, '\0' }; + static const XML_Char enumValueStart[] = { ASCII_LPAREN, '\0' }; /* save one level of indirection */ DTD * const dtd = _dtd; @@ -3950,11 +3964,11 @@ 0, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -3987,11 +4001,11 @@ declAttributeIsCdata, XML_FALSE, attVal, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -4318,14 +4332,14 @@ } break; case XML_ROLE_GROUP_SEQUENCE: - if (groupConnector[prologState.level] == '|') + if (groupConnector[prologState.level] == ASCII_PIPE) return XML_ERROR_SYNTAX; - groupConnector[prologState.level] = ','; + groupConnector[prologState.level] = ASCII_COMMA; if (dtd->in_eldecl && elementDeclHandler) handleDefault = XML_FALSE; break; case XML_ROLE_GROUP_CHOICE: - if (groupConnector[prologState.level] == ',') + if (groupConnector[prologState.level] == ASCII_COMMA) return XML_ERROR_SYNTAX; if (dtd->in_eldecl && !groupConnector[prologState.level] @@ -4337,7 +4351,7 @@ if (elementDeclHandler) handleDefault = XML_FALSE; } - groupConnector[prologState.level] = '|'; + groupConnector[prologState.level] = ASCII_PIPE; break; case XML_ROLE_PARAM_ENTITY_REF: #ifdef XML_DTD @@ -5267,7 +5281,7 @@ DTD * const dtd = _dtd; /* save one level of indirection */ const XML_Char *name; for (name = elementType->name; *name; name++) { - if (*name == XML_T(':')) { + if (*name == XML_T(ASCII_COLON)) { PREFIX *prefix; const XML_Char *s; for (s = elementType->name; s != name; s++) { @@ -5314,12 +5328,12 @@ poolFinish(&dtd->pool); if (!ns) ; - else if (name[0] == XML_T('x') - && name[1] == XML_T('m') - && name[2] == XML_T('l') - && name[3] == XML_T('n') - && name[4] == XML_T('s') - && (name[5] == XML_T('\0') || name[5] == XML_T(':'))) { + else if (name[0] == XML_T(ASCII_x) + && name[1] == XML_T(ASCII_m) + && name[2] == XML_T(ASCII_l) + && name[3] == XML_T(ASCII_n) + && name[4] == XML_T(ASCII_s) + && (name[5] == XML_T('\0') || name[5] == XML_T(ASCII_COLON))) { if (name[5] == XML_T('\0')) id->prefix = &dtd->defaultPrefix; else @@ -5330,7 +5344,7 @@ int i; for (i = 0; name[i]; i++) { /* attributes without prefix are *not* in the default namespace */ - if (name[i] == XML_T(':')) { + if (name[i] == XML_T(ASCII_COLON)) { int j; for (j = 0; j < i; j++) { if (!poolAppendChar(&dtd->pool, name[j])) @@ -5352,7 +5366,7 @@ return id; } -#define CONTEXT_SEP XML_T('\f') +#define CONTEXT_SEP XML_T(ASCII_FF) static const XML_Char * getContext(XML_Parser parser) @@ -5364,7 +5378,7 @@ if (dtd->defaultPrefix.binding) { int i; int len; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = dtd->defaultPrefix.binding->uriLen; if (namespaceSeparator) @@ -5390,7 +5404,7 @@ for (s = prefix->name; *s; s++) if (!poolAppendChar(&tempPool, *s)) return NULL; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = prefix->binding->uriLen; if (namespaceSeparator) @@ -5442,7 +5456,7 @@ context = s; poolDiscard(&tempPool); } - else if (*s == XML_T('=')) { + else if (*s == XML_T(ASCII_EQUALS)) { PREFIX *prefix; if (poolLength(&tempPool) == 0) prefix = &dtd->defaultPrefix; ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 17:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 21:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 18:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 10:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Mon May 7 09:31:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 00:31:36 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 15:31 Message generated for change (Settings changed) made by klemscot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:30 Message: Logged In: YES user_id=223473 Originator: YES Ooops. Sorry about the duplicate comment! Here's a patch (Unified Diff) that solves the problem for me. --- /home/klemscot/as400/expat-2.0.0.orig/lib/ascii.h Tue Nov 12 15:45:57 2002 +++ ./ascii.h Mon May 7 01:25:36 2007 @@ -83,3 +83,10 @@ #define ASCII_LSQB 0x5B #define ASCII_RSQB 0x5D #define ASCII_UNDERSCORE 0x5F +#define ASCII_LPAREN 0x28 +#define ASCII_RPAREN 0x29 +#define ASCII_FF 0x0C +#define ASCII_SLASH 0x2F +#define ASCII_HASH 0x23 +#define ASCII_PIPE 0x7C +#define ASCII_COMMA 0x2C --- /home/klemscot/as400/expat-2.0.0.orig/lib/xmlparse.c Fri Dec 23 08:45:27 2005 +++ ./xmlparse.c Mon May 7 01:21:55 2007 @@ -5,6 +5,7 @@ #include #include /* memset(), memcpy() */ #include +#include #define XML_BUILDING_EXPAT 1 @@ -665,10 +666,12 @@ } static const XML_Char implicitContext[] = { - 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_x, ASCII_m, ASCII_l, ASCII_EQUALS, ASCII_h, ASCII_t, ASCII_t, ASCII_p, + ASCII_COLON, ASCII_SLASH, ASCII_SLASH, ASCII_w, ASCII_w, ASCII_w, + ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, ASCII_o, ASCII_r, ASCII_g, + ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, ASCII_SLASH, ASCII_1, ASCII_9, + ASCII_9, ASCII_8, ASCII_SLASH, ASCII_n, ASCII_a, ASCII_m, ASCII_e, + ASCII_s, ASCII_p, ASCII_a, ASCII_c, ASCII_e, '\0' }; XML_Parser XMLCALL @@ -761,7 +764,7 @@ unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; - namespaceSeparator = '!'; + namespaceSeparator = ASCII_EXCL; ns = XML_FALSE; ns_triplets = XML_FALSE; @@ -2806,7 +2809,7 @@ return XML_ERROR_NO_MEMORY; uriHash = CHAR_HASH(uriHash, c); } - while (*s++ != XML_T(':')) + while (*s++ != XML_T(ASCII_COLON)) ; do { /* copies null terminator */ const XML_Char c = *s; @@ -2880,7 +2883,7 @@ if (!binding) return XML_ERROR_UNBOUND_PREFIX; localPart = tagNamePtr->str; - while (*localPart++ != XML_T(':')) + while (*localPart++ != XML_T(ASCII_COLON)) ; } else if (dtd->defaultPrefix.binding) { @@ -2935,17 +2938,21 @@ const XML_Char *uri, BINDING **bindingsPtr) { static const XML_Char xmlNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, + ASCII_SLASH, ASCII_1, ASCII_9, ASCII_9, ASCII_8, ASCII_SLASH, + ASCII_n, ASCII_a, ASCII_m, ASCII_e, ASCII_s, ASCII_p, ASCII_a, ASCII_c, + ASCII_e, '\0' }; static const int xmlLen = (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; static const XML_Char xmlnsNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_2, ASCII_0, ASCII_0, + ASCII_0, ASCII_SLASH, ASCII_x, ASCII_m, ASCII_l, ASCII_n, ASCII_s, + ASCII_SLASH, '\0' }; static const int xmlnsLen = (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; @@ -2962,13 +2969,13 @@ return XML_ERROR_UNDECLARING_PREFIX; if (prefix->name - && prefix->name[0] == XML_T('x') - && prefix->name[1] == XML_T('m') - && prefix->name[2] == XML_T('l')) { + && prefix->name[0] == XML_T(ASCII_x) + && prefix->name[1] == XML_T(ASCII_m) + && prefix->name[2] == XML_T(ASCII_l)) { /* Not allowed to bind xmlns */ - if (prefix->name[3] == XML_T('n') - && prefix->name[4] == XML_T('s') + if (prefix->name[3] == XML_T(ASCII_n) + && prefix->name[4] == XML_T(ASCII_s) && prefix->name[5] == XML_T('\0')) return XML_ERROR_RESERVED_PREFIX_XMLNS; @@ -3628,23 +3635,30 @@ XML_Bool haveMore) { #ifdef XML_DTD - static const XML_Char externalSubsetName[] = { '#' , '\0' }; + static const XML_Char externalSubsetName[] = { ASCII_HASH , '\0' }; #endif /* XML_DTD */ - static const XML_Char atypeCDATA[] = { 'C', 'D', 'A', 'T', 'A', '\0' }; - static const XML_Char atypeID[] = { 'I', 'D', '\0' }; - static const XML_Char atypeIDREF[] = { 'I', 'D', 'R', 'E', 'F', '\0' }; - static const XML_Char atypeIDREFS[] = { 'I', 'D', 'R', 'E', 'F', 'S', '\0' }; - static const XML_Char atypeENTITY[] = { 'E', 'N', 'T', 'I', 'T', 'Y', '\0' }; + static const XML_Char atypeCDATA[] = { ASCII_C, ASCII_D, ASCII_A, ASCII_T, + ASCII_A, '\0' }; + static const XML_Char atypeID[] = { ASCII_I, ASCII_D, '\0' }; + static const XML_Char atypeIDREF[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, '\0' }; + static const XML_Char atypeIDREFS[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, ASCII_S, '\0' }; + static const XML_Char atypeENTITY[] = { ASCII_E, ASCII_N, ASCII_T, ASCII_I, + ASCII_T, ASCII_Y, '\0' }; static const XML_Char atypeENTITIES[] = - { 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S', '\0' }; + { ASCII_E, ASCII_N, ASCII_T, ASCII_I, ASCII_T, ASCII_I, ASCII_E, + ASCII_S, '\0' }; static const XML_Char atypeNMTOKEN[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, '\0' }; static const XML_Char atypeNMTOKENS[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, + ASCII_S, '\0' }; static const XML_Char notationPrefix[] = { - 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N', '(', '\0' }; - static const XML_Char enumValueSep[] = { '|', '\0' }; - static const XML_Char enumValueStart[] = { '(', '\0' }; + ASCII_N, ASCII_O, ASCII_T, ASCII_A, ASCII_T, ASCII_I, ASCII_O, ASCII_N, + ASCII_LPAREN, '\0' }; + static const XML_Char enumValueSep[] = { ASCII_PIPE, '\0' }; + static const XML_Char enumValueStart[] = { ASCII_LPAREN, '\0' }; /* save one level of indirection */ DTD * const dtd = _dtd; @@ -3950,11 +3964,11 @@ 0, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -3987,11 +4001,11 @@ declAttributeIsCdata, XML_FALSE, attVal, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -4318,14 +4332,14 @@ } break; case XML_ROLE_GROUP_SEQUENCE: - if (groupConnector[prologState.level] == '|') + if (groupConnector[prologState.level] == ASCII_PIPE) return XML_ERROR_SYNTAX; - groupConnector[prologState.level] = ','; + groupConnector[prologState.level] = ASCII_COMMA; if (dtd->in_eldecl && elementDeclHandler) handleDefault = XML_FALSE; break; case XML_ROLE_GROUP_CHOICE: - if (groupConnector[prologState.level] == ',') + if (groupConnector[prologState.level] == ASCII_COMMA) return XML_ERROR_SYNTAX; if (dtd->in_eldecl && !groupConnector[prologState.level] @@ -4337,7 +4351,7 @@ if (elementDeclHandler) handleDefault = XML_FALSE; } - groupConnector[prologState.level] = '|'; + groupConnector[prologState.level] = ASCII_PIPE; break; case XML_ROLE_PARAM_ENTITY_REF: #ifdef XML_DTD @@ -5267,7 +5281,7 @@ DTD * const dtd = _dtd; /* save one level of indirection */ const XML_Char *name; for (name = elementType->name; *name; name++) { - if (*name == XML_T(':')) { + if (*name == XML_T(ASCII_COLON)) { PREFIX *prefix; const XML_Char *s; for (s = elementType->name; s != name; s++) { @@ -5314,12 +5328,12 @@ poolFinish(&dtd->pool); if (!ns) ; - else if (name[0] == XML_T('x') - && name[1] == XML_T('m') - && name[2] == XML_T('l') - && name[3] == XML_T('n') - && name[4] == XML_T('s') - && (name[5] == XML_T('\0') || name[5] == XML_T(':'))) { + else if (name[0] == XML_T(ASCII_x) + && name[1] == XML_T(ASCII_m) + && name[2] == XML_T(ASCII_l) + && name[3] == XML_T(ASCII_n) + && name[4] == XML_T(ASCII_s) + && (name[5] == XML_T('\0') || name[5] == XML_T(ASCII_COLON))) { if (name[5] == XML_T('\0')) id->prefix = &dtd->defaultPrefix; else @@ -5330,7 +5344,7 @@ int i; for (i = 0; name[i]; i++) { /* attributes without prefix are *not* in the default namespace */ - if (name[i] == XML_T(':')) { + if (name[i] == XML_T(ASCII_COLON)) { int j; for (j = 0; j < i; j++) { if (!poolAppendChar(&dtd->pool, name[j])) @@ -5352,7 +5366,7 @@ return id; } -#define CONTEXT_SEP XML_T('\f') +#define CONTEXT_SEP XML_T(ASCII_FF) static const XML_Char * getContext(XML_Parser parser) @@ -5364,7 +5378,7 @@ if (dtd->defaultPrefix.binding) { int i; int len; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = dtd->defaultPrefix.binding->uriLen; if (namespaceSeparator) @@ -5390,7 +5404,7 @@ for (s = prefix->name; *s; s++) if (!poolAppendChar(&tempPool, *s)) return NULL; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = prefix->binding->uriLen; if (namespaceSeparator) @@ -5442,7 +5456,7 @@ context = s; poolDiscard(&tempPool); } - else if (*s == XML_T('=')) { + else if (*s == XML_T(ASCII_EQUALS)) { PREFIX *prefix; if (poolLength(&tempPool) == 0) prefix = &dtd->defaultPrefix; ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 17:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 21:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 18:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 10:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Mon May 7 10:50:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 01:50:55 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 18:36 Message generated for change (Comment added) made by mhaubi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 10:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 19:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 14:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-14 01:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 18:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 22:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 19:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 18:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 21:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 20:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 23:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 22:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 19:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Mon May 7 23:51:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 14:51:42 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 16:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-07 17:51 Message: Logged In: YES user_id=290026 Originator: NO Thanks very much for catching this! I didn't think of EBCDIC, I have to admit. Could you please attach you patch as a file. SF has added a few line breaks on the web page (and what not). ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 03:30 Message: Logged In: YES user_id=223473 Originator: YES Ooops. Sorry about the duplicate comment! Here's a patch (Unified Diff) that solves the problem for me. --- /home/klemscot/as400/expat-2.0.0.orig/lib/ascii.h Tue Nov 12 15:45:57 2002 +++ ./ascii.h Mon May 7 01:25:36 2007 @@ -83,3 +83,10 @@ #define ASCII_LSQB 0x5B #define ASCII_RSQB 0x5D #define ASCII_UNDERSCORE 0x5F +#define ASCII_LPAREN 0x28 +#define ASCII_RPAREN 0x29 +#define ASCII_FF 0x0C +#define ASCII_SLASH 0x2F +#define ASCII_HASH 0x23 +#define ASCII_PIPE 0x7C +#define ASCII_COMMA 0x2C --- /home/klemscot/as400/expat-2.0.0.orig/lib/xmlparse.c Fri Dec 23 08:45:27 2005 +++ ./xmlparse.c Mon May 7 01:21:55 2007 @@ -5,6 +5,7 @@ #include #include /* memset(), memcpy() */ #include +#include #define XML_BUILDING_EXPAT 1 @@ -665,10 +666,12 @@ } static const XML_Char implicitContext[] = { - 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_x, ASCII_m, ASCII_l, ASCII_EQUALS, ASCII_h, ASCII_t, ASCII_t, ASCII_p, + ASCII_COLON, ASCII_SLASH, ASCII_SLASH, ASCII_w, ASCII_w, ASCII_w, + ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, ASCII_o, ASCII_r, ASCII_g, + ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, ASCII_SLASH, ASCII_1, ASCII_9, + ASCII_9, ASCII_8, ASCII_SLASH, ASCII_n, ASCII_a, ASCII_m, ASCII_e, + ASCII_s, ASCII_p, ASCII_a, ASCII_c, ASCII_e, '\0' }; XML_Parser XMLCALL @@ -761,7 +764,7 @@ unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; - namespaceSeparator = '!'; + namespaceSeparator = ASCII_EXCL; ns = XML_FALSE; ns_triplets = XML_FALSE; @@ -2806,7 +2809,7 @@ return XML_ERROR_NO_MEMORY; uriHash = CHAR_HASH(uriHash, c); } - while (*s++ != XML_T(':')) + while (*s++ != XML_T(ASCII_COLON)) ; do { /* copies null terminator */ const XML_Char c = *s; @@ -2880,7 +2883,7 @@ if (!binding) return XML_ERROR_UNBOUND_PREFIX; localPart = tagNamePtr->str; - while (*localPart++ != XML_T(':')) + while (*localPart++ != XML_T(ASCII_COLON)) ; } else if (dtd->defaultPrefix.binding) { @@ -2935,17 +2938,21 @@ const XML_Char *uri, BINDING **bindingsPtr) { static const XML_Char xmlNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, + ASCII_SLASH, ASCII_1, ASCII_9, ASCII_9, ASCII_8, ASCII_SLASH, + ASCII_n, ASCII_a, ASCII_m, ASCII_e, ASCII_s, ASCII_p, ASCII_a, ASCII_c, + ASCII_e, '\0' }; static const int xmlLen = (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; static const XML_Char xmlnsNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_2, ASCII_0, ASCII_0, + ASCII_0, ASCII_SLASH, ASCII_x, ASCII_m, ASCII_l, ASCII_n, ASCII_s, + ASCII_SLASH, '\0' }; static const int xmlnsLen = (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; @@ -2962,13 +2969,13 @@ return XML_ERROR_UNDECLARING_PREFIX; if (prefix->name - && prefix->name[0] == XML_T('x') - && prefix->name[1] == XML_T('m') - && prefix->name[2] == XML_T('l')) { + && prefix->name[0] == XML_T(ASCII_x) + && prefix->name[1] == XML_T(ASCII_m) + && prefix->name[2] == XML_T(ASCII_l)) { /* Not allowed to bind xmlns */ - if (prefix->name[3] == XML_T('n') - && prefix->name[4] == XML_T('s') + if (prefix->name[3] == XML_T(ASCII_n) + && prefix->name[4] == XML_T(ASCII_s) && prefix->name[5] == XML_T('\0')) return XML_ERROR_RESERVED_PREFIX_XMLNS; @@ -3628,23 +3635,30 @@ XML_Bool haveMore) { #ifdef XML_DTD - static const XML_Char externalSubsetName[] = { '#' , '\0' }; + static const XML_Char externalSubsetName[] = { ASCII_HASH , '\0' }; #endif /* XML_DTD */ - static const XML_Char atypeCDATA[] = { 'C', 'D', 'A', 'T', 'A', '\0' }; - static const XML_Char atypeID[] = { 'I', 'D', '\0' }; - static const XML_Char atypeIDREF[] = { 'I', 'D', 'R', 'E', 'F', '\0' }; - static const XML_Char atypeIDREFS[] = { 'I', 'D', 'R', 'E', 'F', 'S', '\0' }; - static const XML_Char atypeENTITY[] = { 'E', 'N', 'T', 'I', 'T', 'Y', '\0' }; + static const XML_Char atypeCDATA[] = { ASCII_C, ASCII_D, ASCII_A, ASCII_T, + ASCII_A, '\0' }; + static const XML_Char atypeID[] = { ASCII_I, ASCII_D, '\0' }; + static const XML_Char atypeIDREF[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, '\0' }; + static const XML_Char atypeIDREFS[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, ASCII_S, '\0' }; + static const XML_Char atypeENTITY[] = { ASCII_E, ASCII_N, ASCII_T, ASCII_I, + ASCII_T, ASCII_Y, '\0' }; static const XML_Char atypeENTITIES[] = - { 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S', '\0' }; + { ASCII_E, ASCII_N, ASCII_T, ASCII_I, ASCII_T, ASCII_I, ASCII_E, + ASCII_S, '\0' }; static const XML_Char atypeNMTOKEN[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, '\0' }; static const XML_Char atypeNMTOKENS[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, + ASCII_S, '\0' }; static const XML_Char notationPrefix[] = { - 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N', '(', '\0' }; - static const XML_Char enumValueSep[] = { '|', '\0' }; - static const XML_Char enumValueStart[] = { '(', '\0' }; + ASCII_N, ASCII_O, ASCII_T, ASCII_A, ASCII_T, ASCII_I, ASCII_O, ASCII_N, + ASCII_LPAREN, '\0' }; + static const XML_Char enumValueSep[] = { ASCII_PIPE, '\0' }; + static const XML_Char enumValueStart[] = { ASCII_LPAREN, '\0' }; /* save one level of indirection */ DTD * const dtd = _dtd; @@ -3950,11 +3964,11 @@ 0, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -3987,11 +4001,11 @@ declAttributeIsCdata, XML_FALSE, attVal, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -4318,14 +4332,14 @@ } break; case XML_ROLE_GROUP_SEQUENCE: - if (groupConnector[prologState.level] == '|') + if (groupConnector[prologState.level] == ASCII_PIPE) return XML_ERROR_SYNTAX; - groupConnector[prologState.level] = ','; + groupConnector[prologState.level] = ASCII_COMMA; if (dtd->in_eldecl && elementDeclHandler) handleDefault = XML_FALSE; break; case XML_ROLE_GROUP_CHOICE: - if (groupConnector[prologState.level] == ',') + if (groupConnector[prologState.level] == ASCII_COMMA) return XML_ERROR_SYNTAX; if (dtd->in_eldecl && !groupConnector[prologState.level] @@ -4337,7 +4351,7 @@ if (elementDeclHandler) handleDefault = XML_FALSE; } - groupConnector[prologState.level] = '|'; + groupConnector[prologState.level] = ASCII_PIPE; break; case XML_ROLE_PARAM_ENTITY_REF: #ifdef XML_DTD @@ -5267,7 +5281,7 @@ DTD * const dtd = _dtd; /* save one level of indirection */ const XML_Char *name; for (name = elementType->name; *name; name++) { - if (*name == XML_T(':')) { + if (*name == XML_T(ASCII_COLON)) { PREFIX *prefix; const XML_Char *s; for (s = elementType->name; s != name; s++) { @@ -5314,12 +5328,12 @@ poolFinish(&dtd->pool); if (!ns) ; - else if (name[0] == XML_T('x') - && name[1] == XML_T('m') - && name[2] == XML_T('l') - && name[3] == XML_T('n') - && name[4] == XML_T('s') - && (name[5] == XML_T('\0') || name[5] == XML_T(':'))) { + else if (name[0] == XML_T(ASCII_x) + && name[1] == XML_T(ASCII_m) + && name[2] == XML_T(ASCII_l) + && name[3] == XML_T(ASCII_n) + && name[4] == XML_T(ASCII_s) + && (name[5] == XML_T('\0') || name[5] == XML_T(ASCII_COLON))) { if (name[5] == XML_T('\0')) id->prefix = &dtd->defaultPrefix; else @@ -5330,7 +5344,7 @@ int i; for (i = 0; name[i]; i++) { /* attributes without prefix are *not* in the default namespace */ - if (name[i] == XML_T(':')) { + if (name[i] == XML_T(ASCII_COLON)) { int j; for (j = 0; j < i; j++) { if (!poolAppendChar(&dtd->pool, name[j])) @@ -5352,7 +5366,7 @@ return id; } -#define CONTEXT_SEP XML_T('\f') +#define CONTEXT_SEP XML_T(ASCII_FF) static const XML_Char * getContext(XML_Parser parser) @@ -5364,7 +5378,7 @@ if (dtd->defaultPrefix.binding) { int i; int len; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = dtd->defaultPrefix.binding->uriLen; if (namespaceSeparator) @@ -5390,7 +5404,7 @@ for (s = prefix->name; *s; s++) if (!poolAppendChar(&tempPool, *s)) return NULL; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = prefix->binding->uriLen; if (namespaceSeparator) @@ -5442,7 +5456,7 @@ context = s; poolDiscard(&tempPool); } - else if (*s == XML_T('=')) { + else if (*s == XML_T(ASCII_EQUALS)) { PREFIX *prefix; if (poolLength(&tempPool) == 0) prefix = &dtd->defaultPrefix; ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 03:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 18:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 12:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 22:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 19:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 11:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Tue May 8 00:08:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 15:08:41 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 15:31 Message generated for change (Comment added) made by klemscot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Scott Klement (klemscot) Date: 2007-05-07 17:08 Message: Logged In: YES user_id=223473 Originator: YES Gak, I didn't notice the file upload option until you pointed it out! Yes, I'll upload it as an attachment. Thanks. File Added: expat.diff ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-07 16:51 Message: Logged In: YES user_id=290026 Originator: NO Thanks very much for catching this! I didn't think of EBCDIC, I have to admit. Could you please attach you patch as a file. SF has added a few line breaks on the web page (and what not). ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:30 Message: Logged In: YES user_id=223473 Originator: YES Ooops. Sorry about the duplicate comment! Here's a patch (Unified Diff) that solves the problem for me. --- /home/klemscot/as400/expat-2.0.0.orig/lib/ascii.h Tue Nov 12 15:45:57 2002 +++ ./ascii.h Mon May 7 01:25:36 2007 @@ -83,3 +83,10 @@ #define ASCII_LSQB 0x5B #define ASCII_RSQB 0x5D #define ASCII_UNDERSCORE 0x5F +#define ASCII_LPAREN 0x28 +#define ASCII_RPAREN 0x29 +#define ASCII_FF 0x0C +#define ASCII_SLASH 0x2F +#define ASCII_HASH 0x23 +#define ASCII_PIPE 0x7C +#define ASCII_COMMA 0x2C --- /home/klemscot/as400/expat-2.0.0.orig/lib/xmlparse.c Fri Dec 23 08:45:27 2005 +++ ./xmlparse.c Mon May 7 01:21:55 2007 @@ -5,6 +5,7 @@ #include #include /* memset(), memcpy() */ #include +#include #define XML_BUILDING_EXPAT 1 @@ -665,10 +666,12 @@ } static const XML_Char implicitContext[] = { - 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_x, ASCII_m, ASCII_l, ASCII_EQUALS, ASCII_h, ASCII_t, ASCII_t, ASCII_p, + ASCII_COLON, ASCII_SLASH, ASCII_SLASH, ASCII_w, ASCII_w, ASCII_w, + ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, ASCII_o, ASCII_r, ASCII_g, + ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, ASCII_SLASH, ASCII_1, ASCII_9, + ASCII_9, ASCII_8, ASCII_SLASH, ASCII_n, ASCII_a, ASCII_m, ASCII_e, + ASCII_s, ASCII_p, ASCII_a, ASCII_c, ASCII_e, '\0' }; XML_Parser XMLCALL @@ -761,7 +764,7 @@ unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; - namespaceSeparator = '!'; + namespaceSeparator = ASCII_EXCL; ns = XML_FALSE; ns_triplets = XML_FALSE; @@ -2806,7 +2809,7 @@ return XML_ERROR_NO_MEMORY; uriHash = CHAR_HASH(uriHash, c); } - while (*s++ != XML_T(':')) + while (*s++ != XML_T(ASCII_COLON)) ; do { /* copies null terminator */ const XML_Char c = *s; @@ -2880,7 +2883,7 @@ if (!binding) return XML_ERROR_UNBOUND_PREFIX; localPart = tagNamePtr->str; - while (*localPart++ != XML_T(':')) + while (*localPart++ != XML_T(ASCII_COLON)) ; } else if (dtd->defaultPrefix.binding) { @@ -2935,17 +2938,21 @@ const XML_Char *uri, BINDING **bindingsPtr) { static const XML_Char xmlNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, + ASCII_SLASH, ASCII_1, ASCII_9, ASCII_9, ASCII_8, ASCII_SLASH, + ASCII_n, ASCII_a, ASCII_m, ASCII_e, ASCII_s, ASCII_p, ASCII_a, ASCII_c, + ASCII_e, '\0' }; static const int xmlLen = (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; static const XML_Char xmlnsNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_2, ASCII_0, ASCII_0, + ASCII_0, ASCII_SLASH, ASCII_x, ASCII_m, ASCII_l, ASCII_n, ASCII_s, + ASCII_SLASH, '\0' }; static const int xmlnsLen = (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; @@ -2962,13 +2969,13 @@ return XML_ERROR_UNDECLARING_PREFIX; if (prefix->name - && prefix->name[0] == XML_T('x') - && prefix->name[1] == XML_T('m') - && prefix->name[2] == XML_T('l')) { + && prefix->name[0] == XML_T(ASCII_x) + && prefix->name[1] == XML_T(ASCII_m) + && prefix->name[2] == XML_T(ASCII_l)) { /* Not allowed to bind xmlns */ - if (prefix->name[3] == XML_T('n') - && prefix->name[4] == XML_T('s') + if (prefix->name[3] == XML_T(ASCII_n) + && prefix->name[4] == XML_T(ASCII_s) && prefix->name[5] == XML_T('\0')) return XML_ERROR_RESERVED_PREFIX_XMLNS; @@ -3628,23 +3635,30 @@ XML_Bool haveMore) { #ifdef XML_DTD - static const XML_Char externalSubsetName[] = { '#' , '\0' }; + static const XML_Char externalSubsetName[] = { ASCII_HASH , '\0' }; #endif /* XML_DTD */ - static const XML_Char atypeCDATA[] = { 'C', 'D', 'A', 'T', 'A', '\0' }; - static const XML_Char atypeID[] = { 'I', 'D', '\0' }; - static const XML_Char atypeIDREF[] = { 'I', 'D', 'R', 'E', 'F', '\0' }; - static const XML_Char atypeIDREFS[] = { 'I', 'D', 'R', 'E', 'F', 'S', '\0' }; - static const XML_Char atypeENTITY[] = { 'E', 'N', 'T', 'I', 'T', 'Y', '\0' }; + static const XML_Char atypeCDATA[] = { ASCII_C, ASCII_D, ASCII_A, ASCII_T, + ASCII_A, '\0' }; + static const XML_Char atypeID[] = { ASCII_I, ASCII_D, '\0' }; + static const XML_Char atypeIDREF[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, '\0' }; + static const XML_Char atypeIDREFS[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, ASCII_S, '\0' }; + static const XML_Char atypeENTITY[] = { ASCII_E, ASCII_N, ASCII_T, ASCII_I, + ASCII_T, ASCII_Y, '\0' }; static const XML_Char atypeENTITIES[] = - { 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S', '\0' }; + { ASCII_E, ASCII_N, ASCII_T, ASCII_I, ASCII_T, ASCII_I, ASCII_E, + ASCII_S, '\0' }; static const XML_Char atypeNMTOKEN[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, '\0' }; static const XML_Char atypeNMTOKENS[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, + ASCII_S, '\0' }; static const XML_Char notationPrefix[] = { - 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N', '(', '\0' }; - static const XML_Char enumValueSep[] = { '|', '\0' }; - static const XML_Char enumValueStart[] = { '(', '\0' }; + ASCII_N, ASCII_O, ASCII_T, ASCII_A, ASCII_T, ASCII_I, ASCII_O, ASCII_N, + ASCII_LPAREN, '\0' }; + static const XML_Char enumValueSep[] = { ASCII_PIPE, '\0' }; + static const XML_Char enumValueStart[] = { ASCII_LPAREN, '\0' }; /* save one level of indirection */ DTD * const dtd = _dtd; @@ -3950,11 +3964,11 @@ 0, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -3987,11 +4001,11 @@ declAttributeIsCdata, XML_FALSE, attVal, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -4318,14 +4332,14 @@ } break; case XML_ROLE_GROUP_SEQUENCE: - if (groupConnector[prologState.level] == '|') + if (groupConnector[prologState.level] == ASCII_PIPE) return XML_ERROR_SYNTAX; - groupConnector[prologState.level] = ','; + groupConnector[prologState.level] = ASCII_COMMA; if (dtd->in_eldecl && elementDeclHandler) handleDefault = XML_FALSE; break; case XML_ROLE_GROUP_CHOICE: - if (groupConnector[prologState.level] == ',') + if (groupConnector[prologState.level] == ASCII_COMMA) return XML_ERROR_SYNTAX; if (dtd->in_eldecl && !groupConnector[prologState.level] @@ -4337,7 +4351,7 @@ if (elementDeclHandler) handleDefault = XML_FALSE; } - groupConnector[prologState.level] = '|'; + groupConnector[prologState.level] = ASCII_PIPE; break; case XML_ROLE_PARAM_ENTITY_REF: #ifdef XML_DTD @@ -5267,7 +5281,7 @@ DTD * const dtd = _dtd; /* save one level of indirection */ const XML_Char *name; for (name = elementType->name; *name; name++) { - if (*name == XML_T(':')) { + if (*name == XML_T(ASCII_COLON)) { PREFIX *prefix; const XML_Char *s; for (s = elementType->name; s != name; s++) { @@ -5314,12 +5328,12 @@ poolFinish(&dtd->pool); if (!ns) ; - else if (name[0] == XML_T('x') - && name[1] == XML_T('m') - && name[2] == XML_T('l') - && name[3] == XML_T('n') - && name[4] == XML_T('s') - && (name[5] == XML_T('\0') || name[5] == XML_T(':'))) { + else if (name[0] == XML_T(ASCII_x) + && name[1] == XML_T(ASCII_m) + && name[2] == XML_T(ASCII_l) + && name[3] == XML_T(ASCII_n) + && name[4] == XML_T(ASCII_s) + && (name[5] == XML_T('\0') || name[5] == XML_T(ASCII_COLON))) { if (name[5] == XML_T('\0')) id->prefix = &dtd->defaultPrefix; else @@ -5330,7 +5344,7 @@ int i; for (i = 0; name[i]; i++) { /* attributes without prefix are *not* in the default namespace */ - if (name[i] == XML_T(':')) { + if (name[i] == XML_T(ASCII_COLON)) { int j; for (j = 0; j < i; j++) { if (!poolAppendChar(&dtd->pool, name[j])) @@ -5352,7 +5366,7 @@ return id; } -#define CONTEXT_SEP XML_T('\f') +#define CONTEXT_SEP XML_T(ASCII_FF) static const XML_Char * getContext(XML_Parser parser) @@ -5364,7 +5378,7 @@ if (dtd->defaultPrefix.binding) { int i; int len; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = dtd->defaultPrefix.binding->uriLen; if (namespaceSeparator) @@ -5390,7 +5404,7 @@ for (s = prefix->name; *s; s++) if (!poolAppendChar(&tempPool, *s)) return NULL; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = prefix->binding->uriLen; if (namespaceSeparator) @@ -5442,7 +5456,7 @@ context = s; poolDiscard(&tempPool); } - else if (*s == XML_T('=')) { + else if (*s == XML_T(ASCII_EQUALS)) { PREFIX *prefix; if (poolLength(&tempPool) == 0) prefix = &dtd->defaultPrefix; ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 17:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 21:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 18:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 10:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Tue May 8 04:27:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 May 2007 19:27:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 16:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-07 22:27 Message: Logged In: YES user_id=290026 Originator: NO Patch applied in ascii.h rev. 1.5 and xmlparse.c rev. 1.161. Would you please try a build from CVS and see if it still works for you. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 18:08 Message: Logged In: YES user_id=223473 Originator: YES Gak, I didn't notice the file upload option until you pointed it out! Yes, I'll upload it as an attachment. Thanks. File Added: expat.diff ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-07 17:51 Message: Logged In: YES user_id=290026 Originator: NO Thanks very much for catching this! I didn't think of EBCDIC, I have to admit. Could you please attach you patch as a file. SF has added a few line breaks on the web page (and what not). ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 03:30 Message: Logged In: YES user_id=223473 Originator: YES Ooops. Sorry about the duplicate comment! Here's a patch (Unified Diff) that solves the problem for me. --- /home/klemscot/as400/expat-2.0.0.orig/lib/ascii.h Tue Nov 12 15:45:57 2002 +++ ./ascii.h Mon May 7 01:25:36 2007 @@ -83,3 +83,10 @@ #define ASCII_LSQB 0x5B #define ASCII_RSQB 0x5D #define ASCII_UNDERSCORE 0x5F +#define ASCII_LPAREN 0x28 +#define ASCII_RPAREN 0x29 +#define ASCII_FF 0x0C +#define ASCII_SLASH 0x2F +#define ASCII_HASH 0x23 +#define ASCII_PIPE 0x7C +#define ASCII_COMMA 0x2C --- /home/klemscot/as400/expat-2.0.0.orig/lib/xmlparse.c Fri Dec 23 08:45:27 2005 +++ ./xmlparse.c Mon May 7 01:21:55 2007 @@ -5,6 +5,7 @@ #include #include /* memset(), memcpy() */ #include +#include #define XML_BUILDING_EXPAT 1 @@ -665,10 +666,12 @@ } static const XML_Char implicitContext[] = { - 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_x, ASCII_m, ASCII_l, ASCII_EQUALS, ASCII_h, ASCII_t, ASCII_t, ASCII_p, + ASCII_COLON, ASCII_SLASH, ASCII_SLASH, ASCII_w, ASCII_w, ASCII_w, + ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, ASCII_o, ASCII_r, ASCII_g, + ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, ASCII_SLASH, ASCII_1, ASCII_9, + ASCII_9, ASCII_8, ASCII_SLASH, ASCII_n, ASCII_a, ASCII_m, ASCII_e, + ASCII_s, ASCII_p, ASCII_a, ASCII_c, ASCII_e, '\0' }; XML_Parser XMLCALL @@ -761,7 +764,7 @@ unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; - namespaceSeparator = '!'; + namespaceSeparator = ASCII_EXCL; ns = XML_FALSE; ns_triplets = XML_FALSE; @@ -2806,7 +2809,7 @@ return XML_ERROR_NO_MEMORY; uriHash = CHAR_HASH(uriHash, c); } - while (*s++ != XML_T(':')) + while (*s++ != XML_T(ASCII_COLON)) ; do { /* copies null terminator */ const XML_Char c = *s; @@ -2880,7 +2883,7 @@ if (!binding) return XML_ERROR_UNBOUND_PREFIX; localPart = tagNamePtr->str; - while (*localPart++ != XML_T(':')) + while (*localPart++ != XML_T(ASCII_COLON)) ; } else if (dtd->defaultPrefix.binding) { @@ -2935,17 +2938,21 @@ const XML_Char *uri, BINDING **bindingsPtr) { static const XML_Char xmlNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, + ASCII_SLASH, ASCII_1, ASCII_9, ASCII_9, ASCII_8, ASCII_SLASH, + ASCII_n, ASCII_a, ASCII_m, ASCII_e, ASCII_s, ASCII_p, ASCII_a, ASCII_c, + ASCII_e, '\0' }; static const int xmlLen = (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; static const XML_Char xmlnsNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_2, ASCII_0, ASCII_0, + ASCII_0, ASCII_SLASH, ASCII_x, ASCII_m, ASCII_l, ASCII_n, ASCII_s, + ASCII_SLASH, '\0' }; static const int xmlnsLen = (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; @@ -2962,13 +2969,13 @@ return XML_ERROR_UNDECLARING_PREFIX; if (prefix->name - && prefix->name[0] == XML_T('x') - && prefix->name[1] == XML_T('m') - && prefix->name[2] == XML_T('l')) { + && prefix->name[0] == XML_T(ASCII_x) + && prefix->name[1] == XML_T(ASCII_m) + && prefix->name[2] == XML_T(ASCII_l)) { /* Not allowed to bind xmlns */ - if (prefix->name[3] == XML_T('n') - && prefix->name[4] == XML_T('s') + if (prefix->name[3] == XML_T(ASCII_n) + && prefix->name[4] == XML_T(ASCII_s) && prefix->name[5] == XML_T('\0')) return XML_ERROR_RESERVED_PREFIX_XMLNS; @@ -3628,23 +3635,30 @@ XML_Bool haveMore) { #ifdef XML_DTD - static const XML_Char externalSubsetName[] = { '#' , '\0' }; + static const XML_Char externalSubsetName[] = { ASCII_HASH , '\0' }; #endif /* XML_DTD */ - static const XML_Char atypeCDATA[] = { 'C', 'D', 'A', 'T', 'A', '\0' }; - static const XML_Char atypeID[] = { 'I', 'D', '\0' }; - static const XML_Char atypeIDREF[] = { 'I', 'D', 'R', 'E', 'F', '\0' }; - static const XML_Char atypeIDREFS[] = { 'I', 'D', 'R', 'E', 'F', 'S', '\0' }; - static const XML_Char atypeENTITY[] = { 'E', 'N', 'T', 'I', 'T', 'Y', '\0' }; + static const XML_Char atypeCDATA[] = { ASCII_C, ASCII_D, ASCII_A, ASCII_T, + ASCII_A, '\0' }; + static const XML_Char atypeID[] = { ASCII_I, ASCII_D, '\0' }; + static const XML_Char atypeIDREF[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, '\0' }; + static const XML_Char atypeIDREFS[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, ASCII_S, '\0' }; + static const XML_Char atypeENTITY[] = { ASCII_E, ASCII_N, ASCII_T, ASCII_I, + ASCII_T, ASCII_Y, '\0' }; static const XML_Char atypeENTITIES[] = - { 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S', '\0' }; + { ASCII_E, ASCII_N, ASCII_T, ASCII_I, ASCII_T, ASCII_I, ASCII_E, + ASCII_S, '\0' }; static const XML_Char atypeNMTOKEN[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, '\0' }; static const XML_Char atypeNMTOKENS[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, + ASCII_S, '\0' }; static const XML_Char notationPrefix[] = { - 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N', '(', '\0' }; - static const XML_Char enumValueSep[] = { '|', '\0' }; - static const XML_Char enumValueStart[] = { '(', '\0' }; + ASCII_N, ASCII_O, ASCII_T, ASCII_A, ASCII_T, ASCII_I, ASCII_O, ASCII_N, + ASCII_LPAREN, '\0' }; + static const XML_Char enumValueSep[] = { ASCII_PIPE, '\0' }; + static const XML_Char enumValueStart[] = { ASCII_LPAREN, '\0' }; /* save one level of indirection */ DTD * const dtd = _dtd; @@ -3950,11 +3964,11 @@ 0, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -3987,11 +4001,11 @@ declAttributeIsCdata, XML_FALSE, attVal, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -4318,14 +4332,14 @@ } break; case XML_ROLE_GROUP_SEQUENCE: - if (groupConnector[prologState.level] == '|') + if (groupConnector[prologState.level] == ASCII_PIPE) return XML_ERROR_SYNTAX; - groupConnector[prologState.level] = ','; + groupConnector[prologState.level] = ASCII_COMMA; if (dtd->in_eldecl && elementDeclHandler) handleDefault = XML_FALSE; break; case XML_ROLE_GROUP_CHOICE: - if (groupConnector[prologState.level] == ',') + if (groupConnector[prologState.level] == ASCII_COMMA) return XML_ERROR_SYNTAX; if (dtd->in_eldecl && !groupConnector[prologState.level] @@ -4337,7 +4351,7 @@ if (elementDeclHandler) handleDefault = XML_FALSE; } - groupConnector[prologState.level] = '|'; + groupConnector[prologState.level] = ASCII_PIPE; break; case XML_ROLE_PARAM_ENTITY_REF: #ifdef XML_DTD @@ -5267,7 +5281,7 @@ DTD * const dtd = _dtd; /* save one level of indirection */ const XML_Char *name; for (name = elementType->name; *name; name++) { - if (*name == XML_T(':')) { + if (*name == XML_T(ASCII_COLON)) { PREFIX *prefix; const XML_Char *s; for (s = elementType->name; s != name; s++) { @@ -5314,12 +5328,12 @@ poolFinish(&dtd->pool); if (!ns) ; - else if (name[0] == XML_T('x') - && name[1] == XML_T('m') - && name[2] == XML_T('l') - && name[3] == XML_T('n') - && name[4] == XML_T('s') - && (name[5] == XML_T('\0') || name[5] == XML_T(':'))) { + else if (name[0] == XML_T(ASCII_x) + && name[1] == XML_T(ASCII_m) + && name[2] == XML_T(ASCII_l) + && name[3] == XML_T(ASCII_n) + && name[4] == XML_T(ASCII_s) + && (name[5] == XML_T('\0') || name[5] == XML_T(ASCII_COLON))) { if (name[5] == XML_T('\0')) id->prefix = &dtd->defaultPrefix; else @@ -5330,7 +5344,7 @@ int i; for (i = 0; name[i]; i++) { /* attributes without prefix are *not* in the default namespace */ - if (name[i] == XML_T(':')) { + if (name[i] == XML_T(ASCII_COLON)) { int j; for (j = 0; j < i; j++) { if (!poolAppendChar(&dtd->pool, name[j])) @@ -5352,7 +5366,7 @@ return id; } -#define CONTEXT_SEP XML_T('\f') +#define CONTEXT_SEP XML_T(ASCII_FF) static const XML_Char * getContext(XML_Parser parser) @@ -5364,7 +5378,7 @@ if (dtd->defaultPrefix.binding) { int i; int len; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = dtd->defaultPrefix.binding->uriLen; if (namespaceSeparator) @@ -5390,7 +5404,7 @@ for (s = prefix->name; *s; s++) if (!poolAppendChar(&tempPool, *s)) return NULL; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = prefix->binding->uriLen; if (namespaceSeparator) @@ -5442,7 +5456,7 @@ context = s; poolDiscard(&tempPool); } - else if (*s == XML_T('=')) { + else if (*s == XML_T(ASCII_EQUALS)) { PREFIX *prefix; if (poolLength(&tempPool) == 0) prefix = &dtd->defaultPrefix; ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 03:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 18:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 12:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 22:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 19:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 11:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Tue May 8 12:38:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 03:38:29 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 11:25 Message generated for change (Comment added) made by hmaldonado You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-08 10:38 Message: Logged In: YES user_id=1788089 Originator: NO I have the same problem on a combination of Mac OS X 10.4.9 + expat (Macport version) + Intel C/C++ Compiler fo Mac. I really don't know who this error concerns to but it seems it is related with the Intecl C/C++ compilers more than anything else. The problem arises because the configure script can not find memmove and bcopy. I have extracted the code generated by autoconf to test for the presence of memmove and tried to compile it with gcc and icc. GCC has not problems compiling it which as expected means that expat can be compiled with gcc without any trouble. However, ICC (Intel compiler) can not compile the code which means that the configure test will fail and memmove is considered as not present in the system which in turn triggers compilation errors. autoconf uses the following compiler options to compile the test code: icc -o conftest -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions ac_check_memmove.c And according to my research -fexceptions is the option making icc to fail. According to gcc documentation the -fexceptions option can make gcc to link the code to libstdc++ even when it is not a C++ program. However, it seems that icc does not do the same and outputs the following messages: ac_check_memmove.c(49): warning #310: old-style parameter list (anachronism) char memmove (); ^ ac_check_memmove.c(49): warning #1419: external declaration in primary source file char memmove (); ^ ac_check_memmove.c(67): remark #111: statement is unreachable return 0; ^ ld: Undefined symbols: ___gxx_personality_v0 The undefined symbol ___gxx_personality_v0 is, not surprisely, found at the libstdc++ library which is automatically included by gcc (trigger by the -fexceptions option) but not included by icc. If the option -lstdc++ is given manually to icc then the compilation succeeds. I think this explains the error and a quick solution for compiling expat will be adding -lstdc++ to the LDFLAGS environment variable at configuration time. LDFLAGS="-lstdc++" ./configure --prefix=/path/to/ ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 18:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 13:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 13:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 13:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 12:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 09:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Tue May 8 17:58:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 08:58:23 -0700 Subject: [Expat-bugs] [ expat-Bugs-1690883 ] Expat rejects xml: prefix with "unbound prefix" error. Message-ID: Bugs item #1690883, was opened at 2007-03-29 15:31 Message generated for change (Comment added) made by klemscot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Scott Klement (klemscot) Assigned to: Nobody/Anonymous (nobody) Summary: Expat rejects xml: prefix with "unbound prefix" error. Initial Comment: When namespace handling is enabled, Expat considers the following document invalid: Foo The error is "Unbound prefix", referring to the "xml:" prefix. However, according the W3C spec, it's not necessary to declare that particular prefix. I'm looking at the following document: http://www.w3.org/TR/REC-xml-names/ Under chapter 3, subheading "Namespace constraint: Reserved Prefixes and Namespace Names" This is the section I'm reading: The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. ****It MAY, but need not, be declared****, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. ---------------------------------------------------------------------- >Comment By: Scott Klement (klemscot) Date: 2007-05-08 10:58 Message: Logged In: YES user_id=223473 Originator: YES Confirmed. CVS build works great, problem solved! Thanks for your help. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-07 21:27 Message: Logged In: YES user_id=290026 Originator: NO Patch applied in ascii.h rev. 1.5 and xmlparse.c rev. 1.161. Would you please try a build from CVS and see if it still works for you. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 17:08 Message: Logged In: YES user_id=223473 Originator: YES Gak, I didn't notice the file upload option until you pointed it out! Yes, I'll upload it as an attachment. Thanks. File Added: expat.diff ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-07 16:51 Message: Logged In: YES user_id=290026 Originator: NO Thanks very much for catching this! I didn't think of EBCDIC, I have to admit. Could you please attach you patch as a file. SF has added a few line breaks on the web page (and what not). ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:30 Message: Logged In: YES user_id=223473 Originator: YES Ooops. Sorry about the duplicate comment! Here's a patch (Unified Diff) that solves the problem for me. --- /home/klemscot/as400/expat-2.0.0.orig/lib/ascii.h Tue Nov 12 15:45:57 2002 +++ ./ascii.h Mon May 7 01:25:36 2007 @@ -83,3 +83,10 @@ #define ASCII_LSQB 0x5B #define ASCII_RSQB 0x5D #define ASCII_UNDERSCORE 0x5F +#define ASCII_LPAREN 0x28 +#define ASCII_RPAREN 0x29 +#define ASCII_FF 0x0C +#define ASCII_SLASH 0x2F +#define ASCII_HASH 0x23 +#define ASCII_PIPE 0x7C +#define ASCII_COMMA 0x2C --- /home/klemscot/as400/expat-2.0.0.orig/lib/xmlparse.c Fri Dec 23 08:45:27 2005 +++ ./xmlparse.c Mon May 7 01:21:55 2007 @@ -5,6 +5,7 @@ #include #include /* memset(), memcpy() */ #include +#include #define XML_BUILDING_EXPAT 1 @@ -665,10 +666,12 @@ } static const XML_Char implicitContext[] = { - 'x', 'm', 'l', '=', 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_x, ASCII_m, ASCII_l, ASCII_EQUALS, ASCII_h, ASCII_t, ASCII_t, ASCII_p, + ASCII_COLON, ASCII_SLASH, ASCII_SLASH, ASCII_w, ASCII_w, ASCII_w, + ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, ASCII_o, ASCII_r, ASCII_g, + ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, ASCII_SLASH, ASCII_1, ASCII_9, + ASCII_9, ASCII_8, ASCII_SLASH, ASCII_n, ASCII_a, ASCII_m, ASCII_e, + ASCII_s, ASCII_p, ASCII_a, ASCII_c, ASCII_e, '\0' }; XML_Parser XMLCALL @@ -761,7 +764,7 @@ unknownEncodingHandler = NULL; unknownEncodingHandlerData = NULL; - namespaceSeparator = '!'; + namespaceSeparator = ASCII_EXCL; ns = XML_FALSE; ns_triplets = XML_FALSE; @@ -2806,7 +2809,7 @@ return XML_ERROR_NO_MEMORY; uriHash = CHAR_HASH(uriHash, c); } - while (*s++ != XML_T(':')) + while (*s++ != XML_T(ASCII_COLON)) ; do { /* copies null terminator */ const XML_Char c = *s; @@ -2880,7 +2883,7 @@ if (!binding) return XML_ERROR_UNBOUND_PREFIX; localPart = tagNamePtr->str; - while (*localPart++ != XML_T(':')) + while (*localPart++ != XML_T(ASCII_COLON)) ; } else if (dtd->defaultPrefix.binding) { @@ -2935,17 +2938,21 @@ const XML_Char *uri, BINDING **bindingsPtr) { static const XML_Char xmlNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', - 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_X, ASCII_M, ASCII_L, + ASCII_SLASH, ASCII_1, ASCII_9, ASCII_9, ASCII_8, ASCII_SLASH, + ASCII_n, ASCII_a, ASCII_m, ASCII_e, ASCII_s, ASCII_p, ASCII_a, ASCII_c, + ASCII_e, '\0' }; static const int xmlLen = (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; static const XML_Char xmlnsNamespace[] = { - 'h', 't', 't', 'p', ':', '/', '/', - 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', - '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' + ASCII_h, ASCII_t, ASCII_t, ASCII_p, ASCII_COLON, ASCII_SLASH, ASCII_SLASH, + ASCII_w, ASCII_w, ASCII_w, ASCII_PERIOD, ASCII_w, ASCII_3, ASCII_PERIOD, + ASCII_o, ASCII_r, ASCII_g, ASCII_SLASH, ASCII_2, ASCII_0, ASCII_0, + ASCII_0, ASCII_SLASH, ASCII_x, ASCII_m, ASCII_l, ASCII_n, ASCII_s, + ASCII_SLASH, '\0' }; static const int xmlnsLen = (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; @@ -2962,13 +2969,13 @@ return XML_ERROR_UNDECLARING_PREFIX; if (prefix->name - && prefix->name[0] == XML_T('x') - && prefix->name[1] == XML_T('m') - && prefix->name[2] == XML_T('l')) { + && prefix->name[0] == XML_T(ASCII_x) + && prefix->name[1] == XML_T(ASCII_m) + && prefix->name[2] == XML_T(ASCII_l)) { /* Not allowed to bind xmlns */ - if (prefix->name[3] == XML_T('n') - && prefix->name[4] == XML_T('s') + if (prefix->name[3] == XML_T(ASCII_n) + && prefix->name[4] == XML_T(ASCII_s) && prefix->name[5] == XML_T('\0')) return XML_ERROR_RESERVED_PREFIX_XMLNS; @@ -3628,23 +3635,30 @@ XML_Bool haveMore) { #ifdef XML_DTD - static const XML_Char externalSubsetName[] = { '#' , '\0' }; + static const XML_Char externalSubsetName[] = { ASCII_HASH , '\0' }; #endif /* XML_DTD */ - static const XML_Char atypeCDATA[] = { 'C', 'D', 'A', 'T', 'A', '\0' }; - static const XML_Char atypeID[] = { 'I', 'D', '\0' }; - static const XML_Char atypeIDREF[] = { 'I', 'D', 'R', 'E', 'F', '\0' }; - static const XML_Char atypeIDREFS[] = { 'I', 'D', 'R', 'E', 'F', 'S', '\0' }; - static const XML_Char atypeENTITY[] = { 'E', 'N', 'T', 'I', 'T', 'Y', '\0' }; + static const XML_Char atypeCDATA[] = { ASCII_C, ASCII_D, ASCII_A, ASCII_T, + ASCII_A, '\0' }; + static const XML_Char atypeID[] = { ASCII_I, ASCII_D, '\0' }; + static const XML_Char atypeIDREF[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, '\0' }; + static const XML_Char atypeIDREFS[] = { ASCII_I, ASCII_D, ASCII_R, ASCII_E, + ASCII_F, ASCII_S, '\0' }; + static const XML_Char atypeENTITY[] = { ASCII_E, ASCII_N, ASCII_T, ASCII_I, + ASCII_T, ASCII_Y, '\0' }; static const XML_Char atypeENTITIES[] = - { 'E', 'N', 'T', 'I', 'T', 'I', 'E', 'S', '\0' }; + { ASCII_E, ASCII_N, ASCII_T, ASCII_I, ASCII_T, ASCII_I, ASCII_E, + ASCII_S, '\0' }; static const XML_Char atypeNMTOKEN[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, '\0' }; static const XML_Char atypeNMTOKENS[] = { - 'N', 'M', 'T', 'O', 'K', 'E', 'N', 'S', '\0' }; + ASCII_N, ASCII_M, ASCII_T, ASCII_O, ASCII_K, ASCII_E, ASCII_N, + ASCII_S, '\0' }; static const XML_Char notationPrefix[] = { - 'N', 'O', 'T', 'A', 'T', 'I', 'O', 'N', '(', '\0' }; - static const XML_Char enumValueSep[] = { '|', '\0' }; - static const XML_Char enumValueStart[] = { '(', '\0' }; + ASCII_N, ASCII_O, ASCII_T, ASCII_A, ASCII_T, ASCII_I, ASCII_O, ASCII_N, + ASCII_LPAREN, '\0' }; + static const XML_Char enumValueSep[] = { ASCII_PIPE, '\0' }; + static const XML_Char enumValueStart[] = { ASCII_LPAREN, '\0' }; /* save one level of indirection */ DTD * const dtd = _dtd; @@ -3950,11 +3964,11 @@ 0, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -3987,11 +4001,11 @@ declAttributeIsCdata, XML_FALSE, attVal, parser)) return XML_ERROR_NO_MEMORY; if (attlistDeclHandler && declAttributeType) { - if (*declAttributeType == XML_T('(') - || (*declAttributeType == XML_T('N') - && declAttributeType[1] == XML_T('O'))) { + if (*declAttributeType == XML_T(ASCII_LPAREN) + || (*declAttributeType == XML_T(ASCII_N) + && declAttributeType[1] == XML_T(ASCII_O))) { /* Enumerated or Notation type */ - if (!poolAppendChar(&tempPool, XML_T(')')) + if (!poolAppendChar(&tempPool, XML_T(ASCII_RPAREN)) || !poolAppendChar(&tempPool, XML_T('\0'))) return XML_ERROR_NO_MEMORY; declAttributeType = tempPool.start; @@ -4318,14 +4332,14 @@ } break; case XML_ROLE_GROUP_SEQUENCE: - if (groupConnector[prologState.level] == '|') + if (groupConnector[prologState.level] == ASCII_PIPE) return XML_ERROR_SYNTAX; - groupConnector[prologState.level] = ','; + groupConnector[prologState.level] = ASCII_COMMA; if (dtd->in_eldecl && elementDeclHandler) handleDefault = XML_FALSE; break; case XML_ROLE_GROUP_CHOICE: - if (groupConnector[prologState.level] == ',') + if (groupConnector[prologState.level] == ASCII_COMMA) return XML_ERROR_SYNTAX; if (dtd->in_eldecl && !groupConnector[prologState.level] @@ -4337,7 +4351,7 @@ if (elementDeclHandler) handleDefault = XML_FALSE; } - groupConnector[prologState.level] = '|'; + groupConnector[prologState.level] = ASCII_PIPE; break; case XML_ROLE_PARAM_ENTITY_REF: #ifdef XML_DTD @@ -5267,7 +5281,7 @@ DTD * const dtd = _dtd; /* save one level of indirection */ const XML_Char *name; for (name = elementType->name; *name; name++) { - if (*name == XML_T(':')) { + if (*name == XML_T(ASCII_COLON)) { PREFIX *prefix; const XML_Char *s; for (s = elementType->name; s != name; s++) { @@ -5314,12 +5328,12 @@ poolFinish(&dtd->pool); if (!ns) ; - else if (name[0] == XML_T('x') - && name[1] == XML_T('m') - && name[2] == XML_T('l') - && name[3] == XML_T('n') - && name[4] == XML_T('s') - && (name[5] == XML_T('\0') || name[5] == XML_T(':'))) { + else if (name[0] == XML_T(ASCII_x) + && name[1] == XML_T(ASCII_m) + && name[2] == XML_T(ASCII_l) + && name[3] == XML_T(ASCII_n) + && name[4] == XML_T(ASCII_s) + && (name[5] == XML_T('\0') || name[5] == XML_T(ASCII_COLON))) { if (name[5] == XML_T('\0')) id->prefix = &dtd->defaultPrefix; else @@ -5330,7 +5344,7 @@ int i; for (i = 0; name[i]; i++) { /* attributes without prefix are *not* in the default namespace */ - if (name[i] == XML_T(':')) { + if (name[i] == XML_T(ASCII_COLON)) { int j; for (j = 0; j < i; j++) { if (!poolAppendChar(&dtd->pool, name[j])) @@ -5352,7 +5366,7 @@ return id; } -#define CONTEXT_SEP XML_T('\f') +#define CONTEXT_SEP XML_T(ASCII_FF) static const XML_Char * getContext(XML_Parser parser) @@ -5364,7 +5378,7 @@ if (dtd->defaultPrefix.binding) { int i; int len; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = dtd->defaultPrefix.binding->uriLen; if (namespaceSeparator) @@ -5390,7 +5404,7 @@ for (s = prefix->name; *s; s++) if (!poolAppendChar(&tempPool, *s)) return NULL; - if (!poolAppendChar(&tempPool, XML_T('='))) + if (!poolAppendChar(&tempPool, XML_T(ASCII_EQUALS))) return NULL; len = prefix->binding->uriLen; if (namespaceSeparator) @@ -5442,7 +5456,7 @@ context = s; poolDiscard(&tempPool); } - else if (*s == XML_T('=')) { + else if (*s == XML_T(ASCII_EQUALS)) { PREFIX *prefix; if (poolLength(&tempPool) == 0) prefix = &dtd->defaultPrefix; ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-07 02:26 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-05-06 17:10 Message: Logged In: YES user_id=223473 Originator: YES I suspect that the problem is due to the fact that I'm running Expat on an EBCDIC-based system. In most cases, Expat uses the macros defined in ascii.h, which work correctly, as they explicitly specify a hex code point. However, there are places where Expat will reference the character directly, expecting that the hex code point of the document will match the hex code point of a character typed into the source code. On an ASCII system, they match, on an EBCDIC system they don't. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-06 11:01 Message: Logged In: YES user_id=290026 Originator: NO Closing this as "Works for me", no follow-up from original poster. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 21:36 Message: Logged In: YES user_id=290026 Originator: NO Just tried with expat 2.0.0 and had no problems. Maybe you are picking up an old version that is still installed on your system? ---------------------------------------------------------------------- Comment By: Scott Klement (klemscot) Date: 2007-04-28 18:52 Message: Logged In: YES user_id=223473 Originator: YES Version 2.0.0. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-04-28 10:37 Message: Logged In: YES user_id=290026 Originator: NO I have no issues parsing this document with Expat CVS head. What version of Expat are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1690883&group_id=10127 From noreply at sourceforge.net Tue May 8 22:17:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 13:17:58 -0700 Subject: [Expat-bugs] [ expat-Bugs-1715239 ] test suite fails on sparc-sun-solaris2.10 (expat 2.0.0) Message-ID: Bugs item #1715239, was opened at 2007-05-08 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715239&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Elias Pipping (pipping) Assigned to: Nobody/Anonymous (nobody) Summary: test suite fails on sparc-sun-solaris2.10 (expat 2.0.0) Initial Comment: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715239&group_id=10127 From noreply at sourceforge.net Wed May 9 01:12:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 16:12:05 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 06:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 19:12 Message: Logged In: YES user_id=290026 Originator: NO Thanks for the nice analysis! Now, the question is (not being a Unix build expert), what can be done at the configuration level to deal with that in Expat? ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-08 06:38 Message: Logged In: YES user_id=1788089 Originator: NO I have the same problem on a combination of Mac OS X 10.4.9 + expat (Macport version) + Intel C/C++ Compiler fo Mac. I really don't know who this error concerns to but it seems it is related with the Intecl C/C++ compilers more than anything else. The problem arises because the configure script can not find memmove and bcopy. I have extracted the code generated by autoconf to test for the presence of memmove and tried to compile it with gcc and icc. GCC has not problems compiling it which as expected means that expat can be compiled with gcc without any trouble. However, ICC (Intel compiler) can not compile the code which means that the configure test will fail and memmove is considered as not present in the system which in turn triggers compilation errors. autoconf uses the following compiler options to compile the test code: icc -o conftest -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions ac_check_memmove.c And according to my research -fexceptions is the option making icc to fail. According to gcc documentation the -fexceptions option can make gcc to link the code to libstdc++ even when it is not a C++ program. However, it seems that icc does not do the same and outputs the following messages: ac_check_memmove.c(49): warning #310: old-style parameter list (anachronism) char memmove (); ^ ac_check_memmove.c(49): warning #1419: external declaration in primary source file char memmove (); ^ ac_check_memmove.c(67): remark #111: statement is unreachable return 0; ^ ld: Undefined symbols: ___gxx_personality_v0 The undefined symbol ___gxx_personality_v0 is, not surprisely, found at the libstdc++ library which is automatically included by gcc (trigger by the -fexceptions option) but not included by icc. If the option -lstdc++ is given manually to icc then the compilation succeeds. I think this explains the error and a quick solution for compiling expat will be adding -lstdc++ to the LDFLAGS environment variable at configuration time. LDFLAGS="-lstdc++" ./configure --prefix=/path/to/ ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 09:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 09:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 09:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 08:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 05:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 9 03:23:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 18:23:33 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 21:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 04:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 08:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-13 19:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 16:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 13:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 12:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 15:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 14:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Wed May 9 03:29:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 May 2007 18:29:13 -0700 Subject: [Expat-bugs] [ expat-Bugs-1715239 ] test suite fails on sparc-sun-solaris2.10 (expat 2.0.0) Message-ID: Bugs item #1715239, was opened at 2007-05-08 16:17 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715239&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Elias Pipping (pipping) Assigned to: Nobody/Anonymous (nobody) Summary: test suite fails on sparc-sun-solaris2.10 (expat 2.0.0) Initial Comment: ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 21:29 Message: Logged In: YES user_id=290026 Originator: NO Could this be related to issue # 1597115 - which is supposedly fixed ? Please check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715239&group_id=10127 From noreply at sourceforge.net Wed May 9 15:00:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 06:00:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 11:25 Message generated for change (Comment added) made by hmaldonado You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-09 13:00 Message: Logged In: YES user_id=1788089 Originator: NO Hi there I am not a UNIX build expert either but I think we can come up with some solutions. Let me explain: Firstly, I have already filed a report on the Intel Support Site and as of today they have updated the report with the following text: "Thank you for the detail report. I was able to reproduce the problem, and the issue have been escalated. I will update this issue after our investigation. Intel Customer Support" As you can see they have not given away so much information other that the report has been escalated (whatever that means in their system). Secondly, the main thing is that Intel wants its compiler to be 100% compatible with gcc so anyone can easily migrate from gcc to icc. For this particular option -fexceptions icc is failing to do so. The way icc interoperate with gcc is by sort of posing as a gcc compiler. icc predefined some macros that are predefined by gcc (__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__) so icc can be seen as gcc. After looking at expat's configure.in I found the following code: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi This code checks if GCC is present (using $GCC which is set by macro AC_PROG_CC which tests for the presence of __GNUC__) and adds some compilation options including -fexceptions (BTW: it would be ideal to know why this option is given as someone has already said that it is not such a good idea). The Intel Manual advices to set CC to icc and when autoconf is used to generate the configure script AC_PROG_CC will set GCC=yes (because icc predefines __GNUC__) and also set leaves CC untouched (CC=icc) (as indicated in the autoconf 2.61 manual). The code above will execute as GCC=yes is true and because icc does accept the option -fexceptions (although it does not handle it as expected) therefore the -fexceptions option is added to CFLAGS which, according with the autoconf manual, is used when compiling or linking programs to test for C features. The latter brings up the question: Why is the CFLAGS variable being modified in configure.in? Was whoever added it expecting that the compilation options would be used to compile the sources or did he/she know that these compilation options would affect the compilation of the sources as well as programs to test for C features (configure)? To the best of my understanding if one wants to compile the sources (e.g. lib/xmlparse.c) with some specific options then those options are given in the Makefile.am (if automake is being used) located in the directory where the sources are. The presence of CFLAGS in the configure.in may be because expat is not using automake (as far as I can see). However, I believe CFLAGS can still be given somewhere else. Then, our first problem is that the programs to test for C features are failing (memmove, bcopy, etc.) when compiling with icc because CFLAGS contains the -fexceptions option. There are different ways to solve this: a. Replace the following code at configure.in: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi >> WITH << if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether $CC accepts -fexceptions) AC_TRY_LINK( , , AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi The only two lines that change are AC_MSG_CHECKING... and AC_TRY_COMPILE... which now is using the macro AC_TRY_LINK. The reason for this is that -fexceptions only makes the Intel compiler fails when linking and not when compiling. This is the reason why the -fexceptions options is added when icc is used. By changing AC_TRY_COMPILE to AC_TRY_LINK (which implies a AC_TRY_COMPILE) the test will fail when using -fexceptions and this will prevent the -fexceptions option to be added. Also this solution has backwards compatibility with other GCC versions and when Intel fixes icc the -fexceptions option will be added as it would be supported. b. This solution involves to make a proper distinction between icc and gcc regarding the effords of icc to be seen as gcc. The line: if test "$GCC" = yes ; then can be changed for something that makes sure that the compiler is truly the gcc and not something else. One way would be to check is the __INTEL_COMPILER__ macro is defined. Then if this macro is defined and GCC = yes then we know that it is not the gcc compiler but something that is compatible. You folks are the right people to decide which way to go as you know the reasons why expat does not use automake, why -fexceptions is needed, etc. I have tried solution (a) and it worked fine on my system (of course I had to run autoconf after changing configure.in so that configure was updated) without any further changes. The configure script detects icc as my default compiler, identifies the -fexceptions option as NOT supported by icc and, finally, finds memmove and bcopy. Regards ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 23:12 Message: Logged In: YES user_id=290026 Originator: NO Thanks for the nice analysis! Now, the question is (not being a Unix build expert), what can be done at the configuration level to deal with that in Expat? ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-08 10:38 Message: Logged In: YES user_id=1788089 Originator: NO I have the same problem on a combination of Mac OS X 10.4.9 + expat (Macport version) + Intel C/C++ Compiler fo Mac. I really don't know who this error concerns to but it seems it is related with the Intecl C/C++ compilers more than anything else. The problem arises because the configure script can not find memmove and bcopy. I have extracted the code generated by autoconf to test for the presence of memmove and tried to compile it with gcc and icc. GCC has not problems compiling it which as expected means that expat can be compiled with gcc without any trouble. However, ICC (Intel compiler) can not compile the code which means that the configure test will fail and memmove is considered as not present in the system which in turn triggers compilation errors. autoconf uses the following compiler options to compile the test code: icc -o conftest -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions ac_check_memmove.c And according to my research -fexceptions is the option making icc to fail. According to gcc documentation the -fexceptions option can make gcc to link the code to libstdc++ even when it is not a C++ program. However, it seems that icc does not do the same and outputs the following messages: ac_check_memmove.c(49): warning #310: old-style parameter list (anachronism) char memmove (); ^ ac_check_memmove.c(49): warning #1419: external declaration in primary source file char memmove (); ^ ac_check_memmove.c(67): remark #111: statement is unreachable return 0; ^ ld: Undefined symbols: ___gxx_personality_v0 The undefined symbol ___gxx_personality_v0 is, not surprisely, found at the libstdc++ library which is automatically included by gcc (trigger by the -fexceptions option) but not included by icc. If the option -lstdc++ is given manually to icc then the compilation succeeds. I think this explains the error and a quick solution for compiling expat will be adding -lstdc++ to the LDFLAGS environment variable at configuration time. LDFLAGS="-lstdc++" ./configure --prefix=/path/to/ ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 18:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 13:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 13:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 13:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 12:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 09:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 9 15:28:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 06:28:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 06:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 09:28 Message: Logged In: YES user_id=290026 Originator: NO Thanks again for you exemplary feedback! > This code checks if GCC is present (using $GCC which is set by > macro AC_PROG_CC which tests for the presence of __GNUC__) and > adds some compilation options including -fexceptions > (BTW: it would be ideal to know why this option is given as\ > someone has already said that it is not such a good idea). I think the reason it to better interoperate with call-backs that throw exceptions, so that the exceptions can pass though to the original caller of XML_Parse(). Expat is called from other languages as well! > The latter brings up the question: Why is the CFLAGS variable > being modified in configure.in? Was whoever added it expecting > that the compilation options would be used to compile the sources > or did he/she know that these compilation options would affect > the compilation of the sources as well as programs to test for > C features (configure)? The CFLags can be modified as arguments to configure in order to build the UTF-16 version of Expat (libexpatw.so/dll). (see README). We are not using automake, because our main build expert (Greg Stein) has too many bad experiences with it, and for Expat he considers it overkill. I prefer your first fix option, and have applied it to configure.in rev. 1.45. Needs testing on other platforms. ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-09 09:00 Message: Logged In: YES user_id=1788089 Originator: NO Hi there I am not a UNIX build expert either but I think we can come up with some solutions. Let me explain: Firstly, I have already filed a report on the Intel Support Site and as of today they have updated the report with the following text: "Thank you for the detail report. I was able to reproduce the problem, and the issue have been escalated. I will update this issue after our investigation. Intel Customer Support" As you can see they have not given away so much information other that the report has been escalated (whatever that means in their system). Secondly, the main thing is that Intel wants its compiler to be 100% compatible with gcc so anyone can easily migrate from gcc to icc. For this particular option -fexceptions icc is failing to do so. The way icc interoperate with gcc is by sort of posing as a gcc compiler. icc predefined some macros that are predefined by gcc (__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__) so icc can be seen as gcc. After looking at expat's configure.in I found the following code: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi This code checks if GCC is present (using $GCC which is set by macro AC_PROG_CC which tests for the presence of __GNUC__) and adds some compilation options including -fexceptions (BTW: it would be ideal to know why this option is given as someone has already said that it is not such a good idea). The Intel Manual advices to set CC to icc and when autoconf is used to generate the configure script AC_PROG_CC will set GCC=yes (because icc predefines __GNUC__) and also set leaves CC untouched (CC=icc) (as indicated in the autoconf 2.61 manual). The code above will execute as GCC=yes is true and because icc does accept the option -fexceptions (although it does not handle it as expected) therefore the -fexceptions option is added to CFLAGS which, according with the autoconf manual, is used when compiling or linking programs to test for C features. The latter brings up the question: Why is the CFLAGS variable being modified in configure.in? Was whoever added it expecting that the compilation options would be used to compile the sources or did he/she know that these compilation options would affect the compilation of the sources as well as programs to test for C features (configure)? To the best of my understanding if one wants to compile the sources (e.g. lib/xmlparse.c) with some specific options then those options are given in the Makefile.am (if automake is being used) located in the directory where the sources are. The presence of CFLAGS in the configure.in may be because expat is not using automake (as far as I can see). However, I believe CFLAGS can still be given somewhere else. Then, our first problem is that the programs to test for C features are failing (memmove, bcopy, etc.) when compiling with icc because CFLAGS contains the -fexceptions option. There are different ways to solve this: a. Replace the following code at configure.in: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi >> WITH << if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether $CC accepts -fexceptions) AC_TRY_LINK( , , AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi The only two lines that change are AC_MSG_CHECKING... and AC_TRY_COMPILE... which now is using the macro AC_TRY_LINK. The reason for this is that -fexceptions only makes the Intel compiler fails when linking and not when compiling. This is the reason why the -fexceptions options is added when icc is used. By changing AC_TRY_COMPILE to AC_TRY_LINK (which implies a AC_TRY_COMPILE) the test will fail when using -fexceptions and this will prevent the -fexceptions option to be added. Also this solution has backwards compatibility with other GCC versions and when Intel fixes icc the -fexceptions option will be added as it would be supported. b. This solution involves to make a proper distinction between icc and gcc regarding the effords of icc to be seen as gcc. The line: if test "$GCC" = yes ; then can be changed for something that makes sure that the compiler is truly the gcc and not something else. One way would be to check is the __INTEL_COMPILER__ macro is defined. Then if this macro is defined and GCC = yes then we know that it is not the gcc compiler but something that is compatible. You folks are the right people to decide which way to go as you know the reasons why expat does not use automake, why -fexceptions is needed, etc. I have tried solution (a) and it worked fine on my system (of course I had to run autoconf after changing configure.in so that configure was updated) without any further changes. The configure script detects icc as my default compiler, identifies the -fexceptions option as NOT supported by icc and, finally, finds memmove and bcopy. Regards ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 19:12 Message: Logged In: YES user_id=290026 Originator: NO Thanks for the nice analysis! Now, the question is (not being a Unix build expert), what can be done at the configuration level to deal with that in Expat? ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-08 06:38 Message: Logged In: YES user_id=1788089 Originator: NO I have the same problem on a combination of Mac OS X 10.4.9 + expat (Macport version) + Intel C/C++ Compiler fo Mac. I really don't know who this error concerns to but it seems it is related with the Intecl C/C++ compilers more than anything else. The problem arises because the configure script can not find memmove and bcopy. I have extracted the code generated by autoconf to test for the presence of memmove and tried to compile it with gcc and icc. GCC has not problems compiling it which as expected means that expat can be compiled with gcc without any trouble. However, ICC (Intel compiler) can not compile the code which means that the configure test will fail and memmove is considered as not present in the system which in turn triggers compilation errors. autoconf uses the following compiler options to compile the test code: icc -o conftest -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions ac_check_memmove.c And according to my research -fexceptions is the option making icc to fail. According to gcc documentation the -fexceptions option can make gcc to link the code to libstdc++ even when it is not a C++ program. However, it seems that icc does not do the same and outputs the following messages: ac_check_memmove.c(49): warning #310: old-style parameter list (anachronism) char memmove (); ^ ac_check_memmove.c(49): warning #1419: external declaration in primary source file char memmove (); ^ ac_check_memmove.c(67): remark #111: statement is unreachable return 0; ^ ld: Undefined symbols: ___gxx_personality_v0 The undefined symbol ___gxx_personality_v0 is, not surprisely, found at the libstdc++ library which is automatically included by gcc (trigger by the -fexceptions option) but not included by icc. If the option -lstdc++ is given manually to icc then the compilation succeeds. I think this explains the error and a quick solution for compiling expat will be adding -lstdc++ to the LDFLAGS environment variable at configuration time. LDFLAGS="-lstdc++" ./configure --prefix=/path/to/ ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 09:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 09:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 09:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 08:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 05:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 9 18:15:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 09:15:32 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 18:36 Message generated for change (Comment added) made by kosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 18:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 03:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 10:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 19:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 14:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-14 01:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 18:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 22:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 19:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 18:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 21:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 20:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 23:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 22:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 19:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Wed May 9 18:23:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 09:23:00 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 12:25 Message generated for change (Comment added) made by wiesmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- >Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-09 18:23 Message: Logged In: YES user_id=117374 Originator: YES I dont' think the problem is related to the build environnement. I have basically the same environnement (MacPorts 1.440) on a PPC PowerBook and an Intel Macbook. Expat builds fine on the PPC and fails on the Intel. The fact that the same problem arises with both ICC and GCC would indicate to me that configure has trouble with Darwin/Intel. I have attached the config.log file to this report. File Added: config.log ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 15:28 Message: Logged In: YES user_id=290026 Originator: NO Thanks again for you exemplary feedback! > This code checks if GCC is present (using $GCC which is set by > macro AC_PROG_CC which tests for the presence of __GNUC__) and > adds some compilation options including -fexceptions > (BTW: it would be ideal to know why this option is given as\ > someone has already said that it is not such a good idea). I think the reason it to better interoperate with call-backs that throw exceptions, so that the exceptions can pass though to the original caller of XML_Parse(). Expat is called from other languages as well! > The latter brings up the question: Why is the CFLAGS variable > being modified in configure.in? Was whoever added it expecting > that the compilation options would be used to compile the sources > or did he/she know that these compilation options would affect > the compilation of the sources as well as programs to test for > C features (configure)? The CFLags can be modified as arguments to configure in order to build the UTF-16 version of Expat (libexpatw.so/dll). (see README). We are not using automake, because our main build expert (Greg Stein) has too many bad experiences with it, and for Expat he considers it overkill. I prefer your first fix option, and have applied it to configure.in rev. 1.45. Needs testing on other platforms. ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-09 15:00 Message: Logged In: YES user_id=1788089 Originator: NO Hi there I am not a UNIX build expert either but I think we can come up with some solutions. Let me explain: Firstly, I have already filed a report on the Intel Support Site and as of today they have updated the report with the following text: "Thank you for the detail report. I was able to reproduce the problem, and the issue have been escalated. I will update this issue after our investigation. Intel Customer Support" As you can see they have not given away so much information other that the report has been escalated (whatever that means in their system). Secondly, the main thing is that Intel wants its compiler to be 100% compatible with gcc so anyone can easily migrate from gcc to icc. For this particular option -fexceptions icc is failing to do so. The way icc interoperate with gcc is by sort of posing as a gcc compiler. icc predefined some macros that are predefined by gcc (__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__) so icc can be seen as gcc. After looking at expat's configure.in I found the following code: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi This code checks if GCC is present (using $GCC which is set by macro AC_PROG_CC which tests for the presence of __GNUC__) and adds some compilation options including -fexceptions (BTW: it would be ideal to know why this option is given as someone has already said that it is not such a good idea). The Intel Manual advices to set CC to icc and when autoconf is used to generate the configure script AC_PROG_CC will set GCC=yes (because icc predefines __GNUC__) and also set leaves CC untouched (CC=icc) (as indicated in the autoconf 2.61 manual). The code above will execute as GCC=yes is true and because icc does accept the option -fexceptions (although it does not handle it as expected) therefore the -fexceptions option is added to CFLAGS which, according with the autoconf manual, is used when compiling or linking programs to test for C features. The latter brings up the question: Why is the CFLAGS variable being modified in configure.in? Was whoever added it expecting that the compilation options would be used to compile the sources or did he/she know that these compilation options would affect the compilation of the sources as well as programs to test for C features (configure)? To the best of my understanding if one wants to compile the sources (e.g. lib/xmlparse.c) with some specific options then those options are given in the Makefile.am (if automake is being used) located in the directory where the sources are. The presence of CFLAGS in the configure.in may be because expat is not using automake (as far as I can see). However, I believe CFLAGS can still be given somewhere else. Then, our first problem is that the programs to test for C features are failing (memmove, bcopy, etc.) when compiling with icc because CFLAGS contains the -fexceptions option. There are different ways to solve this: a. Replace the following code at configure.in: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi >> WITH << if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether $CC accepts -fexceptions) AC_TRY_LINK( , , AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi The only two lines that change are AC_MSG_CHECKING... and AC_TRY_COMPILE... which now is using the macro AC_TRY_LINK. The reason for this is that -fexceptions only makes the Intel compiler fails when linking and not when compiling. This is the reason why the -fexceptions options is added when icc is used. By changing AC_TRY_COMPILE to AC_TRY_LINK (which implies a AC_TRY_COMPILE) the test will fail when using -fexceptions and this will prevent the -fexceptions option to be added. Also this solution has backwards compatibility with other GCC versions and when Intel fixes icc the -fexceptions option will be added as it would be supported. b. This solution involves to make a proper distinction between icc and gcc regarding the effords of icc to be seen as gcc. The line: if test "$GCC" = yes ; then can be changed for something that makes sure that the compiler is truly the gcc and not something else. One way would be to check is the __INTEL_COMPILER__ macro is defined. Then if this macro is defined and GCC = yes then we know that it is not the gcc compiler but something that is compatible. You folks are the right people to decide which way to go as you know the reasons why expat does not use automake, why -fexceptions is needed, etc. I have tried solution (a) and it worked fine on my system (of course I had to run autoconf after changing configure.in so that configure was updated) without any further changes. The configure script detects icc as my default compiler, identifies the -fexceptions option as NOT supported by icc and, finally, finds memmove and bcopy. Regards ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 01:12 Message: Logged In: YES user_id=290026 Originator: NO Thanks for the nice analysis! Now, the question is (not being a Unix build expert), what can be done at the configuration level to deal with that in Expat? ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-08 12:38 Message: Logged In: YES user_id=1788089 Originator: NO I have the same problem on a combination of Mac OS X 10.4.9 + expat (Macport version) + Intel C/C++ Compiler fo Mac. I really don't know who this error concerns to but it seems it is related with the Intecl C/C++ compilers more than anything else. The problem arises because the configure script can not find memmove and bcopy. I have extracted the code generated by autoconf to test for the presence of memmove and tried to compile it with gcc and icc. GCC has not problems compiling it which as expected means that expat can be compiled with gcc without any trouble. However, ICC (Intel compiler) can not compile the code which means that the configure test will fail and memmove is considered as not present in the system which in turn triggers compilation errors. autoconf uses the following compiler options to compile the test code: icc -o conftest -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions ac_check_memmove.c And according to my research -fexceptions is the option making icc to fail. According to gcc documentation the -fexceptions option can make gcc to link the code to libstdc++ even when it is not a C++ program. However, it seems that icc does not do the same and outputs the following messages: ac_check_memmove.c(49): warning #310: old-style parameter list (anachronism) char memmove (); ^ ac_check_memmove.c(49): warning #1419: external declaration in primary source file char memmove (); ^ ac_check_memmove.c(67): remark #111: statement is unreachable return 0; ^ ld: Undefined symbols: ___gxx_personality_v0 The undefined symbol ___gxx_personality_v0 is, not surprisely, found at the libstdc++ library which is automatically included by gcc (trigger by the -fexceptions option) but not included by icc. If the option -lstdc++ is given manually to icc then the compilation succeeds. I think this explains the error and a quick solution for compiling expat will be adding -lstdc++ to the LDFLAGS environment variable at configuration time. LDFLAGS="-lstdc++" ./configure --prefix=/path/to/ ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 20:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 15:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 15:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 11:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 9 18:50:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 09:50:51 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 18:36 Message generated for change (Comment added) made by mhaubi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-09 18:50 Message: Logged In: YES user_id=839786 Originator: NO > Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) > many people use DESTDIR. To reduce confusions, I intendet to support both > variables. As you do not use DESTDIR as make-argument, but INSTALL_ROOT as environment variable, my proposed change should work, because INSTALL_ROOT itself is not defined in the Makefile, and thus the environment-value of INSTALL_ROOT is used for DESTDIR (see also '-e' below). In GNU world, DESTDIR normally is used as make-parameter, not from environment, so when DESTDIR is set as make-argument, INSTALL_ROOT environment variable becomes irrelevant. > But I really suggest evryone to use GNU make, even on nun-GNU platforms > (AFAIK it should run on most other unix'es too). This releaves us from the > ugly job of supporting each single esotic make. Agreed somewhat - but if it is that easy to avoid an additional specific dependency, why not do it (especially if you do not need to fix it yourself) ? > Ah, important to mention: env variables should *NOT* be overwritten by > defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" > or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's > life much, much easier. This only is true if you pass '-e' to make(1), as stated in the manpages, it is _not_ done by default: -e, --environment-overrides Give variables taken from the environment precedence over vari- ables from makefiles. According to their manpages, this is true for GNU-make as well as native make on hpux, aix, solaris, freebsd, interix (do not have access to others). With my proposed patch, both your methods should work. It will not work only if you: 1) have DESTDIR in the environment set to a value != INSTALL_ROOT 2) _and_ pass '-e' to make (commandline or in MAKEFLAGS/MFLAGS environment variable). ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 18:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 03:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 10:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 19:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 14:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-14 01:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 18:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 22:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 19:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 18:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 21:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 20:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 23:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 22:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 19:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Wed May 9 18:58:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 09:58:32 -0700 Subject: [Expat-bugs] [ expat-Bugs-1647805 ] Expat 2.0 does not build on Mac OS X 10.4 / intel Message-ID: Bugs item #1647805, was opened at 2007-01-30 06:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Wiesmann (wiesmann) Assigned to: Greg Stein (gstein) Summary: Expat 2.0 does not build on Mac OS X 10.4 / intel Initial Comment: Installing expat 2.0.0 on Mac OS X (i386-apple-darwin8.8.2) fails with the following error: /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c:77:2: error: #error memmove does not exist on this platform, nor is a substitute available make: *** [lib/xmlparse.lo] Error 1 Output of configure script: checking build system type... i686-apple-darwin8.8.2 checking host system type... i686-apple-darwin8.8.2 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.8.2 dyld checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... no checking for bcopy... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... no checking for working mmap... no checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 12:58 Message: Logged In: YES user_id=290026 Originator: NO Matthias, have you tried the latest configure.in from CVS? Just to make sure this didn't fix your problem. ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-09 12:23 Message: Logged In: YES user_id=117374 Originator: YES I dont' think the problem is related to the build environnement. I have basically the same environnement (MacPorts 1.440) on a PPC PowerBook and an Intel Macbook. Expat builds fine on the PPC and fails on the Intel. The fact that the same problem arises with both ICC and GCC would indicate to me that configure has trouble with Darwin/Intel. I have attached the config.log file to this report. File Added: config.log ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 09:28 Message: Logged In: YES user_id=290026 Originator: NO Thanks again for you exemplary feedback! > This code checks if GCC is present (using $GCC which is set by > macro AC_PROG_CC which tests for the presence of __GNUC__) and > adds some compilation options including -fexceptions > (BTW: it would be ideal to know why this option is given as\ > someone has already said that it is not such a good idea). I think the reason it to better interoperate with call-backs that throw exceptions, so that the exceptions can pass though to the original caller of XML_Parse(). Expat is called from other languages as well! > The latter brings up the question: Why is the CFLAGS variable > being modified in configure.in? Was whoever added it expecting > that the compilation options would be used to compile the sources > or did he/she know that these compilation options would affect > the compilation of the sources as well as programs to test for > C features (configure)? The CFLags can be modified as arguments to configure in order to build the UTF-16 version of Expat (libexpatw.so/dll). (see README). We are not using automake, because our main build expert (Greg Stein) has too many bad experiences with it, and for Expat he considers it overkill. I prefer your first fix option, and have applied it to configure.in rev. 1.45. Needs testing on other platforms. ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-09 09:00 Message: Logged In: YES user_id=1788089 Originator: NO Hi there I am not a UNIX build expert either but I think we can come up with some solutions. Let me explain: Firstly, I have already filed a report on the Intel Support Site and as of today they have updated the report with the following text: "Thank you for the detail report. I was able to reproduce the problem, and the issue have been escalated. I will update this issue after our investigation. Intel Customer Support" As you can see they have not given away so much information other that the report has been escalated (whatever that means in their system). Secondly, the main thing is that Intel wants its compiler to be 100% compatible with gcc so anyone can easily migrate from gcc to icc. For this particular option -fexceptions icc is failing to do so. The way icc interoperate with gcc is by sort of posing as a gcc compiler. icc predefined some macros that are predefined by gcc (__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__) so icc can be seen as gcc. After looking at expat's configure.in I found the following code: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi This code checks if GCC is present (using $GCC which is set by macro AC_PROG_CC which tests for the presence of __GNUC__) and adds some compilation options including -fexceptions (BTW: it would be ideal to know why this option is given as someone has already said that it is not such a good idea). The Intel Manual advices to set CC to icc and when autoconf is used to generate the configure script AC_PROG_CC will set GCC=yes (because icc predefines __GNUC__) and also set leaves CC untouched (CC=icc) (as indicated in the autoconf 2.61 manual). The code above will execute as GCC=yes is true and because icc does accept the option -fexceptions (although it does not handle it as expected) therefore the -fexceptions option is added to CFLAGS which, according with the autoconf manual, is used when compiling or linking programs to test for C features. The latter brings up the question: Why is the CFLAGS variable being modified in configure.in? Was whoever added it expecting that the compilation options would be used to compile the sources or did he/she know that these compilation options would affect the compilation of the sources as well as programs to test for C features (configure)? To the best of my understanding if one wants to compile the sources (e.g. lib/xmlparse.c) with some specific options then those options are given in the Makefile.am (if automake is being used) located in the directory where the sources are. The presence of CFLAGS in the configure.in may be because expat is not using automake (as far as I can see). However, I believe CFLAGS can still be given somewhere else. Then, our first problem is that the programs to test for C features are failing (memmove, bcopy, etc.) when compiling with icc because CFLAGS contains the -fexceptions option. There are different ways to solve this: a. Replace the following code at configure.in: if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether gcc accepts -fexceptions) AC_TRY_COMPILE(,(void)1, AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi >> WITH << if test "$GCC" = yes ; then dnl dnl Be careful about adding the -fexceptions option; some versions of dnl GCC don't support it and it causes extra warnings that are only dnl distracting; avoid. dnl OLDCFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" CFLAGS="$OLDCFLAGS -fexceptions" AC_MSG_CHECKING(whether $CC accepts -fexceptions) AC_TRY_LINK( , , AC_MSG_RESULT(yes), AC_MSG_RESULT(no); CFLAGS="$OLDCFLAGS") fi The only two lines that change are AC_MSG_CHECKING... and AC_TRY_COMPILE... which now is using the macro AC_TRY_LINK. The reason for this is that -fexceptions only makes the Intel compiler fails when linking and not when compiling. This is the reason why the -fexceptions options is added when icc is used. By changing AC_TRY_COMPILE to AC_TRY_LINK (which implies a AC_TRY_COMPILE) the test will fail when using -fexceptions and this will prevent the -fexceptions option to be added. Also this solution has backwards compatibility with other GCC versions and when Intel fixes icc the -fexceptions option will be added as it would be supported. b. This solution involves to make a proper distinction between icc and gcc regarding the effords of icc to be seen as gcc. The line: if test "$GCC" = yes ; then can be changed for something that makes sure that the compiler is truly the gcc and not something else. One way would be to check is the __INTEL_COMPILER__ macro is defined. Then if this macro is defined and GCC = yes then we know that it is not the gcc compiler but something that is compatible. You folks are the right people to decide which way to go as you know the reasons why expat does not use automake, why -fexceptions is needed, etc. I have tried solution (a) and it worked fine on my system (of course I had to run autoconf after changing configure.in so that configure was updated) without any further changes. The configure script detects icc as my default compiler, identifies the -fexceptions option as NOT supported by icc and, finally, finds memmove and bcopy. Regards ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 19:12 Message: Logged In: YES user_id=290026 Originator: NO Thanks for the nice analysis! Now, the question is (not being a Unix build expert), what can be done at the configuration level to deal with that in Expat? ---------------------------------------------------------------------- Comment By: Hazael (hmaldonado) Date: 2007-05-08 06:38 Message: Logged In: YES user_id=1788089 Originator: NO I have the same problem on a combination of Mac OS X 10.4.9 + expat (Macport version) + Intel C/C++ Compiler fo Mac. I really don't know who this error concerns to but it seems it is related with the Intecl C/C++ compilers more than anything else. The problem arises because the configure script can not find memmove and bcopy. I have extracted the code generated by autoconf to test for the presence of memmove and tried to compile it with gcc and icc. GCC has not problems compiling it which as expected means that expat can be compiled with gcc without any trouble. However, ICC (Intel compiler) can not compile the code which means that the configure test will fail and memmove is considered as not present in the system which in turn triggers compilation errors. autoconf uses the following compiler options to compile the test code: icc -o conftest -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions ac_check_memmove.c And according to my research -fexceptions is the option making icc to fail. According to gcc documentation the -fexceptions option can make gcc to link the code to libstdc++ even when it is not a C++ program. However, it seems that icc does not do the same and outputs the following messages: ac_check_memmove.c(49): warning #310: old-style parameter list (anachronism) char memmove (); ^ ac_check_memmove.c(49): warning #1419: external declaration in primary source file char memmove (); ^ ac_check_memmove.c(67): remark #111: statement is unreachable return 0; ^ ld: Undefined symbols: ___gxx_personality_v0 The undefined symbol ___gxx_personality_v0 is, not surprisely, found at the libstdc++ library which is automatically included by gcc (trigger by the -fexceptions option) but not included by icc. If the option -lstdc++ is given manually to icc then the compilation succeeds. I think this explains the error and a quick solution for compiling expat will be adding -lstdc++ to the LDFLAGS environment variable at configuration time. LDFLAGS="-lstdc++" ./configure --prefix=/path/to/ ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-05-02 14:55 Message: Logged In: YES user_id=1022691 Originator: NO wiesmann, please let us know if it was your build environment's fault so we know if we can close the bug. Thank you! Sebastian ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 09:20 Message: Logged In: YES user_id=1697847 Originator: NO > I am using Mac ports (MacPorts 1.320). I know that expat builds correctly > on PPC machines, as I use it on my G4 Powerbook. I'm on an intel mac, too (see above). ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 09:17 Message: Logged In: YES user_id=1697847 Originator: NO You might want to consider running a selfupdate via 'sudo port selfupdate' to get MacPorts 1.4.3. The portfile itself basically hasn't changed for nearly a year, but the base-code has (significantly). Also, make sure you have the latest version of the Developer Tools installed, (on an intel mac the output of 'gcc --version' should be: i686-apple-darwin8-gcc-4.0.1 ... build 5367) ---------------------------------------------------------------------- Comment By: Matthias Wiesmann (wiesmann) Date: 2007-05-02 09:08 Message: Logged In: YES user_id=117374 Originator: YES I am using Mac ports (MacPorts 1.320). I know that expat builds correctly on PPC machines, as I use it on my G4 Powerbook. ---------------------------------------------------------------------- Comment By: Elias Pipping (pipping) Date: 2007-05-02 08:55 Message: Logged In: YES user_id=1697847 Originator: NO works fine on my mac (Mac OS X 10.4.9, i386-apple-darwin8.9.1, latest version from cvs, developer tools 2.4.1) /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c ... ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2007-04-27 05:56 Message: Logged In: YES user_id=1022691 Originator: NO Have you tried the MacPorts port for Expat? http://trac.macports.org/projects/macports/browser/trunk/dports/textproc/expat/Portfile Sebastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1647805&group_id=10127 From noreply at sourceforge.net Wed May 9 19:10:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 10:10:06 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 13:10 Message: Logged In: YES user_id=290026 Originator: NO Before Enrico's change, we had exactly what Michael is suggesting, only that the roles of DESTDIR and INSTALL_ROOT were exchanged. Why does the newest proposal work, and not the the way it used to be before the we introduced the conditional? Does this have to do with how each of them is "usually" used? By changing to the new proposal, whose usage patterns would we break? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-09 12:50 Message: Logged In: YES user_id=839786 Originator: NO > Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) > many people use DESTDIR. To reduce confusions, I intendet to support both > variables. As you do not use DESTDIR as make-argument, but INSTALL_ROOT as environment variable, my proposed change should work, because INSTALL_ROOT itself is not defined in the Makefile, and thus the environment-value of INSTALL_ROOT is used for DESTDIR (see also '-e' below). In GNU world, DESTDIR normally is used as make-parameter, not from environment, so when DESTDIR is set as make-argument, INSTALL_ROOT environment variable becomes irrelevant. > But I really suggest evryone to use GNU make, even on nun-GNU platforms > (AFAIK it should run on most other unix'es too). This releaves us from the > ugly job of supporting each single esotic make. Agreed somewhat - but if it is that easy to avoid an additional specific dependency, why not do it (especially if you do not need to fix it yourself) ? > Ah, important to mention: env variables should *NOT* be overwritten by > defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" > or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's > life much, much easier. This only is true if you pass '-e' to make(1), as stated in the manpages, it is _not_ done by default: -e, --environment-overrides Give variables taken from the environment precedence over vari- ables from makefiles. According to their manpages, this is true for GNU-make as well as native make on hpux, aix, solaris, freebsd, interix (do not have access to others). With my proposed patch, both your methods should work. It will not work only if you: 1) have DESTDIR in the environment set to a value != INSTALL_ROOT 2) _and_ pass '-e' to make (commandline or in MAKEFLAGS/MFLAGS environment variable). ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 12:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 21:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 04:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 08:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-13 19:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 16:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 13:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 12:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 15:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 14:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Wed May 9 19:25:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 10:25:05 -0700 Subject: [Expat-bugs] [ expat-Bugs-1715957 ] pkg-config file please Message-ID: Bugs item #1715957, was opened at 2007-05-09 17:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715957&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aidan Delaney (aidandelaney) Assigned to: Greg Stein (gstein) Summary: pkg-config file please Initial Comment: Any chance of an expat.pc pkg-config file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715957&group_id=10127 From noreply at sourceforge.net Wed May 9 20:39:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 11:39:21 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 14:39 Message: Logged In: YES user_id=290026 Originator: NO Correction: I went back to CVS and realized, before Enrico's patch, neither INSTALL_ROOT and DESTDIR were handled in the makefile. So I went ahead and committed the latest proposal. Applied in Makefile.in rev. 1.58. Please check out and test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 13:10 Message: Logged In: YES user_id=290026 Originator: NO Before Enrico's change, we had exactly what Michael is suggesting, only that the roles of DESTDIR and INSTALL_ROOT were exchanged. Why does the newest proposal work, and not the the way it used to be before the we introduced the conditional? Does this have to do with how each of them is "usually" used? By changing to the new proposal, whose usage patterns would we break? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-09 12:50 Message: Logged In: YES user_id=839786 Originator: NO > Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) > many people use DESTDIR. To reduce confusions, I intendet to support both > variables. As you do not use DESTDIR as make-argument, but INSTALL_ROOT as environment variable, my proposed change should work, because INSTALL_ROOT itself is not defined in the Makefile, and thus the environment-value of INSTALL_ROOT is used for DESTDIR (see also '-e' below). In GNU world, DESTDIR normally is used as make-parameter, not from environment, so when DESTDIR is set as make-argument, INSTALL_ROOT environment variable becomes irrelevant. > But I really suggest evryone to use GNU make, even on nun-GNU platforms > (AFAIK it should run on most other unix'es too). This releaves us from the > ugly job of supporting each single esotic make. Agreed somewhat - but if it is that easy to avoid an additional specific dependency, why not do it (especially if you do not need to fix it yourself) ? > Ah, important to mention: env variables should *NOT* be overwritten by > defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" > or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's > life much, much easier. This only is true if you pass '-e' to make(1), as stated in the manpages, it is _not_ done by default: -e, --environment-overrides Give variables taken from the environment precedence over vari- ables from makefiles. According to their manpages, this is true for GNU-make as well as native make on hpux, aix, solaris, freebsd, interix (do not have access to others). With my proposed patch, both your methods should work. It will not work only if you: 1) have DESTDIR in the environment set to a value != INSTALL_ROOT 2) _and_ pass '-e' to make (commandline or in MAKEFLAGS/MFLAGS environment variable). ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 12:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 21:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 04:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 08:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-13 19:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 16:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 13:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 12:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 15:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 14:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Wed May 9 20:49:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 May 2007 11:49:45 -0700 Subject: [Expat-bugs] [ expat-Bugs-1715239 ] test suite fails on sparc-sun-solaris2.10 (expat 2.0.0) Message-ID: Bugs item #1715239, was opened at 2007-05-08 22:17 Message generated for change (Comment added) made by pipping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715239&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Elias Pipping (pipping) Assigned to: Nobody/Anonymous (nobody) Summary: test suite fails on sparc-sun-solaris2.10 (expat 2.0.0) Initial Comment: ---------------------------------------------------------------------- >Comment By: Elias Pipping (pipping) Date: 2007-05-09 20:49 Message: Logged In: YES user_id=1697847 Originator: YES i've tried it with the latest version from cvs and the error no longer occurs. kind regards, elias pipping ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 03:29 Message: Logged In: YES user_id=290026 Originator: NO Could this be related to issue # 1597115 - which is supposedly fixed ? Please check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715239&group_id=10127 From noreply at sourceforge.net Thu May 10 11:51:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 May 2007 02:51:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 18:36 Message generated for change (Comment added) made by mhaubi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-10 11:51 Message: Logged In: YES user_id=839786 Originator: NO Works as (I have) expected here on solaris9, solaris10, aix53, hpux11.11, hpux11.23 and interix now, thanks! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 20:39 Message: Logged In: YES user_id=290026 Originator: NO Correction: I went back to CVS and realized, before Enrico's patch, neither INSTALL_ROOT and DESTDIR were handled in the makefile. So I went ahead and committed the latest proposal. Applied in Makefile.in rev. 1.58. Please check out and test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 19:10 Message: Logged In: YES user_id=290026 Originator: NO Before Enrico's change, we had exactly what Michael is suggesting, only that the roles of DESTDIR and INSTALL_ROOT were exchanged. Why does the newest proposal work, and not the the way it used to be before the we introduced the conditional? Does this have to do with how each of them is "usually" used? By changing to the new proposal, whose usage patterns would we break? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-09 18:50 Message: Logged In: YES user_id=839786 Originator: NO > Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) > many people use DESTDIR. To reduce confusions, I intendet to support both > variables. As you do not use DESTDIR as make-argument, but INSTALL_ROOT as environment variable, my proposed change should work, because INSTALL_ROOT itself is not defined in the Makefile, and thus the environment-value of INSTALL_ROOT is used for DESTDIR (see also '-e' below). In GNU world, DESTDIR normally is used as make-parameter, not from environment, so when DESTDIR is set as make-argument, INSTALL_ROOT environment variable becomes irrelevant. > But I really suggest evryone to use GNU make, even on nun-GNU platforms > (AFAIK it should run on most other unix'es too). This releaves us from the > ugly job of supporting each single esotic make. Agreed somewhat - but if it is that easy to avoid an additional specific dependency, why not do it (especially if you do not need to fix it yourself) ? > Ah, important to mention: env variables should *NOT* be overwritten by > defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" > or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's > life much, much easier. This only is true if you pass '-e' to make(1), as stated in the manpages, it is _not_ done by default: -e, --environment-overrides Give variables taken from the environment precedence over vari- ables from makefiles. According to their manpages, this is true for GNU-make as well as native make on hpux, aix, solaris, freebsd, interix (do not have access to others). With my proposed patch, both your methods should work. It will not work only if you: 1) have DESTDIR in the environment set to a value != INSTALL_ROOT 2) _and_ pass '-e' to make (commandline or in MAKEFLAGS/MFLAGS environment variable). ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 18:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 03:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 10:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 19:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 14:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-14 01:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 18:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 22:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 19:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 18:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 21:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 20:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 23:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 22:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 19:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Thu May 10 15:00:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 May 2007 06:00:34 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-10 09:00 Message: Logged In: YES user_id=290026 Originator: NO Good! Now, if Enrico confirms that it still works for him, I'll close this issue as fixed. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-10 05:51 Message: Logged In: YES user_id=839786 Originator: NO Works as (I have) expected here on solaris9, solaris10, aix53, hpux11.11, hpux11.23 and interix now, thanks! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 14:39 Message: Logged In: YES user_id=290026 Originator: NO Correction: I went back to CVS and realized, before Enrico's patch, neither INSTALL_ROOT and DESTDIR were handled in the makefile. So I went ahead and committed the latest proposal. Applied in Makefile.in rev. 1.58. Please check out and test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 13:10 Message: Logged In: YES user_id=290026 Originator: NO Before Enrico's change, we had exactly what Michael is suggesting, only that the roles of DESTDIR and INSTALL_ROOT were exchanged. Why does the newest proposal work, and not the the way it used to be before the we introduced the conditional? Does this have to do with how each of them is "usually" used? By changing to the new proposal, whose usage patterns would we break? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-09 12:50 Message: Logged In: YES user_id=839786 Originator: NO > Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) > many people use DESTDIR. To reduce confusions, I intendet to support both > variables. As you do not use DESTDIR as make-argument, but INSTALL_ROOT as environment variable, my proposed change should work, because INSTALL_ROOT itself is not defined in the Makefile, and thus the environment-value of INSTALL_ROOT is used for DESTDIR (see also '-e' below). In GNU world, DESTDIR normally is used as make-parameter, not from environment, so when DESTDIR is set as make-argument, INSTALL_ROOT environment variable becomes irrelevant. > But I really suggest evryone to use GNU make, even on nun-GNU platforms > (AFAIK it should run on most other unix'es too). This releaves us from the > ugly job of supporting each single esotic make. Agreed somewhat - but if it is that easy to avoid an additional specific dependency, why not do it (especially if you do not need to fix it yourself) ? > Ah, important to mention: env variables should *NOT* be overwritten by > defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" > or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's > life much, much easier. This only is true if you pass '-e' to make(1), as stated in the manpages, it is _not_ done by default: -e, --environment-overrides Give variables taken from the environment precedence over vari- ables from makefiles. According to their manpages, this is true for GNU-make as well as native make on hpux, aix, solaris, freebsd, interix (do not have access to others). With my proposed patch, both your methods should work. It will not work only if you: 1) have DESTDIR in the environment set to a value != INSTALL_ROOT 2) _and_ pass '-e' to make (commandline or in MAKEFLAGS/MFLAGS environment variable). ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 12:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 21:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 04:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 08:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-13 19:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 16:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 13:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 12:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 15:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 14:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Fri May 11 18:34:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 09:34:38 -0700 Subject: [Expat-bugs] [ expat-Bugs-1717322 ] .def file directives throw link warnings Message-ID: Bugs item #1717322, was opened at 2007-05-11 09:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin J Bluck (kbluck) Assigned to: Greg Stein (gstein) Summary: .def file directives throw link warnings Initial Comment: CVS Tag: R_2_0_0 libexpat.def and libexpatw.def for Windows DLL builds both include two elements that cause link warnings and in some cases, make the DLL unuseable at runtime. The first line of each file, the LIBRARY directive, includes an explicit library name. This effectively prevents custom builds with a different DLL name. If you attempt to build a DLL with a different name, the linker will throw LNK4070 'filename directive differs from output filename' and the import lib will cause applications to link against the DEF LIBRARY DLL name instead of the actual DLL file name, which of course causes a "DLL not found" error at runtime. To prevent this, that line should read just 'LIBRARY' with no name specified. The next line is a DESCRIPTION directive. This line causes a LNK4017 warning 'statement not supported'. This directive has been deprecated for years in favor of version resources, and should be eliminated completely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 From noreply at sourceforge.net Fri May 11 18:40:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 09:40:55 -0700 Subject: [Expat-bugs] [ expat-Bugs-1717322 ] .def file directives throw link warnings Message-ID: Bugs item #1717322, was opened at 2007-05-11 09:34 Message generated for change (Comment added) made by kbluck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin J Bluck (kbluck) Assigned to: Greg Stein (gstein) Summary: .def file directives throw link warnings Initial Comment: CVS Tag: R_2_0_0 libexpat.def and libexpatw.def for Windows DLL builds both include two elements that cause link warnings and in some cases, make the DLL unuseable at runtime. The first line of each file, the LIBRARY directive, includes an explicit library name. This effectively prevents custom builds with a different DLL name. If you attempt to build a DLL with a different name, the linker will throw LNK4070 'filename directive differs from output filename' and the import lib will cause applications to link against the DEF LIBRARY DLL name instead of the actual DLL file name, which of course causes a "DLL not found" error at runtime. To prevent this, that line should read just 'LIBRARY' with no name specified. The next line is a DESCRIPTION directive. This line causes a LNK4017 warning 'statement not supported'. This directive has been deprecated for years in favor of version resources, and should be eliminated completely. ---------------------------------------------------------------------- >Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 09:40 Message: Logged In: YES user_id=11142 Originator: YES I would have generated a patch, but your CVS seems to be rejecting anonymous access at the moment. Strange, it wasn't doing that a couple days ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 From noreply at sourceforge.net Fri May 11 18:55:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 09:55:22 -0700 Subject: [Expat-bugs] [ expat-Bugs-1717322 ] .def file directives throw link warnings Message-ID: Bugs item #1717322, was opened at 2007-05-11 12:34 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control >Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Kevin J Bluck (kbluck) Assigned to: Greg Stein (gstein) Summary: .def file directives throw link warnings Initial Comment: CVS Tag: R_2_0_0 libexpat.def and libexpatw.def for Windows DLL builds both include two elements that cause link warnings and in some cases, make the DLL unuseable at runtime. The first line of each file, the LIBRARY directive, includes an explicit library name. This effectively prevents custom builds with a different DLL name. If you attempt to build a DLL with a different name, the linker will throw LNK4070 'filename directive differs from output filename' and the import lib will cause applications to link against the DEF LIBRARY DLL name instead of the actual DLL file name, which of course causes a "DLL not found" error at runtime. To prevent this, that line should read just 'LIBRARY' with no name specified. The next line is a DESCRIPTION directive. This line causes a LNK4017 warning 'statement not supported'. This directive has been deprecated for years in favor of version resources, and should be eliminated completely. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 12:55 Message: Logged In: YES user_id=290026 Originator: NO Fixed in libexpat(w).dev rev. 1.8. Please check out and test. Karl ---------------------------------------------------------------------- Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 12:40 Message: Logged In: YES user_id=11142 Originator: YES I would have generated a patch, but your CVS seems to be rejecting anonymous access at the moment. Strange, it wasn't doing that a couple days ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 From noreply at sourceforge.net Fri May 11 18:56:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 09:56:53 -0700 Subject: [Expat-bugs] [ expat-Bugs-1007100 ] Release and Debug DLLs should have different names Message-ID: Bugs item #1007100, was opened at 2004-08-11 01:26 Message generated for change (Comment added) made by kbluck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Release and Debug DLLs should have different names Initial Comment: On windows, (unlike on Unix) it is a wise idea to have output dlls and libs for release and debug with different names, possibly following the Python convention: python.exe python_d.exe python23.dll python23_d.dll etc... The ACE library is another one: ace.dll aced.dll And IBMs unicode libraries (ICU) follow a similar converntion. The reason for this is that applications may encounter runtime errors when linking to libraries that use a different heap, and release and debug versions generally do this. ---------------------------------------------------------------------- Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 09:56 Message: Logged In: YES user_id=11142 Originator: NO There are two main schools of thought on this issue. The first is that debug build targets should be named differently. The second is that debug builds should be made into a different target path than release builds. I personally prefer the second option, since it is completely within my own control and works regardless of whether any given library author has chosen to mangle target names. The only advantage to mangled names is that you can install and run both variants in the same folder. But then, you have to ask, what if I want to define a third build variant, such as optimized with symbols? Now I need yet another naming variant, which assuredly *no* library will support, so I'm forced into using a different path after all. I'd just start out building into different paths in the first place. Then you don't have to concern yourself about other people's naming conventions. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-09 08:13 Message: Logged In: YES user_id=290026 I am not convinced that this is a good idea for Expat. Everytime I would like to debug I need to link to a different library. This is inconvenient. I am not sure that Expat will have a problem with different heaps, as the API does not require cross-allocation or cross-deallocation of memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&group_id=10127 From noreply at sourceforge.net Fri May 11 19:01:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 10:01:02 -0700 Subject: [Expat-bugs] [ expat-Bugs-1007100 ] Release and Debug DLLs should have different names Message-ID: Bugs item #1007100, was opened at 2004-08-11 04:26 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Release and Debug DLLs should have different names Initial Comment: On windows, (unlike on Unix) it is a wise idea to have output dlls and libs for release and debug with different names, possibly following the Python convention: python.exe python_d.exe python23.dll python23_d.dll etc... The ACE library is another one: ace.dll aced.dll And IBMs unicode libraries (ICU) follow a similar converntion. The reason for this is that applications may encounter runtime errors when linking to libraries that use a different heap, and release and debug versions generally do this. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 13:01 Message: Logged In: YES user_id=290026 Originator: NO We are already following the different target path approach. ---------------------------------------------------------------------- Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 12:56 Message: Logged In: YES user_id=11142 Originator: NO There are two main schools of thought on this issue. The first is that debug build targets should be named differently. The second is that debug builds should be made into a different target path than release builds. I personally prefer the second option, since it is completely within my own control and works regardless of whether any given library author has chosen to mangle target names. The only advantage to mangled names is that you can install and run both variants in the same folder. But then, you have to ask, what if I want to define a third build variant, such as optimized with symbols? Now I need yet another naming variant, which assuredly *no* library will support, so I'm forced into using a different path after all. I'd just start out building into different paths in the first place. Then you don't have to concern yourself about other people's naming conventions. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-03-09 11:13 Message: Logged In: YES user_id=290026 I am not convinced that this is a good idea for Expat. Everytime I would like to debug I need to link to a different library. This is inconvenient. I am not sure that Expat will have a problem with different heaps, as the API does not require cross-allocation or cross-deallocation of memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1007100&group_id=10127 From noreply at sourceforge.net Fri May 11 19:12:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 10:12:34 -0700 Subject: [Expat-bugs] [ expat-Bugs-1717322 ] .def file directives throw link warnings Message-ID: Bugs item #1717322, was opened at 2007-05-11 09:34 Message generated for change (Comment added) made by kbluck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Kevin J Bluck (kbluck) Assigned to: Greg Stein (gstein) Summary: .def file directives throw link warnings Initial Comment: CVS Tag: R_2_0_0 libexpat.def and libexpatw.def for Windows DLL builds both include two elements that cause link warnings and in some cases, make the DLL unuseable at runtime. The first line of each file, the LIBRARY directive, includes an explicit library name. This effectively prevents custom builds with a different DLL name. If you attempt to build a DLL with a different name, the linker will throw LNK4070 'filename directive differs from output filename' and the import lib will cause applications to link against the DEF LIBRARY DLL name instead of the actual DLL file name, which of course causes a "DLL not found" error at runtime. To prevent this, that line should read just 'LIBRARY' with no name specified. The next line is a DESCRIPTION directive. This line causes a LNK4017 warning 'statement not supported'. This directive has been deprecated for years in favor of version resources, and should be eliminated completely. ---------------------------------------------------------------------- >Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 10:12 Message: Logged In: YES user_id=11142 Originator: YES Yes, your removal of the explicit name from the LIBRARY directive works as expected. As I was working with tag R_2_0_0, I didn't notice previously that you already removed the DESCRIPTION directive in rev. 1.7, which was not part of that tag. There was no problem with the comment; you didn't have to remove that. It doesn't hurt anything either way. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 09:55 Message: Logged In: YES user_id=290026 Originator: NO Fixed in libexpat(w).dev rev. 1.8. Please check out and test. Karl ---------------------------------------------------------------------- Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 09:40 Message: Logged In: YES user_id=11142 Originator: YES I would have generated a patch, but your CVS seems to be rejecting anonymous access at the moment. Strange, it wasn't doing that a couple days ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 From noreply at sourceforge.net Fri May 11 19:24:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 10:24:15 -0700 Subject: [Expat-bugs] [ expat-Bugs-1717322 ] .def file directives throw link warnings Message-ID: Bugs item #1717322, was opened at 2007-05-11 12:34 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Kevin J Bluck (kbluck) Assigned to: Greg Stein (gstein) Summary: .def file directives throw link warnings Initial Comment: CVS Tag: R_2_0_0 libexpat.def and libexpatw.def for Windows DLL builds both include two elements that cause link warnings and in some cases, make the DLL unuseable at runtime. The first line of each file, the LIBRARY directive, includes an explicit library name. This effectively prevents custom builds with a different DLL name. If you attempt to build a DLL with a different name, the linker will throw LNK4070 'filename directive differs from output filename' and the import lib will cause applications to link against the DEF LIBRARY DLL name instead of the actual DLL file name, which of course causes a "DLL not found" error at runtime. To prevent this, that line should read just 'LIBRARY' with no name specified. The next line is a DESCRIPTION directive. This line causes a LNK4017 warning 'statement not supported'. This directive has been deprecated for years in favor of version resources, and should be eliminated completely. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 13:24 Message: Logged In: YES user_id=290026 Originator: NO OK, the comment is put back in. I guess I can close this as fixed. ---------------------------------------------------------------------- Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 13:12 Message: Logged In: YES user_id=11142 Originator: YES Yes, your removal of the explicit name from the LIBRARY directive works as expected. As I was working with tag R_2_0_0, I didn't notice previously that you already removed the DESCRIPTION directive in rev. 1.7, which was not part of that tag. There was no problem with the comment; you didn't have to remove that. It doesn't hurt anything either way. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 12:55 Message: Logged In: YES user_id=290026 Originator: NO Fixed in libexpat(w).dev rev. 1.8. Please check out and test. Karl ---------------------------------------------------------------------- Comment By: Kevin J Bluck (kbluck) Date: 2007-05-11 12:40 Message: Logged In: YES user_id=11142 Originator: YES I would have generated a patch, but your CVS seems to be rejecting anonymous access at the moment. Strange, it wasn't doing that a couple days ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1717322&group_id=10127 From noreply at sourceforge.net Fri May 11 19:28:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 10:28:13 -0700 Subject: [Expat-bugs] [ expat-Bugs-1613457 ] Makefile.in problem on NETBSD 3.1 Message-ID: Bugs item #1613457, was opened at 2006-12-11 14:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1613457&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Makefile.in problem on NETBSD 3.1 Initial Comment: After running the configure script, then trying to run make, it errors out: squallbsr at karasu2 [~/source/expat-2.0.0]$ make make: "/Users/squallbsr/source/expat-2.0.0/Makefile" line 47: Need an operator make: "/Users/squallbsr/source/expat-2.0.0/Makefile" line 49: Need an operator make: Fatal errors encountered -- cannot continue This can be fixed by adjusting the ifndef INSTALL_ROOT section around lines 47-49 in Makefile.in I changed it to: INSTALL_ROOT ?= $(DESTDIR) which worked on NetBSD and for my application, this of course would need more testing as all I wanted was for expat to complile, not install. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 13:28 Message: Logged In: YES user_id=290026 Originator: NO The latest patch (see the related issue #1490371) removes the conditional directive altogether, but reverses the roles of INSTALL_ROOT and DESDIR. This should hopefully work for most use cases while still being more cross-platform compatible. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:28 Message: Logged In: YES user_id=290026 Originator: NO In an attempt to make Makefile.in more compatible across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: davidharpe (davidharpe) Date: 2007-01-02 14:23 Message: Logged In: YES user_id=1681745 Originator: NO I had the same problem on FreeBSD. Change lines 47-49 to: .ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) .endif (note the leading period) Seems to work fine. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:27 Message: Logged In: YES user_id=290026 Originator: NO Well, I thought about it, and "?=" seems acceptable. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. I'll change that accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-12 14:32 Message: Logged In: YES user_id=290026 Originator: NO Apparently - after doing a Goole search - Solaris as well as BSD Make have issues with the "ifndef" syntax. Is there a way to keep the logic with another syntax? It looks as if "?=" does not have exactly the same logic. ---------------------------------------------------------------------- Comment By: Bryan Rehbein (squallbsr) Date: 2006-12-11 14:54 Message: Logged In: YES user_id=950269 Originator: NO Bug reported by: br39290 at squall.us ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1613457&group_id=10127 From noreply at sourceforge.net Fri May 11 19:32:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 May 2007 10:32:22 -0700 Subject: [Expat-bugs] [ expat-Bugs-1618673 ] expat 2.0.0 compile problem on SCO-Unix 5.0.5 Message-ID: Bugs item #1618673, was opened at 2006-12-19 05:02 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1618673&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Third-party Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat 2.0.0 compile problem on SCO-Unix 5.0.5 Initial Comment: Message from mstabile at metsogeda.it ---------------------------------- Hi, I'm trying to compile your expat 2.0.0 on a sco5.0.5 server but i'm facing with some problems. first: in Makefile.in INSTALL_ROOT ?= $(DESTDIR) or previous ifndef ... sentence don't work . It work (It doesn't give "Must be a separator on rules line 47 (bu39)." message) only with INSTALL_ROOT = $(DESTDIR) Second and hardest problem is: executing make I get an error. with debug mode the message is: ..... + eval cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/ xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.s o -Wl,-R,/usr/local/lib + cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/xmlwf .o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.so -Wl, -R,/usr/local/lib command line: fatal error: illegal value for -R: /usr/local/lib + exit 1 *** Error code 1 (bu21) > -------------- executing cc in debug mode i get cc: 'ld' '-Ra,XPG4PLUS,elf' '-Y' 'P,/usr/ccs/lib:/lib:/usr/lib' '/usr/ccs/lib/c rt1.o' '/usr/ccs/lib/values-Xa.o' '-o' 'xmlwf/.libs/xmlwf' 'xmlwf/xmlwf.o' 'xmlw f/xmlfile.o' 'xmlwf/codepage.o' 'xmlwf/readfilemap.o' './.libs/libexpat.so' '-R' '/usr/local/lib' '-Qy' '-lcrypt' '-lgen' '-lc' '/usr/ccs/lib/crtn.o' cc: process: /usr/ccs/bin/elf/ld command line: fatal error: illegal value for -R: /usr/local/lib So the problem is the -R parameter passed to ld command that does not allow /usr/local/lib as argument as you can see from these part of ld man --------- ....... -Rarg[,arg,...] Set runtime-behavior characteristics. The option accepts a comma-separated list of arguments. Note that there is no space between -R and its arguments. Each argument is one of the accepted values for the -a, -b, or -X flags of cc(CP), and should match the flags used when the objects were compiled. The default is -Rxpg4plus,elf,a for the ELF ld, and -Rxpg4plus,coff,a for the COFF ld. The ELF ld ignores -Rcoff and -Ribcs2; the COFF ld ignores -Relf. Multiple -R arguments may be given; the last argument of each type ( -a, -b, or -X) is the one used. For example, -Ransi,a -Rxpg4,coff is equivalent to -Rxpg4,coff,a. ........ So, I belive some ld parameter must be changed but what? TIA , I hope you can send me the solution ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 13:32 Message: Logged In: YES user_id=290026 Originator: NO The latest Makefile.in patch should make this issue go away (see bug #1490371), as it removes the GNU specific conditional directive. With the other error (ld parameter) I am afraid that as a Windows guy I really cannot help you. Hopefully others will jump in. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:29 Message: Logged In: YES user_id=290026 Originator: NO For part of this issue: In an attempt to make Makefile.in more compatible across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-19 13:48 Message: Logged In: YES user_id=290026 Originator: NO When I made the Expat 2.0 tarball I used libtool 1.5.22. Is that new enough? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-19 10:43 Message: Logged In: YES user_id=3066 Originator: NO > All our Unix build experts have been unresponsive for a while. Sadly, that's me. I've never used SCO Unix myself. Whether a new libtool fixes this problem, I don't know. If anyone can verify that, we can see about using an updated libtool. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-19 10:30 Message: Logged In: YES user_id=290026 Originator: NO All our Unix build experts have been unresponsive for a while. I am not sure I can really help you there. I can only recommend to search Google for problems with ld on SCO. And, in the spirit of support for OpenSource projects, why don't you ditch SCO in favour of Linux? :-) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-12-19 05:26 Message: Logged In: NO Message from mstabile at metsogeda.it ----------------------------------- Command cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.so -Wl,-L,/usr/local/lib seems to work and create xmlwf/.libs/xmlwf How libtool should be changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1618673&group_id=10127 From noreply at sourceforge.net Mon May 28 13:06:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 May 2007 04:06:34 -0700 Subject: [Expat-bugs] [ expat-Bugs-1498374 ] runtests.cpp does not compile Message-ID: Bugs item #1498374, was opened at 2006-05-31 10:51 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1498374&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: runtests.cpp does not compile Initial Comment: The Makefile of the test directory includes -I./lib and not -I../lib for expat.h and expat_external.h If there is no installed copy of the .h filesn compile of runtests.c doesn't work. Looks like the Makefile.in is not correct. peter.sylvester at edelweb.fr ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-05-28 04:06 Message: Logged In: NO The following change (as pointed by http://sourceforge.net/tracker/index.php?func=detail&aid=1597115&group_id=10127&atid=110127) works for me: --- expat-2.0.0/Makefile.in.old 2007-05-28 10:58:17.000000000 +0000 +++ expat-2.0.0/Makefile.in 2007-05-28 10:48:18.000000000 +0000 @@ -107,7 +107,7 @@ INCLUDES = -I$(srcdir)/lib -I. LDFLAGS = @LDFLAGS@ -CPPFLAGS = @CPPFLAGS@ +CPPFLAGS = @CPPFLAGS@ $(INCLUDES) $(DEFS) CFLAGS = @CFLAGS@ -DHAVE_EXPAT_CONFIG_H VSNFLAG = -version-info @LIBCURRENT@:@LIBREVISION@:@LIBAGE@ ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-01 08:59 Message: Logged In: YES user_id=3066 There is no Makefile in the tests/ directory; the top-level Makefile is responsible for building the tests. When that runs, the top-level directory should be the current directory, so ./lib is the right path for the includes. Unfortunately, I don't have access to a machine that doesn't have at least some version of Expat installed by the base system, so I'll leave this open until I have a chance to run that test to confirm. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-31 10:56 Message: Logged In: YES user_id=290026 I think Fred needs something to do. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1498374&group_id=10127