From noreply@sourceforge.net Wed Aug 1 03:19:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 19:19:25 -0700 Subject: [ expat-Bugs-214050 ] Segmentation fault in libxmltok Message-ID: Bugs item #214050, was opened at 2000-09-11 07:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=214050&group_id=10127 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: christian liesch (ia97lies) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault in libxmltok Initial Comment: If I parse the following file (with an error near !DOCTYPE): !DOCTYPE OReilly:Books SYSTEM "dummy.dtd" [ ]> XML Pocket Ref 8.95 I got the following with my gdb: !DOCTYPE OReilly:Books SYSTEM "dummy.dtd" [ error:no element found Program received signal SIGSEGV, Segmentation fault. 0x400269c5 in normal_updatePosition () from /usr/lib/libxmltok.so.1 (gdb) where #0 0x400269c5 in normal_updatePosition () from /usr/lib/libxmltok.so.1 #1 0x4001b0d9 in XML_GetCurrentColumnNumber () from /usr/lib/libxmlparse.so.1 #2 0x8049154 in test_parse () #3 0x80491f5 in main () #4 0x4004da5e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 (gdb) ---------------------------------------------------------------------- Comment By: David Costanzo (david_costanzo) Date: 2001-07-31 19:19 Message: Logged In: YES user_id=109252 I have version 1.95.2 and am crashing on this. The problem is that parser->m_Position has been set to NULL before calling updatePosition. I have whittled down the repro to passing in "<\x04" as my data (that's a '<' followed by the binary byte 0x04). I call XML_Parse twice, once on the data, and once when setting the "finished" flag. The crash happens when I call XML_GetCurrentLineNumber afterward. I'm having a little casting my parser to a Parser* in my dev enviorment, but I think parser->m_bufferPtr is set to NULL somewhere (maybe on the first error). Then, when I call XML_Parse with the "finished" flag, parser- >m_positionPtr is set to parser->m_bufferPtr (NULL). Then I call XML_GetCurrentLineNumber to report the error, which passes NULL in as the position to updatePosition. Then it crashes. I do not think the patch listed will work for my bug, since my problem is that ptr is NULL. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-18 13:35 Message: Logged In: YES user_id=3066 Closing this as it hasn't been reproduced with a recent version of Expat. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-07 01:55 Message: Logged In: NO I could reproduce this on the a May 29 1999 version of expat. The problem seems to be that *ptr in PREFIX(updatePosition)() is a null byte, which chokes somewhere inside the BYTE_TYPE macro. I fixed this (I think), by testing for *ptr in the while loop. Here's the patch: *** xmltok_impl.c 1999/09/03 14:54:37 1.1.1.1 --- xmltok_impl.c 2001/03/07 09:49:46 *************** *** 1709,1715 **** const char *end, POSITION *pos) { ! while (ptr != end) { switch (BYTE_TYPE(enc, ptr)) { #define LEAD_CASE(n) \ case BT_LEAD ## n: \ --- 1709,1715 ---- const char *end, POSITION *pos) { ! while (*ptr && ptr != end) { switch (BYTE_TYPE(enc, ptr)) { #define LEAD_CASE(n) \ case BT_LEAD ## n: \ ---------------------------------------------------------------------- Comment By: Sam TH (samth) Date: 2001-02-02 06:47 Message: Could not reproduce this with CVS expat. ---------------------------------------------------------------------- Comment By: Sam TH (samth) Date: 2001-02-02 06:38 Message: Could not reproduce this with CVS expat. ---------------------------------------------------------------------- Comment By: Jacob Refstrup (jacob_refstrup) Date: 2000-11-28 14:11 Message: This appear to be fixed in 1.95.1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=214050&group_id=10127 From noreply@sourceforge.net Wed Aug 1 22:29:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Aug 2001 14:29:34 -0700 Subject: [ expat-Bugs-446957 ] Make exist silently Message-ID: Bugs item #446957, was opened at 2001-08-01 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=446957&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make exist silently Initial Comment: Platform: Solaris 8 gcc 2.95.3 gnu make (or Sol8 make - same effect with both) "./configure" succeeds. running "make" produces nothing. Reverted to 1.95.1, works fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=446957&group_id=10127 From noreply@sourceforge.net Thu Aug 2 15:54:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Aug 2001 07:54:12 -0700 Subject: [ expat-Bugs-447197 ] NULLs as whitespace or character data Message-ID: Bugs item #447197, was opened at 2001-08-02 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=447197&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keith Tingle (ktingle) Assigned to: Nobody/Anonymous (nobody) Summary: NULLs as whitespace or character data Initial Comment: We had a nasty bug in a Perl script that embedded NULL values into our Xml documents. msxml treated the NULL values as whitespace and ignored them, Expat will not handle NULL values in the stream. Neither seems correct to me as the spec says nothing about NULLs being treated as whitespace and character data is anything that is not markup data; http://www.w3.org/TR/REC-xml#dt-chardata I know this is esoteric but shouldn't Expat treat NULLs as character data? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=447197&group_id=10127 From noreply@sourceforge.net Sun Aug 5 21:31:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 Aug 2001 13:31:00 -0700 Subject: [ expat-Bugs-448234 ] Features Added Since 1.2 ? Message-ID: Bugs item #448234, was opened at 2001-08-05 13:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=448234&group_id=10127 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Features Added Since 1.2 ? Initial Comment: From noreply@sourceforge.net Mon Aug 6 22:19:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 Aug 2001 14:19:52 -0700 Subject: [ expat-Bugs-448560 ] xmlwf/Makefile uses unchecked SHELL var Message-ID: Bugs item #448560, was opened at 2001-08-06 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=448560&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Sean Kelly (seankelly) Assigned to: Greg Stein (gstein) Summary: xmlwf/Makefile uses unchecked SHELL var Initial Comment: On FreeBSD 4.2 using standard BSD make (/usr/bin/make), "make install" fails in the xmlwf directory: saffron% pwd /u/kelly/src/expat-1.95.2/xmlwf saffron% make install /usr/local/bin/tcsh ../conftools/mkinstalldirs /usr/loc al/bin errstatus=0: Command not found. If I do "env SHELL=/bin/sh make install", then it's happy. Apparently, the SHELL setting doesn't get passed from the parent directory's Makefile, as it's just invoking "make" itself, so the child directory grabs it from the environment. GNU make works around the problem, too, as it explicitly sets SHELL to /bin/sh, ignoring the environment setting. I'd add another SHELL=/bin/sh like there is in the parent Makefile, or make it a configurable setting in the xmlwf Makefile. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=448560&group_id=10127 From noreply@sourceforge.net Wed Aug 8 10:10:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 Aug 2001 02:10:19 -0700 Subject: [ expat-Bugs-445893 ] Make fails Message-ID: Bugs item #445893, was opened at 2001-07-30 02:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445893&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Make fails Initial Comment: Im tryin to compile expat-1.95.2 under redhat 5.2. But im getting this error: cc1: Invalid option `-fexceptions' xmlparse.c: In function `XML_GetBuffer': xmlparse.c:1178: `punting' undeclared (first use this function) xmlparse.c:1178: (Each undeclared identifier is reported only once xmlparse.c:1178: for each function it appears in.) xmlparse.c:1178: parse error before `on' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/root/tmp/expat-1.95.2/lib' make: *** [lib] Error 2 ---------------------------------------------------------------------- Comment By: Gudleik Rasch (rastamatra) Date: 2001-08-08 02:10 Message: Logged In: YES user_id=273240 I get the same error when trying to compile on FreeBSD 3.4-RELEASE. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445893&group_id=10127 From papadopo@shfj.cea.fr Thu Aug 9 11:30:25 2001 From: papadopo@shfj.cea.fr (Dimitri PAPADOPOULOS-ORFANOS) Date: Thu, 9 Aug 2001 12:30:25 +0200 (MEST) Subject: expat-1.95.2 on Solaris Message-ID: <200108091030.MAA11403@nestor.shfj.cea.fr> Hi, I'm trying to build expat-1.95.2 on Solaris using Sun WorkShop 5.0. 1) I had to use GNU make. Sun make doesn't work. There's not even an error message. 2) I get an error while building xmlwf: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. gmake[1]: *** [xmlwf] Error 1 The reason is that cc does not know -static. I changed LDFLAGS= @LDFLAGS@ -static to LDFLAGS= @LDFLAGS@ -static in xmlwf/Makefile.in and xmlwf now builds correctly although dynamically linked instead of statically. I tried with -Bstatic but then all libraries are ncluding the C library are linked statically which is not what you want. The correct command line would be: cc -o xmlwf xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -Bstatic -lexpat -Bdynamic But libtool should probably take care of this. From noreply@sourceforge.net Thu Aug 9 16:35:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 08:35:53 -0700 Subject: [ expat-Bugs-449518 ] ]]> in non-CDATA content causes error Message-ID: Bugs item #449518, was opened at 2001-08-09 08:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ]]> in non-CDATA content causes error Initial Comment: The three characters ]]> in the body of an XML document, but outside of a CDATA section, cause a parser error, as can be seen by parsing: foo]]> Which is valid XML. The XML REC has the following to say: [In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".] QED, expat has this wrong. Matt Sergeant. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 From noreply@sourceforge.net Thu Aug 9 17:35:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 09:35:23 -0700 Subject: [ expat-Bugs-449518 ] ]]> in non-CDATA content causes error Message-ID: Bugs item #449518, was opened at 2001-08-09 08:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ]]> in non-CDATA content causes error Initial Comment: The three characters ]]> in the body of an XML document, but outside of a CDATA section, cause a parser error, as can be seen by parsing: foo]]> Which is valid XML. The XML REC has the following to say: [In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".] QED, expat has this wrong. Matt Sergeant. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-09 09:35 Message: Logged In: NO But consider this production: CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) And: right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 From noreply@sourceforge.net Thu Aug 9 18:06:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:06:22 -0700 Subject: [ expat-Bugs-449518 ] ]]> in non-CDATA content causes error Message-ID: Bugs item #449518, was opened at 2001-08-09 08:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ]]> in non-CDATA content causes error Initial Comment: The three characters ]]> in the body of an XML document, but outside of a CDATA section, cause a parser error, as can be seen by parsing: foo]]> Which is valid XML. The XML REC has the following to say: [In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".] QED, expat has this wrong. Matt Sergeant. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-09 10:06 Message: Logged In: NO Agreed. Please close this bug. Now I have to go log it as a bug against libxml2 :-) Matt. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-09 09:35 Message: Logged In: NO But consider this production: CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) And: right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 From noreply@sourceforge.net Thu Aug 9 18:10:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:10:05 -0700 Subject: [ expat-Bugs-449518 ] ]]> in non-CDATA content causes error Message-ID: Bugs item #449518, was opened at 2001-08-09 08:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 Category: None >Group: Not a Bug >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ]]> in non-CDATA content causes error Initial Comment: The three characters ]]> in the body of an XML document, but outside of a CDATA section, cause a parser error, as can be seen by parsing: foo]]> Which is valid XML. The XML REC has the following to say: [In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup. In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".] QED, expat has this wrong. Matt Sergeant. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-09 10:06 Message: Logged In: NO Agreed. Please close this bug. Now I have to go log it as a bug against libxml2 :-) Matt. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-09 09:35 Message: Logged In: NO But consider this production: CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) And: right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=449518&group_id=10127 From noreply@sourceforge.net Thu Aug 9 18:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:39:58 -0700 Subject: [ expat-Bugs-445893 ] Make fails Message-ID: Bugs item #445893, was opened at 2001-07-30 02:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445893&group_id=10127 >Category: Build control Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make fails Initial Comment: Im tryin to compile expat-1.95.2 under redhat 5.2. But im getting this error: cc1: Invalid option `-fexceptions' xmlparse.c: In function `XML_GetBuffer': xmlparse.c:1178: `punting' undeclared (first use this function) xmlparse.c:1178: (Each undeclared identifier is reported only once xmlparse.c:1178: for each function it appears in.) xmlparse.c:1178: parse error before `on' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/root/tmp/expat-1.95.2/lib' make: *** [lib] Error 2 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 10:39 Message: Logged In: YES user_id=3066 Are you using a compiler other than GCC? The configure script seems to think you're using GCC or the -fexceptions would not be on the command line. If you are using GCC, what version? ---------------------------------------------------------------------- Comment By: Gudleik Rasch (rastamatra) Date: 2001-08-08 02:10 Message: Logged In: YES user_id=273240 I get the same error when trying to compile on FreeBSD 3.4-RELEASE. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445893&group_id=10127 From noreply@sourceforge.net Thu Aug 9 18:40:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:40:58 -0700 Subject: [ expat-Bugs-438393 ] expat compile fails in ld on HPUX 11.0 Message-ID: Bugs item #438393, was opened at 2001-07-03 16:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438393&group_id=10127 >Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: SANJAY WAZA (sanjay_waza) >Assigned to: Greg Stein (gstein) Summary: expat compile fails in ld on HPUX 11.0 Initial Comment: I failed to install the expat . I am not able to understand why The configure with though fine , It failed in make The results of configure are ./configure -- prefix=/users/summit/implementation/admin/expat ./configure -- prefix=/users/summit/implementation/admin/expat loading cache ./config.cache checking host system type... hppa2.0w-hp-hpux11.00 checking build system type... hppa2.0w-hp-hpux11.00 checking for ranlib... (cached) ranlib checking for gcc... (cached) cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for non-GNU ld... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /usr/bin/nm -p checking whether ln -s works... (cached) yes loading cache ./config.cache within ltconfig checking whether we are using GNU C... no checking for object suffix... o checking for executable suffix... (cached) no checking for cc option to produce PIC... +Z checking if cc PIC flag +Z works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc static flag -Wl,-a -Wl,archive works... -Wl,-a -Wl,archive checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -p output... failed checking how to hardcode library paths into programs... relink checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... hpux11.00 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g ) works... yes checking whether the C compiler (cc -g ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /opt/imake/bin/install -c checking how to run the C preprocessor... (cached) cc - E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) yes checking for working const... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) no checking for memmove... (cached) yes checking for bcopy... (cached) yes creating ./config.status creating Makefile creating lib/Makefile creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged In Make it gives the following error autoconf Make: Cannot load autoconf. Stop. *** Error exit code 1 Stop. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 20:51 Message: Logged In: YES user_id=3066 Can you test this with the current CVS version of Expat? The build process has changed a fair bit, and suspect this may have changed. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438393&group_id=10127 From noreply@sourceforge.net Thu Aug 9 18:52:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 10:52:08 -0700 Subject: [ expat-Bugs-446957 ] Make exits silently Message-ID: Bugs item #446957, was opened at 2001-08-01 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=446957&group_id=10127 Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) >Summary: Make exits silently Initial Comment: Platform: Solaris 8 gcc 2.95.3 gnu make (or Sol8 make - same effect with both) "./configure" succeeds. running "make" produces nothing. Reverted to 1.95.1, works fine. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 10:52 Message: Logged In: YES user_id=3066 I'm very surprised that you're having difficulties even with GNU make; can you please double-check that? I observed the same problem with Sun make (Solaris 8, but I think any version will do); it doesn't seem to understand the .PHONY directives in the makefile. GNU make worked fine for me, though. Greg, any wisdom here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=446957&group_id=10127 From noreply@sourceforge.net Thu Aug 9 19:11:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:11:17 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 Category: XML::Parser (Perl module) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Thu Aug 9 19:12:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:12:51 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 >Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:12 Message: Logged In: YES user_id=3066 This should not have been categorized as an XML::Parser issue. I did that, but I'm not at all sure why... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Thu Aug 9 19:17:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:17:02 -0700 Subject: [ expat-Bugs-232649 ] EXPATLIBPATH = ? Message-ID: Bugs item #232649, was opened at 2001-02-15 17:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=232649&group_id=10127 Category: XML::Parser (Perl module) >Group: Third-party Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: EXPATLIBPATH = ? Initial Comment: Sires: Trying to install Expat: CPAN returns... ... EXPATLIBPATH = to set directory in which to find libexpat <============= Where? Does it mean LIBs for Expat? or a file name libexpat? ... EXPATINCPATH =... expat.h <==== I see this one but not the other... Regards, Dope on the ropes. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:17 Message: Logged In: YES user_id=3066 Clark's disappeared, and this is definately an XML::Parser issue, not a bug in Expat itself. Closing this as a third-party documentation bug. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-04 18:26 Message: Logged In: YES user_id=3066 Assigned to Clark since this relates to the Perl bindings. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-27 10:45 Message: Logged In: NO Ferget it, I beat my head against the keyboard until it worked... I was trying to install XML::Parser but getting the Expat stop sign... For those who care... (linux-mandrake kernel 2.2.14) Gzip and Untar Expat package (gzip -dv expa....gz, tar -ivh expat....tar) Then, in newly created subdirectory, ./configure followed by make install (of course you need a complete version of make, gcc and gcc- c++ rpm-ed into the machine for all of this to work properly, probably my original problem... doh) Next return to CPAN (perl -MCPAN -e shell) then installed XML::Parser seems to have taken it... WHEEEeeee LINUX! Sorry for you pro's reading this... maybe it will help a newbie in some convoluted way. Tom 8^} ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-27 09:34 Message: Logged In: NO HELLLLEEEOOOO CLARK ARE YOU THERE ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-16 09:54 Message: This appears to relate to the Perl bindings, so I've assigned this to Clark Cooper. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=232649&group_id=10127 From noreply@sourceforge.net Thu Aug 9 19:20:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 11:20:47 -0700 Subject: [ expat-Bugs-434664 ] utf8_toutf16 infinite loop Message-ID: Bugs item #434664, was opened at 2001-06-19 19:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434664&group_id=10127 >Category: None Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: utf8_toutf16 infinite loop Initial Comment: I believe this is a low priority bug since I can't see how it could ever get tickled calling only the interface in expat.h, but I came across it while calling into xmltok directly. If the input buffer contains a BT_LEAD4 character with only space left for one output character, the routine goes into an infinite loop. I fixed it with the following goto --- your tolerance of goto may vary. Michael Isard. [ I am waiting for sourceforge to fix their new account procedure which seems to have been broken for some days --- in the meantime you can mail me directly at michael.isard@compaq.com ] -------- from expat/xmltok/xmltok.c static void utf8_toUtf16(const ENCODING *enc, const char **fromP, const char *fromLim, unsigned short **toP, const unsigned short *toLim) { unsigned short *to = *toP; const char *from = *fromP; while (from != fromLim && to != toLim) { switch (((struct normal_encoding *)enc)->type [(unsigned char)*from]) { case BT_LEAD2: *to++ = ((from[0] & 0x1f) << 6) | (from[1] & 0x3f); from += 2; break; case BT_LEAD3: *to++ = ((from[0] & 0xf) << 12) | ((from[1] & 0x3f) << 6) | (from[2] & 0x3f); from += 3; break; case BT_LEAD4: { unsigned long n; if (to + 1 == toLim) goto after; /* BUGBUG this used to say break; which keeps looping */ n = ((from[0] & 0x7) << 18) | ((from[1] & 0x3f) << 12) | ((from[2] & 0x3f) << 6) | (from[3] & 0x3f); n -= 0x10000; to[0] = (unsigned short)((n >> 10) | 0xD800); to[1] = (unsigned short)((n & 0x3FF) | 0xDC00); to += 2; from += 4; } break; default: *to++ = *from++; break; } } after: /* BUGBUG new jump target added to escape from loop */ *fromP = from; *toP = to; } ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:20 Message: Logged In: YES user_id=3066 This is not XML::Parser specific, so I'm changing the categorization. Forcing SF to send me a copy of the properly-indented code is a nice side-effect. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434664&group_id=10127 From noreply@sourceforge.net Thu Aug 9 21:46:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 13:46:19 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- Comment By: Michael Isard (mmisard) Date: 2001-08-09 13:46 Message: Logged In: YES user_id=252517 I just noticed this reading the code, so I have no test code which triggers it. Thanks, Michael. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:12 Message: Logged In: YES user_id=3066 This should not have been categorized as an XML::Parser issue. I did that, but I'm not at all sure why... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Thu Aug 9 21:52:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 Aug 2001 13:52:22 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 13:52 Message: Logged In: YES user_id=3066 Ok, thanks! ---------------------------------------------------------------------- Comment By: Michael Isard (mmisard) Date: 2001-08-09 13:46 Message: Logged In: YES user_id=252517 I just noticed this reading the code, so I have no test code which triggers it. Thanks, Michael. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:12 Message: Logged In: YES user_id=3066 This should not have been categorized as an XML::Parser issue. I did that, but I'm not at all sure why... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Fri Aug 10 10:20:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 02:20:20 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- Comment By: Andy Southgate (southa) Date: 2001-08-10 02:20 Message: Logged In: YES user_id=29974 Hi, I hit this bug for real running expat on an embedded platform (128K RAM) and can test, if that's any help. Thanks for the fix. Andy Southgate ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 13:52 Message: Logged In: YES user_id=3066 Ok, thanks! ---------------------------------------------------------------------- Comment By: Michael Isard (mmisard) Date: 2001-08-09 13:46 Message: Logged In: YES user_id=252517 I just noticed this reading the code, so I have no test code which triggers it. Thanks, Michael. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:12 Message: Logged In: YES user_id=3066 This should not have been categorized as an XML::Parser issue. I did that, but I'm not at all sure why... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Fri Aug 10 14:47:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 06:47:04 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 06:47 Message: Logged In: YES user_id=3066 I'd certainly appreciate the confirmation! One thing I've learned working on Python is that anything that causes a memory violation is Pure Evil(tm) and must be squashed. ---------------------------------------------------------------------- Comment By: Andy Southgate (southa) Date: 2001-08-10 02:20 Message: Logged In: YES user_id=29974 Hi, I hit this bug for real running expat on an embedded platform (128K RAM) and can test, if that's any help. Thanks for the fix. Andy Southgate ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 13:52 Message: Logged In: YES user_id=3066 Ok, thanks! ---------------------------------------------------------------------- Comment By: Michael Isard (mmisard) Date: 2001-08-09 13:46 Message: Logged In: YES user_id=252517 I just noticed this reading the code, so I have no test code which triggers it. Thanks, Michael. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:12 Message: Logged In: YES user_id=3066 This should not have been categorized as an XML::Parser issue. I did that, but I'm not at all sure why... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Fri Aug 10 14:55:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 06:55:13 -0700 Subject: [ expat-Bugs-448560 ] xmlwf/Makefile uses unchecked SHELL var Message-ID: Bugs item #448560, was opened at 2001-08-06 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=448560&group_id=10127 Category: Build control >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sean Kelly (seankelly) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf/Makefile uses unchecked SHELL var Initial Comment: On FreeBSD 4.2 using standard BSD make (/usr/bin/make), "make install" fails in the xmlwf directory: saffron% pwd /u/kelly/src/expat-1.95.2/xmlwf saffron% make install /usr/local/bin/tcsh ../conftools/mkinstalldirs /usr/loc al/bin errstatus=0: Command not found. If I do "env SHELL=/bin/sh make install", then it's happy. Apparently, the SHELL setting doesn't get passed from the parent directory's Makefile, as it's just invoking "make" itself, so the child directory grabs it from the environment. GNU make works around the problem, too, as it explicitly sets SHELL to /bin/sh, ignoring the environment setting. I'd add another SHELL=/bin/sh like there is in the parent Makefile, or make it a configurable setting in the xmlwf Makefile. Thanks. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 06:55 Message: Logged In: YES user_id=3066 Fixed in xmlwf/Makefile.in revision 1.7; configure will now provide the appropriate value. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=448560&group_id=10127 From noreply@sourceforge.net Fri Aug 10 16:30:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 Aug 2001 08:30:27 -0700 Subject: [ expat-Bugs-434665 ] memory bug in XML_Parse Message-ID: Bugs item #434665, was opened at 2001-06-19 19:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory bug in XML_Parse Initial Comment: A check should be added to the end of XML_Parse() in xmlparse.c --- the line currently reads memcpy(XML_GetBuffer(parser, len), s, len); but XML_GetBuffer can return 0. Michael Isard. ---------------------------------------------------------------------- Comment By: Andy Southgate (southa) Date: 2001-08-10 08:30 Message: Logged In: YES user_id=29974 Yep, tested that one, and it now prints an error about being out of memory at line 1 instead of overwriting my vector table. Problem solved. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 06:47 Message: Logged In: YES user_id=3066 I'd certainly appreciate the confirmation! One thing I've learned working on Python is that anything that causes a memory violation is Pure Evil(tm) and must be squashed. ---------------------------------------------------------------------- Comment By: Andy Southgate (southa) Date: 2001-08-10 02:20 Message: Logged In: YES user_id=29974 Hi, I hit this bug for real running expat on an embedded platform (128K RAM) and can test, if that's any help. Thanks for the fix. Andy Southgate ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 13:52 Message: Logged In: YES user_id=3066 Ok, thanks! ---------------------------------------------------------------------- Comment By: Michael Isard (mmisard) Date: 2001-08-09 13:46 Message: Logged In: YES user_id=252517 I just noticed this reading the code, so I have no test code which triggers it. Thanks, Michael. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:12 Message: Logged In: YES user_id=3066 This should not have been categorized as an XML::Parser issue. I did that, but I'm not at all sure why... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 11:11 Message: Logged In: YES user_id=3066 Fixed in lib/xmlparse.c revision 1.22. Was this triggered by a real lack of memory or some other condition? Or was this found simply by reading the code? (If there's some other way to trigger the condition, I'd like to know about it so the diagnostics can be relatively specific.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=434665&group_id=10127 From noreply@sourceforge.net Mon Aug 13 22:01:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 13 Aug 2001 14:01:31 -0700 Subject: [ expat-Patches-450608 ] Proposal for XML_ParserReset function Message-ID: Patches item #450608, was opened at 2001-08-13 14:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=450608&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Crowley (dcrowley) Assigned to: Nobody/Anonymous (nobody) Summary: Proposal for XML_ParserReset function Initial Comment: This is my first cut at adding a XML_ParserReset function. My idea was to reset the parser to a state that was almost identical to what it is after XML_ParserCreate() except that any allocated memory is preserved. As this patch is currently, I think it misght still has some potential problems with dtdInit () and possibly internalEncoding and setContext(). But for my documents/application it seems to work great. It passes Purify without any memory leaks and when parsing 5000 documents, I only get ~40 memory allocations instead of ~200,000 :) The function declartion needed for expat.h: /* Resets an existing parser to a state comparable to that after XML_ParserCreate but preserves any allocated memory. */ XMLPARSEAPI(void) XML_ParserReset(XML_Parser parser, const XML_Char *encoding); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=450608&group_id=10127 From noreply@sourceforge.net Thu Aug 16 04:46:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 Aug 2001 20:46:30 -0700 Subject: [ expat-Patches-451440 ] Build xmlwf with libtool Message-ID: Patches item #451440, was opened at 2001-08-15 20:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (china) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: Build xmlwf with libtool Initial Comment: A patch to build xmlwf with libtool can be found at: ftp://ftp.thewrittenword.com/outgoing/pub/expat-1.95.2.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 From noreply@sourceforge.net Thu Aug 16 05:16:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 Aug 2001 21:16:12 -0700 Subject: [ expat-Patches-451440 ] Build xmlwf with libtool Message-ID: Patches item #451440, was opened at 2001-08-15 20:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None >Priority: 6 Submitted By: The Written Word (china) (tww-china) >Assigned to: Greg Stein (gstein) Summary: Build xmlwf with libtool Initial Comment: A patch to build xmlwf with libtool can be found at: ftp://ftp.thewrittenword.com/outgoing/pub/expat-1.95.2.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 From noreply@sourceforge.net Thu Aug 16 05:20:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 Aug 2001 21:20:39 -0700 Subject: [ expat-Patches-450608 ] Proposal for XML_ParserReset function Message-ID: Patches item #450608, was opened at 2001-08-13 14:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=450608&group_id=10127 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: David Crowley (dcrowley) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Proposal for XML_ParserReset function Initial Comment: This is my first cut at adding a XML_ParserReset function. My idea was to reset the parser to a state that was almost identical to what it is after XML_ParserCreate() except that any allocated memory is preserved. As this patch is currently, I think it misght still has some potential problems with dtdInit () and possibly internalEncoding and setContext(). But for my documents/application it seems to work great. It passes Purify without any memory leaks and when parsing 5000 documents, I only get ~40 memory allocations instead of ~200,000 :) The function declartion needed for expat.h: /* Resets an existing parser to a state comparable to that after XML_ParserCreate but preserves any allocated memory. */ XMLPARSEAPI(void) XML_ParserReset(XML_Parser parser, const XML_Char *encoding); ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-15 21:20 Message: Logged In: YES user_id=3066 Well, the number of allocations being so substantially reduced is nice to know. I don't know just when I'll get a chance to look at this, but I promise I will get to it! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=450608&group_id=10127 From noreply@sourceforge.net Fri Aug 17 20:02:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 Aug 2001 12:02:47 -0700 Subject: [ expat-Bugs-447197 ] NULLs as whitespace or character data Message-ID: Bugs item #447197, was opened at 2001-08-02 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=447197&group_id=10127 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Keith Tingle (ktingle) Assigned to: Nobody/Anonymous (nobody) Summary: NULLs as whitespace or character data Initial Comment: We had a nasty bug in a Perl script that embedded NULL values into our Xml documents. msxml treated the NULL values as whitespace and ignored them, Expat will not handle NULL values in the stream. Neither seems correct to me as the spec says nothing about NULLs being treated as whitespace and character data is anything that is not markup data; http://www.w3.org/TR/REC-xml#dt-chardata I know this is esoteric but shouldn't Expat treat NULLs as character data? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-17 12:02 Message: Logged In: YES user_id=3066 The ASCII NUL character is illegal in XML; see section 2.2 of the XML 1.0 recommendation. More MSXML3.0 and the MSXML4.0 preview releases supposedly fix this if they are not being used in backward-compatibility mode (i.e., use the version-specific CLSIDs, and you get conforming behavior). Classifying this as "not a bug." ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=447197&group_id=10127 From stanb@awod.com Sat Aug 18 22:08:12 2001 From: stanb@awod.com (Stan Brown) Date: Sat, 18 Aug 2001 17:08:12 -0400 (EDT) Subject: Expat 1.95.1 build failure on HP-UX 10.20 Message-ID: I'm trying to build on HP-UX 10.20, I have tried both Gcc, and HP's ANSI C compile both fail in the exact same way. checking if the linker (/opt/gnu/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.7.2.1/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes loading cache /dev/null within ltconfig ltconfig: you must specify a host type if you use `--no-verify' Try `ltconfig --help' for more information. configure: error: libtool configure failed Sugestions? -- Stan Brown stanb@awod.com 843-745-3154 Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited. From noreply@sourceforge.net Tue Aug 21 00:42:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 16:42:13 -0700 Subject: [ expat-Bugs-453546 ] memmove() segv inside XML_GetBuffer Message-ID: Bugs item #453546, was opened at 2001-08-20 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bart Schaefer (barts) Assigned to: Clark Cooper (coopercc) Summary: memmove() segv inside XML_GetBuffer Initial Comment: I do not believe this to be the same bug as 434665. I'm using XML::Parser::EasyTree. I wrote a module that, when perl is run from the shell command line, successfully parses an XML file and interprets the resulting tree. When I use the same module as a mod_perl handler for an upload of exactly the same file, I get a segmentation fault. GDB on a single-threaded httpd shows this to be happening on a memmove() call with dest=0x0, *inside* XML_GetBuffer(). The fix in xmlparse.c rev 1.22 only helps after XML_GetBuffer() returns 0, and I don't get that far. I'm using the 1.95.2-1 RPM on RedHat 6.2 linux, with perl 5.6.0 and XML::Parser both installed using the CPAN shell. I've tried it on two different machines with Apache 1.3.14/ mod_perl 1.24_01 and Apache 1.3.19/mod_perl 1.25, with the same results. If I can come up with a minimal file that reproduces this, I'll attach it to this bug report later. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 From noreply@sourceforge.net Tue Aug 21 02:11:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 Aug 2001 18:11:38 -0700 Subject: [ expat-Bugs-453546 ] memmove() segv inside XML_GetBuffer (mod_perl) Message-ID: Bugs item #453546, was opened at 2001-08-20 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 Category: XML::Parser (Perl module) Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Bart Schaefer (barts) Assigned to: Clark Cooper (coopercc) >Summary: memmove() segv inside XML_GetBuffer (mod_perl) Initial Comment: I do not believe this to be the same bug as 434665. I'm using XML::Parser::EasyTree. I wrote a module that, when perl is run from the shell command line, successfully parses an XML file and interprets the resulting tree. When I use the same module as a mod_perl handler for an upload of exactly the same file, I get a segmentation fault. GDB on a single-threaded httpd shows this to be happening on a memmove() call with dest=0x0, *inside* XML_GetBuffer(). The fix in xmlparse.c rev 1.22 only helps after XML_GetBuffer() returns 0, and I don't get that far. I'm using the 1.95.2-1 RPM on RedHat 6.2 linux, with perl 5.6.0 and XML::Parser both installed using the CPAN shell. I've tried it on two different machines with Apache 1.3.14/ mod_perl 1.24_01 and Apache 1.3.19/mod_perl 1.25, with the same results. If I can come up with a minimal file that reproduces this, I'll attach it to this bug report later. ---------------------------------------------------------------------- >Comment By: Bart Schaefer (barts) Date: 2001-08-20 18:11 Message: Logged In: YES user_id=22647 This appears to be a problem with use of global data that is getting messed up by mod_perl. I converted to a CGI script and it works fine now. I reduced the priority and mentioned mod_perl in the summary. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=453546&group_id=10127 From paul@softco.com.au Tue Aug 21 05:48:18 2001 From: paul@softco.com.au (Haesler, Paul) Date: Tue, 21 Aug 2001 14:48:18 +1000 Subject: Makefile problem Message-ID: <510C573EF157D011A6EB0000C00EE6DB3A2F66@ntserver.softco.com.au> Expat 1.95.2; Generic Unix tarball. On following the instructions in the README file, I got the following output from make: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. gmake[1]: *** [xmlwf] Error 1 "-static" is not a valid compiler/linker flag. For some reason it is specified explicitly in Makefile.in - it is not dependent on the results of the configure operation. I commented out the LDFLAGS line in xmlwf/Makefile and it compiled fine. System description: uname -a: SunOS suntzu 5.6 Generic_105181-21 sun4m sparc SUNW,SPARCstation-20 GNU make and /opt/SUNWspro/bin/cc Regards, Paul Haesler (paul@softco.com.au) Softco Solutions Ph: (03) 9882 3166 Fax: (03) 9882 3266 From c.w.huling@pobox.com Tue Aug 21 21:51:50 2001 From: c.w.huling@pobox.com (c.w.huling@pobox.com) Date: Tue, 21 Aug 2001 16:51:50 -0400 (EDT) Subject: DTD: ENTITY in ATTLIST Message-ID: <15234.51686.979853.810438@cx528142-a.vbch1.va.home.com> Following som examples I have found in a book, I ran across using an entity inside an attributes list. I have tried this, but get an error using the outline example with expat 1.95.1 and 1.95.2. ]> ./outline < doc.xml Parse error at line 12: illegal parameter entity reference -- C Wayne Huling From noreply@sourceforge.net Wed Aug 22 21:23:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 Aug 2001 13:23:16 -0700 Subject: [ expat-Bugs-445955 ] Make of 1.95.2 fails on MacOS X 10.0.4 Message-ID: Bugs item #445955, was opened at 2001-07-30 07:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make of 1.95.2 fails on MacOS X 10.0.4 Initial Comment: expat 1.95.2.tar.gz distribution On MacOS X 10.0.4 (Darwin 1.3.7) make issues an error and halts: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt 0.o make[1]: *** [xmlwf] Error 1 ma ke: *** [xmlwf] Error 2 This does not happen with the older version 1.95.1 ---------------------------------------------------------------------- Comment By: nat irons (bumppo) Date: 2001-08-22 13:23 Message: Logged In: YES user_id=8138 I also see make breaking on xmlwf with 1.95.2 on Mac OS X 10.0.4, but my symptoms are slightly different: gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: xmlwf.o incompatible, file contains unsupported type of section 5 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: xmlfile.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: unixfilemap.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 If you'd like to follow up with someone having the first problem, it was also reported on the perl-macosx list. Like the original poster, 1.95.1 installs smoothly for me here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 From noreply@sourceforge.net Fri Aug 24 08:39:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 Aug 2001 00:39:42 -0700 Subject: [ expat-Bugs-454879 ] Compile of xmlwf fails in cygwin v1.95.2 Message-ID: Bugs item #454879, was opened at 2001-08-24 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Pabs (pabs3) Assigned to: Greg Stein (gstein) Summary: Compile of xmlwf fails in cygwin v1.95.2 Initial Comment: make.log attached The short of it is that the .o files in the xmlwf dir reference functions in the lib as _imp__, but in the lib (libexpat.a) the functions are named _ & just Probably some gcc flag was omitted from one or the other. Bye, Pabs ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 From noreply@sourceforge.net Sat Aug 25 14:57:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 Aug 2001 06:57:05 -0700 Subject: [ expat-Patches-455263 ] Make install error of xmlwf Message-ID: Patches item #455263, was opened at 2001-08-25 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=455263&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: TAKAHASHI Masayoshi (maki) Assigned to: Nobody/Anonymous (nobody) Summary: Make install error of xmlwf Initial Comment: On FreeBSD-4.2 RELEASE, I cannot install xmlwf, because standard shell in FreeBSD is csh(tcsh). It's a small patch. %diff -u xmlwf/Makefile.in~ xmlwf/Makefile.in --- xmlwf/Makefile.in~ Sat Jul 28 05:33:34 2001 +++ xmlwf/Makefile.in Sat Aug 25 22:38:41 2001 @@ -18,6 +18,8 @@ # SOFTWARE OR THE USE OR OTHER DEALINGS IN EXPAT. # +SHELL = @SHELL@ + bindir = @bindir@ LIBDIR= ../lib/.libs ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=455263&group_id=10127 From noreply@sourceforge.net Sat Aug 25 15:16:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 Aug 2001 07:16:51 -0700 Subject: [ expat-Patches-455263 ] Make install error of xmlwf Message-ID: Patches item #455263, was opened at 2001-08-25 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=455263&group_id=10127 >Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: TAKAHASHI Masayoshi (maki) >Assigned to: Greg Stein (gstein) Summary: Make install error of xmlwf Initial Comment: On FreeBSD-4.2 RELEASE, I cannot install xmlwf, because standard shell in FreeBSD is csh(tcsh). It's a small patch. %diff -u xmlwf/Makefile.in~ xmlwf/Makefile.in --- xmlwf/Makefile.in~ Sat Jul 28 05:33:34 2001 +++ xmlwf/Makefile.in Sat Aug 25 22:38:41 2001 @@ -18,6 +18,8 @@ # SOFTWARE OR THE USE OR OTHER DEALINGS IN EXPAT. # +SHELL = @SHELL@ + bindir = @bindir@ LIBDIR= ../lib/.libs ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-25 07:16 Message: Logged In: YES user_id=3066 Assigned to the buildmeister; note that there are two xmlwf build patches to look at. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=455263&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:27:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:27:41 -0700 Subject: [ expat-Patches-455263 ] Make install error of xmlwf Message-ID: Patches item #455263, was opened at 2001-08-25 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=455263&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: TAKAHASHI Masayoshi (maki) Assigned to: Greg Stein (gstein) Summary: Make install error of xmlwf Initial Comment: On FreeBSD-4.2 RELEASE, I cannot install xmlwf, because standard shell in FreeBSD is csh(tcsh). It's a small patch. %diff -u xmlwf/Makefile.in~ xmlwf/Makefile.in --- xmlwf/Makefile.in~ Sat Jul 28 05:33:34 2001 +++ xmlwf/Makefile.in Sat Aug 25 22:38:41 2001 @@ -18,6 +18,8 @@ # SOFTWARE OR THE USE OR OTHER DEALINGS IN EXPAT. # +SHELL = @SHELL@ + bindir = @bindir@ LIBDIR= ../lib/.libs ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:27 Message: Logged In: YES user_id=6501 This was fixed in the latest CVS. The top-level Makefile handles the installation, and it has the proper @SHELL@ syntax. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-25 07:16 Message: Logged In: YES user_id=3066 Assigned to the buildmeister; note that there are two xmlwf build patches to look at. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=455263&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:30:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:30:54 -0700 Subject: [ expat-Patches-451440 ] Build xmlwf with libtool Message-ID: Patches item #451440, was opened at 2001-08-15 20:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 Category: Build Control Group: None Status: Open >Resolution: Accepted Priority: 6 Submitted By: The Written Word (china) (tww-china) Assigned to: Greg Stein (gstein) Summary: Build xmlwf with libtool Initial Comment: A patch to build xmlwf with libtool can be found at: ftp://ftp.thewrittenword.com/outgoing/pub/expat-1.95.2.patch ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:30 Message: Logged In: YES user_id=6501 The xmlwf Makefile is going away, in favor of all compilation and linking from the top-level Makefile. At that point, everything will use libtool properly. I'll close this bug once that occurs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:34:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:34:12 -0700 Subject: [ expat-Patches-438892 ] Probing macro for autoconf/aclocal Message-ID: Patches item #438892, was opened at 2001-07-05 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=438892&group_id=10127 Category: Build Control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Probing macro for autoconf/aclocal Initial Comment: Here is the autoconf probing macro suitable to be included by aclocal. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:34 Message: Logged In: YES user_id=6501 This is something that an Expat-using app can include in their configuration script to locate and use Expat. Maybe part of the doc? (e.g. an example of how to find Expat) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 13:07 Message: Logged In: YES user_id=3066 I'm not sure how this should be used; can someone provide a brief example? Should this just get tossed in the conftools/ directory and mentioned in the README? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=438892&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:37:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:37:00 -0700 Subject: [ expat-Bugs-222061 ] configure: error: no acceptable ld found in $PATH Message-ID: Bugs item #222061, was opened at 2000-11-09 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=222061&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: D Singh (daywan) Assigned to: Greg Stein (gstein) Summary: configure: error: no acceptable ld found in $PATH Initial Comment: Trying to install expat on SunOS 5.8 using ./configure --prefix=/home/tmp ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:37 Message: Logged In: YES user_id=6501 If an "ld" isn't found, then there is nothing that we can do. It sounds like a configuration/estup problem on your system. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-01-26 11:21 Message: Where is ld on your system? Perhaps you need to add something to your path. Take a look in /usr/ccs/bin, /usr/ucb/bin. Please let us know if you find it there and adding the directory fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=222061&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:40:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:40:21 -0700 Subject: [ expat-Bugs-230172 ] examples and xmlwf Makefile.in don't support builddir Message-ID: Bugs item #230172, was opened at 2001-01-26 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=230172&group_id=10127 Category: Build control Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Axel Hecht (axelhecht) Assigned to: Greg Stein (gstein) Summary: examples and xmlwf Makefile.in don't support builddir Initial Comment: The Makefile.in's for xmlwf and examples don't cope with a build dir != srcdir. Please add srcdir = @srcdir@ top_srcdir = @top_srcdir@ VPATH = @srcdir@ and add -I$(srcdir)/../lib to CFLAGS. Should LDFLAGS do -L../lib, or -L../lib/.libs? Axel ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:40 Message: Logged In: YES user_id=6501 We should be linking using libtool, and link against libexpat.la. We won't have to know anything about the .libs directory in that case. The vpath stuff has been handled, yes. It will be even simpler when we complete the move to a single makefile. Leaving open until we make the final switch to libtool- based linking. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 14:50 Message: Logged In: YES user_id=3066 I'm not sure what the deal should be with the LDFLAGS setting; I'll leave that with Greg for a little longer, at least until I can read up some more on libtool. The other changes appear to have already been made in CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=230172&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:42:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:42:46 -0700 Subject: [ expat-Bugs-231288 ] Undeclared VERSION under WinNT&Borland C++ Builder Message-ID: Bugs item #231288, was opened at 2001-02-06 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=231288&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Undeclared VERSION under WinNT&Borland C++ Builder Initial Comment: When I try to make expat 1.95.1 under WinNT using Borland C++ Builder, the last failed to find #define VERSION ... I set `COMPILE_FROM_DSP' (or smth. like that, not sure now), it includes winconfig.h, but this header does not contain declaration of VERSION. So, I had to add #ifndef VERSION #define VERSION "1.95.1" #endif m.b. it'll be better, if you add this declaration in it? ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:42 Message: Logged In: YES user_id=6501 We have revamped the use/need of the VERSION symbol. It is now computed from the individual version number components, and it works in a platform-independent fashion. IOW, it has been fixed in CVS and will appear in 1.95.3 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 12:21 Message: Logged In: YES user_id=3066 I don't know much about the Borland product. I've spent a fair bit of time over the last day getting the Windows build back up to snuff (and am just hoping I succeeded!), so there are new .dsp and .dsw files for MSVC in the CVS repository. I don't know if Borland C++ Builder can use those. I'd like to make this work, but suspect I'll need help on Windows, especially with compilers other than MSVC. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 20:48 Message: Logged In: YES user_id=3066 The build has changed a little bit on Unix, but the Windows port has fallen behind. Can anyone determine if this is still a problem? Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=231288&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:48:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:48:06 -0700 Subject: [ expat-Bugs-436688 ] make install fails under cygwin Message-ID: Bugs item #436688, was opened at 2001-06-27 03:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=436688&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Ricardo Gladwell (axonrg) Assigned to: Greg Stein (gstein) Summary: make install fails under cygwin Initial Comment: Configuration and compilation for expat 1.95.1 and expat 1.95.0 seems to work fine under cygwin. However, after executing: > ./configure > make Running 'make install' fails when it attempts to archive the libexpat.a file using ranlib. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:48 Message: Logged In: YES user_id=6501 This appears to be a problem with the toolset under cygwin, rather than anything that Expat is doing. We did not create the .a file and we did not supply the ranlib program. If you can isolate a fix for Expat, then we'd be most obliged. Until then, I cannot see what to "fix" in our scripts. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=436688&group_id=10127 From noreply@sourceforge.net Sun Aug 26 11:59:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 03:59:25 -0700 Subject: [ expat-Bugs-438393 ] expat compile fails in ld on HPUX 11.0 Message-ID: Bugs item #438393, was opened at 2001-07-03 16:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438393&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: SANJAY WAZA (sanjay_waza) Assigned to: Greg Stein (gstein) Summary: expat compile fails in ld on HPUX 11.0 Initial Comment: I failed to install the expat . I am not able to understand why The configure with though fine , It failed in make The results of configure are ./configure -- prefix=/users/summit/implementation/admin/expat ./configure -- prefix=/users/summit/implementation/admin/expat loading cache ./config.cache checking host system type... hppa2.0w-hp-hpux11.00 checking build system type... hppa2.0w-hp-hpux11.00 checking for ranlib... (cached) ranlib checking for gcc... (cached) cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for non-GNU ld... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /usr/bin/nm -p checking whether ln -s works... (cached) yes loading cache ./config.cache within ltconfig checking whether we are using GNU C... no checking for object suffix... o checking for executable suffix... (cached) no checking for cc option to produce PIC... +Z checking if cc PIC flag +Z works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc static flag -Wl,-a -Wl,archive works... -Wl,-a -Wl,archive checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -p output... failed checking how to hardcode library paths into programs... relink checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... hpux11.00 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g ) works... yes checking whether the C compiler (cc -g ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /opt/imake/bin/install -c checking how to run the C preprocessor... (cached) cc - E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) yes checking for working const... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) no checking for memmove... (cached) yes checking for bcopy... (cached) yes creating ./config.status creating Makefile creating lib/Makefile creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged In Make it gives the following error autoconf Make: Cannot load autoconf. Stop. *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 03:59 Message: Logged In: YES user_id=6501 This was some crappy stuff in the Makefile that would attempt to regenerate the ./configure script if it was out of date with respect to configure.in (for whatever reason). Thus, it would try to run autoconf. I fixed this in CVS a couple days ago; you'll see the fix in the 1.93.3 release. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 20:51 Message: Logged In: YES user_id=3066 Can you test this with the current CVS version of Expat? The build process has changed a fair bit, and suspect this may have changed. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438393&group_id=10127 From noreply@sourceforge.net Sun Aug 26 12:05:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 04:05:17 -0700 Subject: [ expat-Bugs-409729 ] Make Fails Digital Unix 4.0d Message-ID: Bugs item #409729, was opened at 2001-03-19 05:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=409729&group_id=10127 Category: Build control Group: Platform Specific Status: Open >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make Fails Digital Unix 4.0d Initial Comment: ./configure works fine. But when I run >make I get nothing it just exits quietly without doing anything if I run >make install i get /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=1.95.0 -I. -I.. -g -c libtool: compile: cannot determine name of library object from '-c' *** Exit 1 Stop. *** Exit 1 Stop. Any help with this bug would be greatly appreciated. Thanks Bill ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 04:05 Message: Logged In: YES user_id=6501 The build system is being revamped further for the 1.95.3 release. It should not have a problem. I will close this bug when the build revamp is completed (i.e. when I believe we've truly nailed this issue). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-04 18:37 Message: Logged In: YES user_id=3066 Can anyone experiancing this problem reproduce it with the current CVS version? There have been a fair number of cleanups in the build control (thanks, Greg!). Assigned to Greg for monitoring. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-19 09:08 Message: Logged In: NO I could not get this to compile however, from following another lead in the bug reports I managed to get expat-1.95.1 in setld format for DU4.0d from ftp.thewrittenword.com. Problem Solved (sort of) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-19 07:28 Message: Logged In: NO I installed the latest gnu make and got cd lib; /usr/local/bin/make make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c rm -f .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -DPIC -o .libs/xmlparse.lo cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make: *** [lib] Error 2 so I looked through the old bug fixes and attempted to fix things by altering lib/Makefile.in according to other fixes: first I tried this: commenting out the following rules @echo '$(COMPILE) -c $<'; \ # $(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $< # @-cp .deps/$(*F).pp .deps/$(*F).P; \ # tr ' ' '\012' < .deps/$(*F).pp \ # | sed -e 's/^\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \ # >> .deps/$(*F).P; \ # rm .deps/$(*F).pp .c.lo: @echo '$(LTCOMPILE) -c $<'; \ # test -d .deps || mkdir .deps ; \ # $(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $< # @-sed -e 's/^\([^:]*\)\.o[ ]*:/\1.lo \1.o :/' \ # < .deps/$(*F).pp > .deps/$(*F).P; \ # tr ' ' '\012' < .deps/$(*F).pp \ # | sed -e 's/^\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \ # >> .deps/$(*F).P; \ # rm -f .deps/$(*F).pp and got this make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' cd .. \ && CONFIG_FILES=lib/Makefile CONFIG_HEADERS= /bin/sh ./config.status creating lib/Makefile make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmltok.c /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlrole.c /bin/sh ../libtool --mode=link cc -version-info 0:1:0 -g -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* (cd . && ln -s xmlparse.lo xmlparse.o) (cd . && ln -s xmltok.lo xmltok.o) ln: xmltok.o exists, specify -f to remove. make[1]: *** [libexpat.la] Error 1 make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make: *** [lib] Error 2 then i tried changing lines with -Wp,-MD,. to -Wp,-M. and got : make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' cd .. \ && CONFIG_FILES=lib/Makefile CONFIG_HEADERS= /bin/sh ./config.status creating lib/Makefile make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c rm -f .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -Wp,-M.deps/xmlparse.pp -c xmlparse.c -DPIC -o .libs/xmlparse.lo cc: Error: Extraneous text follows Boolean option name in "-M.deps/xmlparse.pp" make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make: *** [lib] Error 2 Still looking for a solution. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=409729&group_id=10127 From noreply@sourceforge.net Sun Aug 26 12:06:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 04:06:48 -0700 Subject: [ expat-Bugs-446957 ] Make exits silently Message-ID: Bugs item #446957, was opened at 2001-08-01 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=446957&group_id=10127 Category: Build control Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make exits silently Initial Comment: Platform: Solaris 8 gcc 2.95.3 gnu make (or Sol8 make - same effect with both) "./configure" succeeds. running "make" produces nothing. Reverted to 1.95.1, works fine. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-08-26 04:06 Message: Logged In: YES user_id=6501 No idea. We'll have a simpler system shortly, and can try that. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 10:52 Message: Logged In: YES user_id=3066 I'm very surprised that you're having difficulties even with GNU make; can you please double-check that? I observed the same problem with Sun make (Solaris 8, but I think any version will do); it doesn't seem to understand the .PHONY directives in the makefile. GNU make worked fine for me, though. Greg, any wisdom here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=446957&group_id=10127 From noreply@sourceforge.net Mon Aug 27 06:38:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 Aug 2001 22:38:50 -0700 Subject: [ expat-Bugs-454879 ] Compile of xmlwf fails in cygwin v1.95.2 Message-ID: Bugs item #454879, was opened at 2001-08-24 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Pabs (pabs3) Assigned to: Greg Stein (gstein) Summary: Compile of xmlwf fails in cygwin v1.95.2 Initial Comment: make.log attached The short of it is that the .o files in the xmlwf dir reference functions in the lib as _imp__, but in the lib (libexpat.a) the functions are named _ & just Probably some gcc flag was omitted from one or the other. Bye, Pabs ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-26 22:38 Message: Logged In: NO to clarify v1.95.2 is the expat version number ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 From noreply@sourceforge.net Tue Aug 28 00:29:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 Aug 2001 16:29:58 -0700 Subject: [ expat-Bugs-454879 ] Compile of xmlwf fails in cygwin v1.95.2 Message-ID: Bugs item #454879, was opened at 2001-08-24 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Pabs (pabs3) Assigned to: Greg Stein (gstein) Summary: Compile of xmlwf fails in cygwin v1.95.2 Initial Comment: make.log attached The short of it is that the .o files in the xmlwf dir reference functions in the lib as _imp__, but in the lib (libexpat.a) the functions are named _ & just Probably some gcc flag was omitted from one or the other. Bye, Pabs ---------------------------------------------------------------------- Comment By: David Crowley (dcrowley) Date: 2001-08-27 16:29 Message: Logged In: YES user_id=27458 I have this same problem. I had to make a change to expat.h. I fixed it by changing the macro for XMLPARSEAPI. I just added the "&& !defined(__CYGWIN32)". Here it is: #ifndef XMLPARSEAPI # if defined(__declspec) && !defined(__BEOS__) && !defined (__CYGWIN32__) # define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else # define XMLPARSEAPI(type) type # endif #endif /* not defined XMLPARSEAPI */ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-26 22:38 Message: Logged In: NO to clarify v1.95.2 is the expat version number ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 From dblumberg@oasis-inc.com Tue Aug 28 18:52:47 2001 From: dblumberg@oasis-inc.com (Dave Blumberg) Date: Tue, 28 Aug 2001 13:52:47 -0400 Subject: Windows 2000 Release-32 Build Errors Message-ID: Has anyone been able to build expat as a Release-32 build, under Visual C++ 6.0 on Windows 2000 ? From fdrake@acm.org Tue Aug 28 18:53:33 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 28 Aug 2001 13:53:33 -0400 Subject: Windows 2000 Release-32 Build Errors In-Reply-To: References: Message-ID: <15243.55965.809808.756945@grendel.digicool.com> Dave Blumberg writes: > Has anyone been able to build expat as a Release-32 build, under Visual C++ > 6.0 on Windows 2000 ? The release was built that way; are you using the .tar.gz package or the Windows installer? (The installer includes the sources.) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From noreply@sourceforge.net Wed Aug 29 12:38:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 Aug 2001 04:38:42 -0700 Subject: [ expat-Bugs-454879 ] Compile of xmlwf fails in cygwin v1.95.2 Message-ID: Bugs item #454879, was opened at 2001-08-24 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Pabs (pabs3) Assigned to: Greg Stein (gstein) Summary: Compile of xmlwf fails in cygwin v1.95.2 Initial Comment: make.log attached The short of it is that the .o files in the xmlwf dir reference functions in the lib as _imp__, but in the lib (libexpat.a) the functions are named _ & just Probably some gcc flag was omitted from one or the other. Bye, Pabs ---------------------------------------------------------------------- Comment By: Neil Lunn (corrosion) Date: 2001-08-29 04:38 Message: Logged In: YES user_id=78218 Meaning that the above patch should actually be applied to expat.h.in from the source distribution. Could someone confirm the CVS commit? ---------------------------------------------------------------------- Comment By: David Crowley (dcrowley) Date: 2001-08-27 16:29 Message: Logged In: YES user_id=27458 I have this same problem. I had to make a change to expat.h. I fixed it by changing the macro for XMLPARSEAPI. I just added the "&& !defined(__CYGWIN32)". Here it is: #ifndef XMLPARSEAPI # if defined(__declspec) && !defined(__BEOS__) && !defined (__CYGWIN32__) # define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else # define XMLPARSEAPI(type) type # endif #endif /* not defined XMLPARSEAPI */ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-26 22:38 Message: Logged In: NO to clarify v1.95.2 is the expat version number ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=454879&group_id=10127