From noreply at sourceforge.net Tue Jan 4 18:24:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 18:24:56 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 09:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&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 on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Tue Jan 4 19:13:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 19:13:30 2005 Subject: [Expat-bugs] [ expat-Bugs-1058173 ] building expat 1.95.8 on Solaris using Sun Compiler Message-ID: Bugs item #1058173, was opened at 2004-11-01 09:49 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1058173&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: building expat 1.95.8 on Solaris using Sun Compiler Initial Comment: Hi I'm trying to build on a Solaris system using a SUN compiler. ./configure returned host system type=sparc-sun-solaris2.8 However the build failed and returned the following /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file __eprintf lib/xmlparse.lo ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 make: *** [libexpat.la] Error 1 Any help or advice regarding building the expat 1.95.8 would be greatly appreciated. Regards Thomas thomas@robots.ox.ac.uk ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 13:13 Message: Logged In: YES user_id=290026 Duplicate of issue # 1058158. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1058173&group_id=10127 From noreply at sourceforge.net Tue Jan 4 19:14:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 19:14:47 2005 Subject: [Expat-bugs] [ expat-Bugs-1058218 ] building expat 1.95.8 on Solaris using Sun Compiler Message-ID: Bugs item #1058218, was opened at 2004-11-01 10:39 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1058218&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: building expat 1.95.8 on Solaris using Sun Compiler Initial Comment: Hi I'm trying to build on a Solaris system using a SUN compiler. ./configure returned host system type=sparc-sun-solaris2.8 However the build failed and returned the following /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file __eprintf lib/xmlparse.lo ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 make: *** [libexpat.la] Error 1 Any help or advice regarding building the expat 1.95.8 would be greatly appreciated. Regards Thomas thomas@robots.ox.ac.uk ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 13:14 Message: Logged In: YES user_id=290026 Duplicate of issue # 1058158. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1058218&group_id=10127 From noreply at sourceforge.net Tue Jan 4 19:19:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 19:19:13 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 12:24 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&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 on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 13:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Tue Jan 4 20:49:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 20:49:54 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 09:24 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&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 on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 11:49 Message: Logged In: NO Hmmmm... The one in CVS and the one that came with the package I downloaded from sourceforge (expat-1.95.8.tar.gz) are radically different. It isn't clear to me which version of this file exists in the package I got here at SF, but I compared it to 1.143, and they aren't the same. Here is a copy of my UNIX diff file: 1444c1444 < to detect errors based on that fact. --- > to detect errors based on this information. 1497a1498 > positionPtr = end; 1519a1521,1522 > bufferPtr = buffer; > bufferEnd = buffer + nLeftOver; 1521,1526d1523 < bufferPtr = buffer; < bufferEnd = buffer + nLeftOver; < positionPtr = bufferPtr; < parseEndPtr = bufferEnd; < eventPtr = bufferPtr; < eventEndPtr = bufferPtr; 1545c1542 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1704c1701 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1842c1839 < static const XML_LChar* const message[] = { --- > static const XML_LChar *message[] = { 1860c1857 < XML_L("XML or text declaration not at start of entity"), --- > XML_L("xml declaration not at start of external entity"), 1880c1877 < XML_L("cannot suspend in external parameter entity"), --- > XML_L("cannot suspend in external parameter entity") 1881,1883d1877 < XML_L("reserved prefix (xml) must not be undeclared or bound to another namespace name"), < XML_L("reserved prefix (xmlns) must not be declared or undeclared"), < XML_L("prefix must not be bound to one of the reserved namespace names") 1925,1927c1919,1921 < static const XML_Feature features[] = { < {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), < sizeof(XML_Char)}, --- > static XML_Feature features[] = { > {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), 0}, > {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), 0}, 1928,1929d1921 < {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), < sizeof(XML_LChar)}, 1948a1941,1942 > features[0].value = sizeof(XML_Char); > features[1].value = sizeof(XML_LChar); 2831c2825 < j < step ? (j += nsAttsSize - step) : (j -= step); --- > j < step ? ( j += nsAttsSize - step) : (j -= step); 2888c2882 < ; /* prefixLen includes null terminator */ --- > ; 2895c2889 < ; /* i includes null terminator */ --- > ; 2910d2903 < /* if namespaceSeparator != '\0' then uri includes it already */ 2913d2905 < /* we always have a namespace separator between localPart and prefix */ 2915,2916c2907,2908 < uri += i - 1; < *uri = namespaceSeparator; /* replace null terminator */ --- > uri = uri + (i - 1); > if (namespaceSeparator) 2916a2909 > *uri = namespaceSeparator; 2930,2949d2922 < static const XML_Char xmlNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', < 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' < }; < static const int xmlLen = < (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; < static const XML_Char xmlnsNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' < }; < static const int xmlnsLen = < (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; < < XML_Bool mustBeXML = XML_FALSE; < XML_Bool isXML = XML_TRUE; < XML_Bool isXMLNS = XML_TRUE; < 2957,2958c2930,2931 < if (prefix->name < && prefix->name[0] == XML_T('x') --- > for (len = 0; uri[len]; len++) > ; 2959,2989d2931 < && prefix->name[1] == XML_T('m') < && prefix->name[2] == XML_T('l')) { < < /* Not allowed to bind xmlns */ < if (prefix->name[3] == XML_T('n') < && prefix->name[4] == XML_T('s') < && prefix->name[5] == XML_T('\0')) < return XML_ERROR_RESERVED_PREFIX_XMLNS; < < if (prefix->name[3] == XML_T('\0')) < mustBeXML = XML_TRUE; < } < < for (len = 0; uri[len]; len++) { < if (isXML && (len > xmlLen || uri[len] != xmlNamespace [len])) < isXML = XML_FALSE; < < if (!mustBeXML && isXMLNS < && (len > xmlnsLen || uri[len] != xmlnsNamespace [len])) < isXMLNS = XML_FALSE; < } < isXML = isXML && len == xmlLen; < isXMLNS = isXMLNS && len == xmlnsLen; < < if (mustBeXML != isXML) < return mustBeXML ? XML_ERROR_RESERVED_PREFIX_XML < : XML_ERROR_RESERVED_NAMESPACE_URI; < < if (isXMLNS) < return XML_ERROR_RESERVED_NAMESPACE_URI; < 5347c5289 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) 5373c5315 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) Should I try simply replacing xmlparse.c with the one from CVS in my distro? Thanks, --Scott ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 10:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Tue Jan 4 20:54:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 20:54:35 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 12:24 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&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 on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 14:54 Message: Logged In: YES user_id=290026 The changes seem to be just the ones made since 1.95.8, so your version looks OK. Which compiler are you using? Is it in ANSI compatibility mode? I am not the build expert here, so if you find a solution, please let me know. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 14:49 Message: Logged In: NO Hmmmm... The one in CVS and the one that came with the package I downloaded from sourceforge (expat-1.95.8.tar.gz) are radically different. It isn't clear to me which version of this file exists in the package I got here at SF, but I compared it to 1.143, and they aren't the same. Here is a copy of my UNIX diff file: 1444c1444 < to detect errors based on that fact. --- > to detect errors based on this information. 1497a1498 > positionPtr = end; 1519a1521,1522 > bufferPtr = buffer; > bufferEnd = buffer + nLeftOver; 1521,1526d1523 < bufferPtr = buffer; < bufferEnd = buffer + nLeftOver; < positionPtr = bufferPtr; < parseEndPtr = bufferEnd; < eventPtr = bufferPtr; < eventEndPtr = bufferPtr; 1545c1542 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1704c1701 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1842c1839 < static const XML_LChar* const message[] = { --- > static const XML_LChar *message[] = { 1860c1857 < XML_L("XML or text declaration not at start of entity"), --- > XML_L("xml declaration not at start of external entity"), 1880c1877 < XML_L("cannot suspend in external parameter entity"), --- > XML_L("cannot suspend in external parameter entity") 1881,1883d1877 < XML_L("reserved prefix (xml) must not be undeclared or bound to another namespace name"), < XML_L("reserved prefix (xmlns) must not be declared or undeclared"), < XML_L("prefix must not be bound to one of the reserved namespace names") 1925,1927c1919,1921 < static const XML_Feature features[] = { < {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), < sizeof(XML_Char)}, --- > static XML_Feature features[] = { > {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), 0}, > {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), 0}, 1928,1929d1921 < {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), < sizeof(XML_LChar)}, 1948a1941,1942 > features[0].value = sizeof(XML_Char); > features[1].value = sizeof(XML_LChar); 2831c2825 < j < step ? (j += nsAttsSize - step) : (j -= step); --- > j < step ? ( j += nsAttsSize - step) : (j -= step); 2888c2882 < ; /* prefixLen includes null terminator */ --- > ; 2895c2889 < ; /* i includes null terminator */ --- > ; 2910d2903 < /* if namespaceSeparator != '\0' then uri includes it already */ 2913d2905 < /* we always have a namespace separator between localPart and prefix */ 2915,2916c2907,2908 < uri += i - 1; < *uri = namespaceSeparator; /* replace null terminator */ --- > uri = uri + (i - 1); > if (namespaceSeparator) 2916a2909 > *uri = namespaceSeparator; 2930,2949d2922 < static const XML_Char xmlNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', < 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' < }; < static const int xmlLen = < (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; < static const XML_Char xmlnsNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' < }; < static const int xmlnsLen = < (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; < < XML_Bool mustBeXML = XML_FALSE; < XML_Bool isXML = XML_TRUE; < XML_Bool isXMLNS = XML_TRUE; < 2957,2958c2930,2931 < if (prefix->name < && prefix->name[0] == XML_T('x') --- > for (len = 0; uri[len]; len++) > ; 2959,2989d2931 < && prefix->name[1] == XML_T('m') < && prefix->name[2] == XML_T('l')) { < < /* Not allowed to bind xmlns */ < if (prefix->name[3] == XML_T('n') < && prefix->name[4] == XML_T('s') < && prefix->name[5] == XML_T('\0')) < return XML_ERROR_RESERVED_PREFIX_XMLNS; < < if (prefix->name[3] == XML_T('\0')) < mustBeXML = XML_TRUE; < } < < for (len = 0; uri[len]; len++) { < if (isXML && (len > xmlLen || uri[len] != xmlNamespace [len])) < isXML = XML_FALSE; < < if (!mustBeXML && isXMLNS < && (len > xmlnsLen || uri[len] != xmlnsNamespace [len])) < isXMLNS = XML_FALSE; < } < isXML = isXML && len == xmlLen; < isXMLNS = isXMLNS && len == xmlnsLen; < < if (mustBeXML != isXML) < return mustBeXML ? XML_ERROR_RESERVED_PREFIX_XML < : XML_ERROR_RESERVED_NAMESPACE_URI; < < if (isXMLNS) < return XML_ERROR_RESERVED_NAMESPACE_URI; < 5347c5289 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) 5373c5315 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) Should I try simply replacing xmlparse.c with the one from CVS in my distro? Thanks, --Scott ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 13:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Tue Jan 4 22:39:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 4 22:39:38 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 09:24 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&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 on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 13:39 Message: Logged In: NO ./configure comes up fine, so I am not sure why make fails. checking for an ANSI C-conforming const... yes I am using GCC, and the above line from the ./config output *seems* to indicate that it is fine in ANSI compatibility mode, but not sure how to force ANSI compatibility. I don't see anything in the docs... I need to get this running to compile it in with PHP, anybody done this on Solaris 9 before? Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 11:54 Message: Logged In: YES user_id=290026 The changes seem to be just the ones made since 1.95.8, so your version looks OK. Which compiler are you using? Is it in ANSI compatibility mode? I am not the build expert here, so if you find a solution, please let me know. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 11:49 Message: Logged In: NO Hmmmm... The one in CVS and the one that came with the package I downloaded from sourceforge (expat-1.95.8.tar.gz) are radically different. It isn't clear to me which version of this file exists in the package I got here at SF, but I compared it to 1.143, and they aren't the same. Here is a copy of my UNIX diff file: 1444c1444 < to detect errors based on that fact. --- > to detect errors based on this information. 1497a1498 > positionPtr = end; 1519a1521,1522 > bufferPtr = buffer; > bufferEnd = buffer + nLeftOver; 1521,1526d1523 < bufferPtr = buffer; < bufferEnd = buffer + nLeftOver; < positionPtr = bufferPtr; < parseEndPtr = bufferEnd; < eventPtr = bufferPtr; < eventEndPtr = bufferPtr; 1545c1542 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1704c1701 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1842c1839 < static const XML_LChar* const message[] = { --- > static const XML_LChar *message[] = { 1860c1857 < XML_L("XML or text declaration not at start of entity"), --- > XML_L("xml declaration not at start of external entity"), 1880c1877 < XML_L("cannot suspend in external parameter entity"), --- > XML_L("cannot suspend in external parameter entity") 1881,1883d1877 < XML_L("reserved prefix (xml) must not be undeclared or bound to another namespace name"), < XML_L("reserved prefix (xmlns) must not be declared or undeclared"), < XML_L("prefix must not be bound to one of the reserved namespace names") 1925,1927c1919,1921 < static const XML_Feature features[] = { < {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), < sizeof(XML_Char)}, --- > static XML_Feature features[] = { > {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), 0}, > {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), 0}, 1928,1929d1921 < {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), < sizeof(XML_LChar)}, 1948a1941,1942 > features[0].value = sizeof(XML_Char); > features[1].value = sizeof(XML_LChar); 2831c2825 < j < step ? (j += nsAttsSize - step) : (j -= step); --- > j < step ? ( j += nsAttsSize - step) : (j -= step); 2888c2882 < ; /* prefixLen includes null terminator */ --- > ; 2895c2889 < ; /* i includes null terminator */ --- > ; 2910d2903 < /* if namespaceSeparator != '\0' then uri includes it already */ 2913d2905 < /* we always have a namespace separator between localPart and prefix */ 2915,2916c2907,2908 < uri += i - 1; < *uri = namespaceSeparator; /* replace null terminator */ --- > uri = uri + (i - 1); > if (namespaceSeparator) 2916a2909 > *uri = namespaceSeparator; 2930,2949d2922 < static const XML_Char xmlNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', < 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' < }; < static const int xmlLen = < (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; < static const XML_Char xmlnsNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' < }; < static const int xmlnsLen = < (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; < < XML_Bool mustBeXML = XML_FALSE; < XML_Bool isXML = XML_TRUE; < XML_Bool isXMLNS = XML_TRUE; < 2957,2958c2930,2931 < if (prefix->name < && prefix->name[0] == XML_T('x') --- > for (len = 0; uri[len]; len++) > ; 2959,2989d2931 < && prefix->name[1] == XML_T('m') < && prefix->name[2] == XML_T('l')) { < < /* Not allowed to bind xmlns */ < if (prefix->name[3] == XML_T('n') < && prefix->name[4] == XML_T('s') < && prefix->name[5] == XML_T('\0')) < return XML_ERROR_RESERVED_PREFIX_XMLNS; < < if (prefix->name[3] == XML_T('\0')) < mustBeXML = XML_TRUE; < } < < for (len = 0; uri[len]; len++) { < if (isXML && (len > xmlLen || uri[len] != xmlNamespace [len])) < isXML = XML_FALSE; < < if (!mustBeXML && isXMLNS < && (len > xmlnsLen || uri[len] != xmlnsNamespace [len])) < isXMLNS = XML_FALSE; < } < isXML = isXML && len == xmlLen; < isXMLNS = isXMLNS && len == xmlnsLen; < < if (mustBeXML != isXML) < return mustBeXML ? XML_ERROR_RESERVED_PREFIX_XML < : XML_ERROR_RESERVED_NAMESPACE_URI; < < if (isXMLNS) < return XML_ERROR_RESERVED_NAMESPACE_URI; < 5347c5289 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) 5373c5315 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) Should I try simply replacing xmlparse.c with the one from CVS in my distro? Thanks, --Scott ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 10:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Wed Jan 5 19:36:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 19:36:07 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 09:24 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&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 on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-05 10:36 Message: Logged In: NO Anybody? I could sure use some help here! Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 13:39 Message: Logged In: NO ./configure comes up fine, so I am not sure why make fails. checking for an ANSI C-conforming const... yes I am using GCC, and the above line from the ./config output *seems* to indicate that it is fine in ANSI compatibility mode, but not sure how to force ANSI compatibility. I don't see anything in the docs... I need to get this running to compile it in with PHP, anybody done this on Solaris 9 before? Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 11:54 Message: Logged In: YES user_id=290026 The changes seem to be just the ones made since 1.95.8, so your version looks OK. Which compiler are you using? Is it in ANSI compatibility mode? I am not the build expert here, so if you find a solution, please let me know. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 11:49 Message: Logged In: NO Hmmmm... The one in CVS and the one that came with the package I downloaded from sourceforge (expat-1.95.8.tar.gz) are radically different. It isn't clear to me which version of this file exists in the package I got here at SF, but I compared it to 1.143, and they aren't the same. Here is a copy of my UNIX diff file: 1444c1444 < to detect errors based on that fact. --- > to detect errors based on this information. 1497a1498 > positionPtr = end; 1519a1521,1522 > bufferPtr = buffer; > bufferEnd = buffer + nLeftOver; 1521,1526d1523 < bufferPtr = buffer; < bufferEnd = buffer + nLeftOver; < positionPtr = bufferPtr; < parseEndPtr = bufferEnd; < eventPtr = bufferPtr; < eventEndPtr = bufferPtr; 1545c1542 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1704c1701 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1842c1839 < static const XML_LChar* const message[] = { --- > static const XML_LChar *message[] = { 1860c1857 < XML_L("XML or text declaration not at start of entity"), --- > XML_L("xml declaration not at start of external entity"), 1880c1877 < XML_L("cannot suspend in external parameter entity"), --- > XML_L("cannot suspend in external parameter entity") 1881,1883d1877 < XML_L("reserved prefix (xml) must not be undeclared or bound to another namespace name"), < XML_L("reserved prefix (xmlns) must not be declared or undeclared"), < XML_L("prefix must not be bound to one of the reserved namespace names") 1925,1927c1919,1921 < static const XML_Feature features[] = { < {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), < sizeof(XML_Char)}, --- > static XML_Feature features[] = { > {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), 0}, > {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), 0}, 1928,1929d1921 < {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), < sizeof(XML_LChar)}, 1948a1941,1942 > features[0].value = sizeof(XML_Char); > features[1].value = sizeof(XML_LChar); 2831c2825 < j < step ? (j += nsAttsSize - step) : (j -= step); --- > j < step ? ( j += nsAttsSize - step) : (j -= step); 2888c2882 < ; /* prefixLen includes null terminator */ --- > ; 2895c2889 < ; /* i includes null terminator */ --- > ; 2910d2903 < /* if namespaceSeparator != '\0' then uri includes it already */ 2913d2905 < /* we always have a namespace separator between localPart and prefix */ 2915,2916c2907,2908 < uri += i - 1; < *uri = namespaceSeparator; /* replace null terminator */ --- > uri = uri + (i - 1); > if (namespaceSeparator) 2916a2909 > *uri = namespaceSeparator; 2930,2949d2922 < static const XML_Char xmlNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', < 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' < }; < static const int xmlLen = < (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; < static const XML_Char xmlnsNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' < }; < static const int xmlnsLen = < (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; < < XML_Bool mustBeXML = XML_FALSE; < XML_Bool isXML = XML_TRUE; < XML_Bool isXMLNS = XML_TRUE; < 2957,2958c2930,2931 < if (prefix->name < && prefix->name[0] == XML_T('x') --- > for (len = 0; uri[len]; len++) > ; 2959,2989d2931 < && prefix->name[1] == XML_T('m') < && prefix->name[2] == XML_T('l')) { < < /* Not allowed to bind xmlns */ < if (prefix->name[3] == XML_T('n') < && prefix->name[4] == XML_T('s') < && prefix->name[5] == XML_T('\0')) < return XML_ERROR_RESERVED_PREFIX_XMLNS; < < if (prefix->name[3] == XML_T('\0')) < mustBeXML = XML_TRUE; < } < < for (len = 0; uri[len]; len++) { < if (isXML && (len > xmlLen || uri[len] != xmlNamespace [len])) < isXML = XML_FALSE; < < if (!mustBeXML && isXMLNS < && (len > xmlnsLen || uri[len] != xmlnsNamespace [len])) < isXMLNS = XML_FALSE; < } < isXML = isXML && len == xmlLen; < isXMLNS = isXMLNS && len == xmlnsLen; < < if (mustBeXML != isXML) < return mustBeXML ? XML_ERROR_RESERVED_PREFIX_XML < : XML_ERROR_RESERVED_NAMESPACE_URI; < < if (isXMLNS) < return XML_ERROR_RESERVED_NAMESPACE_URI; < 5347c5289 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) 5373c5315 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) Should I try simply replacing xmlparse.c with the one from CVS in my distro? Thanks, --Scott ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 10:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Wed Jan 5 19:47:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 19:47:18 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 12:24 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make fails on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-05 13:47 Message: Logged In: YES user_id=290026 I don't have Solaris available. Have you tried playing around with the source to find out exactly what the compiler doesn't like? It seems this line: lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) should not be reported, as 'pool' is most certainly declared. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-05 13:36 Message: Logged In: NO Anybody? I could sure use some help here! Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 16:39 Message: Logged In: NO ./configure comes up fine, so I am not sure why make fails. checking for an ANSI C-conforming const... yes I am using GCC, and the above line from the ./config output *seems* to indicate that it is fine in ANSI compatibility mode, but not sure how to force ANSI compatibility. I don't see anything in the docs... I need to get this running to compile it in with PHP, anybody done this on Solaris 9 before? Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 14:54 Message: Logged In: YES user_id=290026 The changes seem to be just the ones made since 1.95.8, so your version looks OK. Which compiler are you using? Is it in ANSI compatibility mode? I am not the build expert here, so if you find a solution, please let me know. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 14:49 Message: Logged In: NO Hmmmm... The one in CVS and the one that came with the package I downloaded from sourceforge (expat-1.95.8.tar.gz) are radically different. It isn't clear to me which version of this file exists in the package I got here at SF, but I compared it to 1.143, and they aren't the same. Here is a copy of my UNIX diff file: 1444c1444 < to detect errors based on that fact. --- > to detect errors based on this information. 1497a1498 > positionPtr = end; 1519a1521,1522 > bufferPtr = buffer; > bufferEnd = buffer + nLeftOver; 1521,1526d1523 < bufferPtr = buffer; < bufferEnd = buffer + nLeftOver; < positionPtr = bufferPtr; < parseEndPtr = bufferEnd; < eventPtr = bufferPtr; < eventEndPtr = bufferPtr; 1545c1542 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1704c1701 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1842c1839 < static const XML_LChar* const message[] = { --- > static const XML_LChar *message[] = { 1860c1857 < XML_L("XML or text declaration not at start of entity"), --- > XML_L("xml declaration not at start of external entity"), 1880c1877 < XML_L("cannot suspend in external parameter entity"), --- > XML_L("cannot suspend in external parameter entity") 1881,1883d1877 < XML_L("reserved prefix (xml) must not be undeclared or bound to another namespace name"), < XML_L("reserved prefix (xmlns) must not be declared or undeclared"), < XML_L("prefix must not be bound to one of the reserved namespace names") 1925,1927c1919,1921 < static const XML_Feature features[] = { < {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), < sizeof(XML_Char)}, --- > static XML_Feature features[] = { > {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), 0}, > {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), 0}, 1928,1929d1921 < {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), < sizeof(XML_LChar)}, 1948a1941,1942 > features[0].value = sizeof(XML_Char); > features[1].value = sizeof(XML_LChar); 2831c2825 < j < step ? (j += nsAttsSize - step) : (j -= step); --- > j < step ? ( j += nsAttsSize - step) : (j -= step); 2888c2882 < ; /* prefixLen includes null terminator */ --- > ; 2895c2889 < ; /* i includes null terminator */ --- > ; 2910d2903 < /* if namespaceSeparator != '\0' then uri includes it already */ 2913d2905 < /* we always have a namespace separator between localPart and prefix */ 2915,2916c2907,2908 < uri += i - 1; < *uri = namespaceSeparator; /* replace null terminator */ --- > uri = uri + (i - 1); > if (namespaceSeparator) 2916a2909 > *uri = namespaceSeparator; 2930,2949d2922 < static const XML_Char xmlNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', < 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' < }; < static const int xmlLen = < (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; < static const XML_Char xmlnsNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' < }; < static const int xmlnsLen = < (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; < < XML_Bool mustBeXML = XML_FALSE; < XML_Bool isXML = XML_TRUE; < XML_Bool isXMLNS = XML_TRUE; < 2957,2958c2930,2931 < if (prefix->name < && prefix->name[0] == XML_T('x') --- > for (len = 0; uri[len]; len++) > ; 2959,2989d2931 < && prefix->name[1] == XML_T('m') < && prefix->name[2] == XML_T('l')) { < < /* Not allowed to bind xmlns */ < if (prefix->name[3] == XML_T('n') < && prefix->name[4] == XML_T('s') < && prefix->name[5] == XML_T('\0')) < return XML_ERROR_RESERVED_PREFIX_XMLNS; < < if (prefix->name[3] == XML_T('\0')) < mustBeXML = XML_TRUE; < } < < for (len = 0; uri[len]; len++) { < if (isXML && (len > xmlLen || uri[len] != xmlNamespace [len])) < isXML = XML_FALSE; < < if (!mustBeXML && isXMLNS < && (len > xmlnsLen || uri[len] != xmlnsNamespace [len])) < isXMLNS = XML_FALSE; < } < isXML = isXML && len == xmlLen; < isXMLNS = isXMLNS && len == xmlnsLen; < < if (mustBeXML != isXML) < return mustBeXML ? XML_ERROR_RESERVED_PREFIX_XML < : XML_ERROR_RESERVED_NAMESPACE_URI; < < if (isXMLNS) < return XML_ERROR_RESERVED_NAMESPACE_URI; < 5347c5289 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) 5373c5315 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) Should I try simply replacing xmlparse.c with the one from CVS in my distro? Thanks, --Scott ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 13:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Wed Jan 5 20:03:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 5 20:03:22 2005 Subject: [Expat-bugs] [ expat-Bugs-1095888 ] make fails on Solaris 9 - expat 1.95.8 Message-ID: Bugs item #1095888, was opened at 2005-01-04 09:24 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make fails on Solaris 9 - expat 1.95.8 Initial Comment: When executing the following: PATH=/usr/ccs/bin:$PATH make I receive the following output: /bin/bash ./libtool --silent --mode=compile gcc -g -O2 - Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c lib/xmlparse.c: In function `storeAttributeValue': lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) lib/xmlparse.c:4713: error: (Each undeclared identifier is reported only once lib/xmlparse.c:4713: error: for each function it appears in.) lib/xmlparse.c:4718: warning: left-hand operand of comma expression has no effect *** Error code 1 make: Fatal error: Command failed for target `lib/xmlparse.lo' E-Mail: HS.Brown@smius.com ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-05 11:03 Message: Logged In: NO Well, not being a C programmer, I don't know what to look for... I do see that pool is declared (I think), but I have no explanation for the errors; I just want it to compile. I need to compile PHP to support Horde and IMP. This is a dependency/prereq for compiling PHP with XML support. I wish I could puzzle it out, but I haven't a clue what I am looking at, sadly. Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-05 10:47 Message: Logged In: YES user_id=290026 I don't have Solaris available. Have you tried playing around with the source to find out exactly what the compiler doesn't like? It seems this line: lib/xmlparse.c:4713: error: `pool' undeclared (first use in this function) should not be reported, as 'pool' is most certainly declared. Karl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-05 10:36 Message: Logged In: NO Anybody? I could sure use some help here! Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 13:39 Message: Logged In: NO ./configure comes up fine, so I am not sure why make fails. checking for an ANSI C-conforming const... yes I am using GCC, and the above line from the ./config output *seems* to indicate that it is fine in ANSI compatibility mode, but not sure how to force ANSI compatibility. I don't see anything in the docs... I need to get this running to compile it in with PHP, anybody done this on Solaris 9 before? Thanks, --H. Scott Brown ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 11:54 Message: Logged In: YES user_id=290026 The changes seem to be just the ones made since 1.95.8, so your version looks OK. Which compiler are you using? Is it in ANSI compatibility mode? I am not the build expert here, so if you find a solution, please let me know. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-04 11:49 Message: Logged In: NO Hmmmm... The one in CVS and the one that came with the package I downloaded from sourceforge (expat-1.95.8.tar.gz) are radically different. It isn't clear to me which version of this file exists in the package I got here at SF, but I compared it to 1.143, and they aren't the same. Here is a copy of my UNIX diff file: 1444c1444 < to detect errors based on that fact. --- > to detect errors based on this information. 1497a1498 > positionPtr = end; 1519a1521,1522 > bufferPtr = buffer; > bufferEnd = buffer + nLeftOver; 1521,1526d1523 < bufferPtr = buffer; < bufferEnd = buffer + nLeftOver; < positionPtr = bufferPtr; < parseEndPtr = bufferEnd; < eventPtr = bufferPtr; < eventEndPtr = bufferPtr; 1545c1542 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1704c1701 < enum XML_Status result = XML_STATUS_OK; --- > enum XML_Error result = XML_STATUS_OK; 1842c1839 < static const XML_LChar* const message[] = { --- > static const XML_LChar *message[] = { 1860c1857 < XML_L("XML or text declaration not at start of entity"), --- > XML_L("xml declaration not at start of external entity"), 1880c1877 < XML_L("cannot suspend in external parameter entity"), --- > XML_L("cannot suspend in external parameter entity") 1881,1883d1877 < XML_L("reserved prefix (xml) must not be undeclared or bound to another namespace name"), < XML_L("reserved prefix (xmlns) must not be declared or undeclared"), < XML_L("prefix must not be bound to one of the reserved namespace names") 1925,1927c1919,1921 < static const XML_Feature features[] = { < {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), < sizeof(XML_Char)}, --- > static XML_Feature features[] = { > {XML_FEATURE_SIZEOF_XML_CHAR, XML_L("sizeof (XML_Char)"), 0}, > {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), 0}, 1928,1929d1921 < {XML_FEATURE_SIZEOF_XML_LCHAR, XML_L("sizeof (XML_LChar)"), < sizeof(XML_LChar)}, 1948a1941,1942 > features[0].value = sizeof(XML_Char); > features[1].value = sizeof(XML_LChar); 2831c2825 < j < step ? (j += nsAttsSize - step) : (j -= step); --- > j < step ? ( j += nsAttsSize - step) : (j -= step); 2888c2882 < ; /* prefixLen includes null terminator */ --- > ; 2895c2889 < ; /* i includes null terminator */ --- > ; 2910d2903 < /* if namespaceSeparator != '\0' then uri includes it already */ 2913d2905 < /* we always have a namespace separator between localPart and prefix */ 2915,2916c2907,2908 < uri += i - 1; < *uri = namespaceSeparator; /* replace null terminator */ --- > uri = uri + (i - 1); > if (namespaceSeparator) 2916a2909 > *uri = namespaceSeparator; 2930,2949d2922 < static const XML_Char xmlNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < 'X', 'M', 'L', '/', '1', '9', '9', '8', '/', < 'n', 'a', 'm', 'e', 's', 'p', 'a', 'c', 'e', '\0' < }; < static const int xmlLen = < (int)sizeof(xmlNamespace)/sizeof(XML_Char) - 1; < static const XML_Char xmlnsNamespace[] = { < 'h', 't', 't', 'p', ':', '/', '/', < 'w', 'w', 'w', '.', 'w', '3', '.', 'o', 'r', 'g', '/', < '2', '0', '0', '0', '/', 'x', 'm', 'l', 'n', 's', '/', '\0' < }; < static const int xmlnsLen = < (int)sizeof(xmlnsNamespace)/sizeof(XML_Char) - 1; < < XML_Bool mustBeXML = XML_FALSE; < XML_Bool isXML = XML_TRUE; < XML_Bool isXMLNS = XML_TRUE; < 2957,2958c2930,2931 < if (prefix->name < && prefix->name[0] == XML_T('x') --- > for (len = 0; uri[len]; len++) > ; 2959,2989d2931 < && prefix->name[1] == XML_T('m') < && prefix->name[2] == XML_T('l')) { < < /* Not allowed to bind xmlns */ < if (prefix->name[3] == XML_T('n') < && prefix->name[4] == XML_T('s') < && prefix->name[5] == XML_T('\0')) < return XML_ERROR_RESERVED_PREFIX_XMLNS; < < if (prefix->name[3] == XML_T('\0')) < mustBeXML = XML_TRUE; < } < < for (len = 0; uri[len]; len++) { < if (isXML && (len > xmlLen || uri[len] != xmlNamespace [len])) < isXML = XML_FALSE; < < if (!mustBeXML && isXMLNS < && (len > xmlnsLen || uri[len] != xmlnsNamespace [len])) < isXMLNS = XML_FALSE; < } < isXML = isXML && len == xmlLen; < isXMLNS = isXMLNS && len == xmlnsLen; < < if (mustBeXML != isXML) < return mustBeXML ? XML_ERROR_RESERVED_PREFIX_XML < : XML_ERROR_RESERVED_NAMESPACE_URI; < < if (isXMLNS) < return XML_ERROR_RESERVED_NAMESPACE_URI; < 5347c5289 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) 5373c5315 < if (namespaceSeparator) --- > if (namespaceSeparator != XML_T('\0')) Should I try simply replacing xmlparse.c with the one from CVS in my distro? Thanks, --Scott ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-04 10:19 Message: Logged In: YES user_id=290026 Your line numbers seem off. Are you using the correct xmlparse.c? Compare it with CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 From noreply at sourceforge.net Wed Jan 19 10:45:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 19 10:45:48 2005 Subject: [Expat-bugs] [ expat-Bugs-1105135 ] Win64 portability warnings Message-ID: Bugs item #1105135, was opened at 2005-01-19 10:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Henrik Goldman (hgoldman) Assigned to: Nobody/Anonymous (nobody) Summary: Win64 portability warnings Initial Comment: I am trying to get my software ready for Win64 (AMD64 / IA64). Currently I'm using Visual Studio .NET 2003 with /Wp64 switch enabled. However theres some missing typecasts in expat to make it compile clean. Instead of waiting for someone to fix it I can probably do it myself but I'm only willing to if my changes will be considered for next release. I'm rather sure all the warnings will go away with apropriate typecasts. Please advise me how to continue. I'm using the downloaded version of expat 1.95.8: c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1604) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1606) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1615) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1628) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1642) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1761) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1770) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1771) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2318) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2323) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2511) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2516) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2541) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2550) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3067) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3076) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3938) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(4623) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(4669) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(5130) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(5135) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(6017) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(6031) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127 From noreply at sourceforge.net Tue Jan 25 15:46:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 15:46:37 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 06:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Tue Jan 25 16:20:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 16:21:00 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Tue Jan 25 17:27:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 17:27:20 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Tue Jan 25 17:48:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 17:48:34 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Tue Jan 25 18:21:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 18:21:39 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Tue Jan 25 19:02:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 25 19:02:48 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Wed Jan 26 07:52:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 26 07:52:51 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Thu Jan 27 04:08:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 04:08:40 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-26 22:08 Message: Logged In: YES user_id=290026 Your last suggestion seems reasonable. What about this - let's wait until after Expat 2.0, as the subsequent releases won't be backwards compatible anyway. Then we can simply add the "aspects" parameter to the existing XML_ParserReset() function without having to worry about compatibility. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Thu Jan 27 05:06:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 05:06:22 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:06 Message: Logged In: YES user_id=3066 Either adding it now or after works for me, but after probably makes more sense given that we're trying to wrap up a stable 2.0. My own suspicion is that the cost of re-initializing a parser should be thought of as two separate parts: re-initializing the parse state within Expat, and re-initializing the user-provided information (callbacks and user-data). The parse state involves a whole pile of memory structures that the user has no direct access to (or control over the cost of re-initialization), and the user-provided information is most a collection of pointers for which the initialization cost is dominated by the function call overhead. This leads me to think that there's no substantial performance benefit in this for most applications, but there may be substantial benefit for apps running on embedded processors. It would be interesting to know if Sebastian's application is running in an embedded environment, and if not, what the motivation for the original question might be. If the motivation is not efficiency but convenience, then it can certainly wait for Expat 3. FTR, the original post that generated this tracker issue can be found in the expat-discuss mailing list archives: http://mail.libexpat.org/pipermail/expat-discuss/2005-January/001726.html ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-26 22:08 Message: Logged In: YES user_id=290026 Your last suggestion seems reasonable. What about this - let's wait until after Expat 2.0, as the subsequent releases won't be backwards compatible anyway. Then we can simply add the "aspects" parameter to the existing XML_ParserReset() function without having to worry about compatibility. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Thu Jan 27 05:53:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 05:53:16 2005 Subject: [Expat-bugs] [ expat-Bugs-1063934 ] building expat-1.95.8 for win32 with mingw Message-ID: Bugs item #1063934, was opened at 2004-11-10 11:35 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1063934&group_id=10127 Category: Build control Group: Third-party Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: building expat-1.95.8 for win32 with mingw Initial Comment: Hi! I'm compiling expat-1.95.8 for win32 with mingw in an cygwin-enviroment. During buildprocess i get following error: /bin/bash ./libtool --silent --mode=link g++-mingw -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -no-undefined -version-info 5:0:5 -rpath /wamas/test/erudig/WX/cygwin_win32/lib -Wl,--export-all,--kill-at -o libxmiexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/bin/ld: warning: cannot find entry symbol _DllMainCRTStartup@12; defaulting to 00401000 /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `_WinMain@16' collect2: ld returned 1 exit status make: *** [libxmiexpat.la] Error 1 I suppose the libtool-script which is generated during configure is libtool-1.4.x. In this scipt they excluded some dll-entrypoints for cygwin and mingw. I replaced this script with the script of libtool-1.5.10 and all worked fine. So can you please replace the configure-scipt with an scipt which is generated with libtool-1.5 or higher. sincerely Elmar Rudigier ps: g++-mingw is is only a scipt which calls g++ whith the flag -mno-cygwin to exclude cygwin.dll during linking. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:53 Message: Logged In: YES user_id=3066 Using libtool 1.5.10 seems to work on my system (FC1), so I'll plan on using that for the next release. Assigning to me, since the version of libtool that gets used seems to be a matter of what's installed on the machine used to build the distribution. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-11-26 05:29 Message: Logged In: NO Please check http://sourceforge.net/tracker/index.php?func=detail&aid=1073661&group_id=10127&atid=110127 I think it is solved ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1063934&group_id=10127 From noreply at sourceforge.net Thu Jan 27 05:54:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 05:54:42 2005 Subject: [Expat-bugs] [ expat-Bugs-1075079 ] errors in building expat 1.95.2 on Solaris 2.9 Message-ID: Bugs item #1075079, was opened at 2004-11-29 03:47 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1075079&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: errors in building expat 1.95.2 on Solaris 2.9 Initial Comment: When I build expat 1.95.2 on Solaris 2.9 Under the directory of expat.1.95.2 # ./configure configure error: no acceptable cc found in $PATH Then I type the command according to the README file # PATH=/usr/ccs/bin:$PATH make make: FATAL error: no arguments to build. What kind of arguments is needed here? I am not familar with Solaris System. I need help to fix the error urgently. Thanks a lot Sherley ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:54 Message: Logged In: YES user_id=3066 Closing as out-of-date, since 1.95.2 is no longer supported. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-11-29 09:06 Message: Logged In: YES user_id=290026 Expat 1.95.2 is not really supported anymore. Why don't you use 1.95.8, or even better, the CVS version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1075079&group_id=10127 From noreply at sourceforge.net Thu Jan 27 06:23:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 06:23:08 2005 Subject: [Expat-bugs] [ expat-Bugs-1021776 ] Recursion in macro "parsing", HP 11.0 Message-ID: Bugs item #1021776, was opened at 2004-09-03 08:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion in macro "parsing", HP 11.0 Initial Comment: uname -a HP-UX hprgs B.11.00 U 9000/800 76745 unlimited-user license ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... cat: Cannot open conftest. c: No such file or directory no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h hprgs:#/varios/perl/expat-1.95.8> ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h make /bin/sh ./libtool --silent --mode=compile /usr/ccs/ bin/cc -g -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/ xmlparse.lo -c lib/xmlparse.c (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: "lib/xmlparse.c", line 855: error 4065: Recursion in macro "parsing". *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:23 Message: Logged In: YES user_id=3066 While this seems rather clearly to be a compiler problem, we can deal with this by renaming the "parsing" macro; that won't be a problem for the API (since the macro is strictly internal) nor will it be a problem for compliant compilers. I've attached a patch. If someone who can reproduce the problem can test the patch on an affected version of HP-UX, that would be quite helpful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 11:12 Message: Logged In: YES user_id=290026 I had a further look at the source and found these macros #define parsing (parser->m_parsingStatus.parsing) #define finalBuffer (parser->m_parsingStatus.finalBuffer) as the likely source of your problems. AFAIK, if a macro refers to itself, then the C preprocessor must not expand the reference, so it looks as if your compiler breaks that rule. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 09:29 Message: Logged In: YES user_id=290026 Must be a platform issue, but I have no expertise in it. However, we may get a build expert on board, and then I'll assign this issue to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-21 08:49 Message: Logged In: NO I have the same problem?? Steen.brandtmar@ementor.dk ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 04:55 Message: Logged In: NO I have the same issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 From noreply at sourceforge.net Thu Jan 27 06:44:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 06:44:05 2005 Subject: [Expat-bugs] [ expat-Bugs-1023646 ] Error in codepageMap, codepage.c Message-ID: Bugs item #1023646, was opened at 2004-09-07 08:39 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error in codepageMap, codepage.c Initial Comment: Applies to expat v.1.95.8 >From MS: "LeadByte: Specifies a fixed-length array of lead-byte ranges, where the number of lead-byte ranges is variable. If there are no lead bytes in this code page, then every element of the array is NULL. If there are lead bytes in this code page, a starting value and ending value is specified for each range. Ranges are inclusive. The maximum number of lead-byte ranges for any code page is five. The array uses two bytes to describe each range, with a double-byte null terminator after the last range." Note that "Ranges are inclusive". Therefore the function codepageMap should be changed: for (i = 0; i < MAX_LEADBYTES; i+=2) { int j, lim; if (info.LeadByte[i] == 0 && info.LeadByte[i + 1] == 0) break; lim = info.LeadByte[i + 1]; for (j = info.LeadByte[i]; j <= lim; j++) map[j] = -2; } Regards, Ole Stauning, spam@uning.dk ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:44 Message: Logged In: YES user_id=3066 I'm inclined to agree, having read the CPINFO documentation. Do you have a test case that breaks using the current code, and which your proposed change would fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 From noreply at sourceforge.net Thu Jan 27 06:46:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 06:46:27 2005 Subject: [Expat-bugs] [ expat-Bugs-1105135 ] Win64 portability warnings Message-ID: Bugs item #1105135, was opened at 2005-01-19 04:45 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Henrik Goldman (hgoldman) Assigned to: Nobody/Anonymous (nobody) Summary: Win64 portability warnings Initial Comment: I am trying to get my software ready for Win64 (AMD64 / IA64). Currently I'm using Visual Studio .NET 2003 with /Wp64 switch enabled. However theres some missing typecasts in expat to make it compile clean. Instead of waiting for someone to fix it I can probably do it myself but I'm only willing to if my changes will be considered for next release. I'm rather sure all the warnings will go away with apropriate typecasts. Please advise me how to continue. I'm using the downloaded version of expat 1.95.8: c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1604) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1606) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1615) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1628) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1642) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1761) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1770) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1771) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2318) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2323) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2511) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2516) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2541) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2550) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3067) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3076) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3938) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(4623) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(4669) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(5130) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(5135) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(6017) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(6031) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:46 Message: Logged In: YES user_id=3066 We'll certainly consider patches. The best way to proceed would be to attach a patch to this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127 From noreply at sourceforge.net Thu Jan 27 06:50:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 06:50:59 2005 Subject: [Expat-bugs] [ expat-Bugs-863550 ] Update to libtool 1.5 Message-ID: Bugs item #863550, was opened at 2003-12-20 10:05 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=863550&group_id=10127 Category: Build control Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Update to libtool 1.5 Initial Comment: Please update the libtool included with expat to version 1.5 (stable). It makes building on platforms such as Cygwin easier, as well as easing integration when combining expat with other modern projects. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:50 Message: Logged In: YES user_id=3066 I'm planning to construct the next release using libtool 1.5.10, so this problem should be solved with Expat 1.95.9. ---------------------------------------------------------------------- Comment By: Christian Ehrlicher (chehrlic) Date: 2004-01-15 11:15 Message: Logged In: YES user_id=798735 Is the old libtool also responsible for this output when I want to link against libexpat? libtool: link: warning: `/usr/lib/libexpat.la' seems to be moved I've build from src.rpm. And now in /usr/lib/libexpat.la the libdir-path is /var/tmp/expat-buildroot/usr/lib which causes this error. It would be fine if this would go away with the 'new' libtool ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-01-07 10:28 Message: Logged In: YES user_id=3066 Greg, can you try to get to this soon? I'd like to release a new version of Expat this month. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-01-07 10:24 Message: Logged In: NO bah, i just wasted a day or so because the libtool included in the expat 1.95.7 is too old and does not work on current mingw (i have 3.1.0) it produces unusable libraries, and programs linked against them crash in funny ways (gdb does not give a useful backtrace...) please release a new version with libtool 1.5, that should work a whole lot better (i have 1.4e which seems to be a alpha or beta of 1.5) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-12-20 10:11 Message: Logged In: NO This is easy to do, manually: 1) make distclean 2) Either libtoolize or update config.guess, config.sub, ltmain.sh files within conftools. Manually copy the latest libtool.m4 into conftools. 3) autoheader && autoconf. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=863550&group_id=10127 From noreply at sourceforge.net Thu Jan 27 15:32:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 15:33:00 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:32 Message: Logged In: YES user_id=290026 I totally agree with your conceptual separation between re-initializing internal state and clearing user settings. Changing how the latter behaves is mostly a matter of convenience, I agree as well. IMO, the bulk of applications would benefit from having user settings *not* cleared, but there are others with the opposite requirements. So, I vote for modifying XML_ParserReset() for the first release after 2.0. I also suggest that we define the "aspects" parameter type as a set of bit flags, so that the user can easily combine various options. E.g. (one of several possible mappings): XML_ASPECT_NONE = 0; XML_ASPECT_USERDATA = 1; XML_ASPECT_CONTENTHANDLERS = 2; XML_ASPECT_OTHERHANDLERS = 4; XML_ASPECT_ANYTHINGELSE = 8; etc. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:06 Message: Logged In: YES user_id=3066 Either adding it now or after works for me, but after probably makes more sense given that we're trying to wrap up a stable 2.0. My own suspicion is that the cost of re-initializing a parser should be thought of as two separate parts: re-initializing the parse state within Expat, and re-initializing the user-provided information (callbacks and user-data). The parse state involves a whole pile of memory structures that the user has no direct access to (or control over the cost of re-initialization), and the user-provided information is most a collection of pointers for which the initialization cost is dominated by the function call overhead. This leads me to think that there's no substantial performance benefit in this for most applications, but there may be substantial benefit for apps running on embedded processors. It would be interesting to know if Sebastian's application is running in an embedded environment, and if not, what the motivation for the original question might be. If the motivation is not efficiency but convenience, then it can certainly wait for Expat 3. FTR, the original post that generated this tracker issue can be found in the expat-discuss mailing list archives: http://mail.libexpat.org/pipermail/expat-discuss/2005-January/001726.html ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-26 22:08 Message: Logged In: YES user_id=290026 Your last suggestion seems reasonable. What about this - let's wait until after Expat 2.0, as the subsequent releases won't be backwards compatible anyway. Then we can simply add the "aspects" parameter to the existing XML_ParserReset() function without having to worry about compatibility. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Thu Jan 27 15:37:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 15:37:08 2005 Subject: [Expat-bugs] [ expat-Bugs-1021776 ] Recursion in macro "parsing", HP 11.0 Message-ID: Bugs item #1021776, was opened at 2004-09-03 08:06 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion in macro "parsing", HP 11.0 Initial Comment: uname -a HP-UX hprgs B.11.00 U 9000/800 76745 unlimited-user license ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... cat: Cannot open conftest. c: No such file or directory no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h hprgs:#/varios/perl/expat-1.95.8> ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h make /bin/sh ./libtool --silent --mode=compile /usr/ccs/ bin/cc -g -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/ xmlparse.lo -c lib/xmlparse.c (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: "lib/xmlparse.c", line 855: error 4065: Recursion in macro "parsing". *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:37 Message: Logged In: YES user_id=290026 The only objection I would have is that this breaks the naming convention for these types of macros. But that is not a showstopper for me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:23 Message: Logged In: YES user_id=3066 While this seems rather clearly to be a compiler problem, we can deal with this by renaming the "parsing" macro; that won't be a problem for the API (since the macro is strictly internal) nor will it be a problem for compliant compilers. I've attached a patch. If someone who can reproduce the problem can test the patch on an affected version of HP-UX, that would be quite helpful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 11:12 Message: Logged In: YES user_id=290026 I had a further look at the source and found these macros #define parsing (parser->m_parsingStatus.parsing) #define finalBuffer (parser->m_parsingStatus.finalBuffer) as the likely source of your problems. AFAIK, if a macro refers to itself, then the C preprocessor must not expand the reference, so it looks as if your compiler breaks that rule. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 09:29 Message: Logged In: YES user_id=290026 Must be a platform issue, but I have no expertise in it. However, we may get a build expert on board, and then I'll assign this issue to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-21 08:49 Message: Logged In: NO I have the same problem?? Steen.brandtmar@ementor.dk ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 04:55 Message: Logged In: NO I have the same issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 From noreply at sourceforge.net Thu Jan 27 15:46:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 15:46:36 2005 Subject: [Expat-bugs] [ expat-Bugs-1023646 ] Error in codepageMap, codepage.c Message-ID: Bugs item #1023646, was opened at 2004-09-07 08:39 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error in codepageMap, codepage.c Initial Comment: Applies to expat v.1.95.8 >From MS: "LeadByte: Specifies a fixed-length array of lead-byte ranges, where the number of lead-byte ranges is variable. If there are no lead bytes in this code page, then every element of the array is NULL. If there are lead bytes in this code page, a starting value and ending value is specified for each range. Ranges are inclusive. The maximum number of lead-byte ranges for any code page is five. The array uses two bytes to describe each range, with a double-byte null terminator after the last range." Note that "Ranges are inclusive". Therefore the function codepageMap should be changed: for (i = 0; i < MAX_LEADBYTES; i+=2) { int j, lim; if (info.LeadByte[i] == 0 && info.LeadByte[i + 1] == 0) break; lim = info.LeadByte[i + 1]; for (j = info.LeadByte[i]; j <= lim; j++) map[j] = -2; } Regards, Ole Stauning, spam@uning.dk ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:46 Message: Logged In: YES user_id=290026 FWIW, I agree with the above conclusions as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:44 Message: Logged In: YES user_id=3066 I'm inclined to agree, having read the CPINFO documentation. Do you have a test case that breaks using the current code, and which your proposed change would fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 From noreply at sourceforge.net Thu Jan 27 15:49:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 15:49:19 2005 Subject: [Expat-bugs] [ expat-Bugs-1110770 ] xmlwf canonical output needs update Message-ID: Bugs item #1110770, was opened at 2005-01-27 09:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1110770&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf canonical output needs update Initial Comment: The canonical output generated by xmlwf does not conform to the test outputs provided by the official XML-Test-Suite. This should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1110770&group_id=10127 From noreply at sourceforge.net Thu Jan 27 16:09:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 16:09:21 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:09 Message: Logged In: YES user_id=3066 I'd drop the "anything else" bit, and add XML_ASPECT_ALL = MAX_UINT or something like that. The problem with "anything else" is that it's semantics change (or we need a new "anything else" value) as soon as an additional aspect is introducted. Each bit should correspond to a well-defined bit of state, and that mapping should never change. If some aspect represented by a bit needs to be broken out into separate aspects in the future, the new aspects should receive their own bit, and the original bit should continue to deal with all parts of that aspect. There should also be a define that contains all the known aspects, but nothing else. That can be used to determine if any aspects are indicated which are not known; this should probably be treated as an error by the library, and get reported without making any changes. Sounds like we're agreed on making this an Expat 3 change. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:32 Message: Logged In: YES user_id=290026 I totally agree with your conceptual separation between re-initializing internal state and clearing user settings. Changing how the latter behaves is mostly a matter of convenience, I agree as well. IMO, the bulk of applications would benefit from having user settings *not* cleared, but there are others with the opposite requirements. So, I vote for modifying XML_ParserReset() for the first release after 2.0. I also suggest that we define the "aspects" parameter type as a set of bit flags, so that the user can easily combine various options. E.g. (one of several possible mappings): XML_ASPECT_NONE = 0; XML_ASPECT_USERDATA = 1; XML_ASPECT_CONTENTHANDLERS = 2; XML_ASPECT_OTHERHANDLERS = 4; XML_ASPECT_ANYTHINGELSE = 8; etc. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:06 Message: Logged In: YES user_id=3066 Either adding it now or after works for me, but after probably makes more sense given that we're trying to wrap up a stable 2.0. My own suspicion is that the cost of re-initializing a parser should be thought of as two separate parts: re-initializing the parse state within Expat, and re-initializing the user-provided information (callbacks and user-data). The parse state involves a whole pile of memory structures that the user has no direct access to (or control over the cost of re-initialization), and the user-provided information is most a collection of pointers for which the initialization cost is dominated by the function call overhead. This leads me to think that there's no substantial performance benefit in this for most applications, but there may be substantial benefit for apps running on embedded processors. It would be interesting to know if Sebastian's application is running in an embedded environment, and if not, what the motivation for the original question might be. If the motivation is not efficiency but convenience, then it can certainly wait for Expat 3. FTR, the original post that generated this tracker issue can be found in the expat-discuss mailing list archives: http://mail.libexpat.org/pipermail/expat-discuss/2005-January/001726.html ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-26 22:08 Message: Logged In: YES user_id=290026 Your last suggestion seems reasonable. What about this - let's wait until after Expat 2.0, as the subsequent releases won't be backwards compatible anyway. Then we can simply add the "aspects" parameter to the existing XML_ParserReset() function without having to worry about compatibility. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Thu Jan 27 16:14:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 16:14:47 2005 Subject: [Expat-bugs] [ expat-Bugs-1021776 ] Recursion in macro "parsing", HP 11.0 Message-ID: Bugs item #1021776, was opened at 2004-09-03 08:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion in macro "parsing", HP 11.0 Initial Comment: uname -a HP-UX hprgs B.11.00 U 9000/800 76745 unlimited-user license ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... cat: Cannot open conftest. c: No such file or directory no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h hprgs:#/varios/perl/expat-1.95.8> ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h make /bin/sh ./libtool --silent --mode=compile /usr/ccs/ bin/cc -g -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/ xmlparse.lo -c lib/xmlparse.c (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: "lib/xmlparse.c", line 855: error 4065: Recursion in macro "parsing". *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=3066 Less than ideal because it breaks the convention, but it's also expanding not to a member of the parser but a member of a member of the parser, so it's a little different anyway. After I submitted the patch, I realized that we could see the same problem for "finalBuffer" on the affected platform; if we don't I'll be very surprised actually. The final patch will need to include a comment explaining why the macros are different from the others, and cite this tracker issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:37 Message: Logged In: YES user_id=290026 The only objection I would have is that this breaks the naming convention for these types of macros. But that is not a showstopper for me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:23 Message: Logged In: YES user_id=3066 While this seems rather clearly to be a compiler problem, we can deal with this by renaming the "parsing" macro; that won't be a problem for the API (since the macro is strictly internal) nor will it be a problem for compliant compilers. I've attached a patch. If someone who can reproduce the problem can test the patch on an affected version of HP-UX, that would be quite helpful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 11:12 Message: Logged In: YES user_id=290026 I had a further look at the source and found these macros #define parsing (parser->m_parsingStatus.parsing) #define finalBuffer (parser->m_parsingStatus.finalBuffer) as the likely source of your problems. AFAIK, if a macro refers to itself, then the C preprocessor must not expand the reference, so it looks as if your compiler breaks that rule. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 09:29 Message: Logged In: YES user_id=290026 Must be a platform issue, but I have no expertise in it. However, we may get a build expert on board, and then I'll assign this issue to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-21 08:49 Message: Logged In: NO I have the same problem?? Steen.brandtmar@ementor.dk ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 04:55 Message: Logged In: NO I have the same issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 From noreply at sourceforge.net Thu Jan 27 16:17:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 16:17:43 2005 Subject: [Expat-bugs] [ expat-Bugs-1023646 ] Error in codepageMap, codepage.c Message-ID: Bugs item #1023646, was opened at 2004-09-07 08:39 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 Category: None >Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Error in codepageMap, codepage.c Initial Comment: Applies to expat v.1.95.8 >From MS: "LeadByte: Specifies a fixed-length array of lead-byte ranges, where the number of lead-byte ranges is variable. If there are no lead bytes in this code page, then every element of the array is NULL. If there are lead bytes in this code page, a starting value and ending value is specified for each range. Ranges are inclusive. The maximum number of lead-byte ranges for any code page is five. The array uses two bytes to describe each range, with a double-byte null terminator after the last range." Note that "Ranges are inclusive". Therefore the function codepageMap should be changed: for (i = 0; i < MAX_LEADBYTES; i+=2) { int j, lim; if (info.LeadByte[i] == 0 && info.LeadByte[i + 1] == 0) break; lim = info.LeadByte[i + 1]; for (j = info.LeadByte[i]; j <= lim; j++) map[j] = -2; } Regards, Ole Stauning, spam@uning.dk ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:17 Message: Logged In: YES user_id=3066 Then I think this is ok to commit if everything continues to work for you on Windows. I'll email the original poster since it doesn't look like SF will be sending him updates automatically. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:46 Message: Logged In: YES user_id=290026 FWIW, I agree with the above conclusions as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:44 Message: Logged In: YES user_id=3066 I'm inclined to agree, having read the CPINFO documentation. Do you have a test case that breaks using the current code, and which your proposed change would fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1023646&group_id=10127 From noreply at sourceforge.net Thu Jan 27 16:26:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 16:26:32 2005 Subject: [Expat-bugs] [ expat-Bugs-1109116 ] Optimize implementation of XML_ParserReset Message-ID: Bugs item #1109116, was opened at 2005-01-25 09:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Optimize implementation of XML_ParserReset Initial Comment: The current implementation of XML_ParserReset sets the user data pointer and the handlers to NULL. So, the user has to set these again. At a first glance, there is no need to do things this way. Instead, XML_ParserReset could reset the internal parser data only and leave user data and handlers untouched. So after this function has been called, the parser would be ready to start parsing a new document (just like stated in the documentation of this function). To completely reset the parser, the user would still be able to call XML_ParserFree and XML_ParserCreate. Stefan Letz. stefan.letz de.ibm.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 10:26 Message: Logged In: YES user_id=290026 You are correct about anything else - the example was just for illustration purposes. I think we agree on all aspects here. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:09 Message: Logged In: YES user_id=3066 I'd drop the "anything else" bit, and add XML_ASPECT_ALL = MAX_UINT or something like that. The problem with "anything else" is that it's semantics change (or we need a new "anything else" value) as soon as an additional aspect is introducted. Each bit should correspond to a well-defined bit of state, and that mapping should never change. If some aspect represented by a bit needs to be broken out into separate aspects in the future, the new aspects should receive their own bit, and the original bit should continue to deal with all parts of that aspect. There should also be a define that contains all the known aspects, but nothing else. That can be used to determine if any aspects are indicated which are not known; this should probably be treated as an error by the library, and get reported without making any changes. Sounds like we're agreed on making this an Expat 3 change. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:32 Message: Logged In: YES user_id=290026 I totally agree with your conceptual separation between re-initializing internal state and clearing user settings. Changing how the latter behaves is mostly a matter of convenience, I agree as well. IMO, the bulk of applications would benefit from having user settings *not* cleared, but there are others with the opposite requirements. So, I vote for modifying XML_ParserReset() for the first release after 2.0. I also suggest that we define the "aspects" parameter type as a set of bit flags, so that the user can easily combine various options. E.g. (one of several possible mappings): XML_ASPECT_NONE = 0; XML_ASPECT_USERDATA = 1; XML_ASPECT_CONTENTHANDLERS = 2; XML_ASPECT_OTHERHANDLERS = 4; XML_ASPECT_ANYTHINGELSE = 8; etc. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 23:06 Message: Logged In: YES user_id=3066 Either adding it now or after works for me, but after probably makes more sense given that we're trying to wrap up a stable 2.0. My own suspicion is that the cost of re-initializing a parser should be thought of as two separate parts: re-initializing the parse state within Expat, and re-initializing the user-provided information (callbacks and user-data). The parse state involves a whole pile of memory structures that the user has no direct access to (or control over the cost of re-initialization), and the user-provided information is most a collection of pointers for which the initialization cost is dominated by the function call overhead. This leads me to think that there's no substantial performance benefit in this for most applications, but there may be substantial benefit for apps running on embedded processors. It would be interesting to know if Sebastian's application is running in an embedded environment, and if not, what the motivation for the original question might be. If the motivation is not efficiency but convenience, then it can certainly wait for Expat 3. FTR, the original post that generated this tracker issue can be found in the expat-discuss mailing list archives: http://mail.libexpat.org/pipermail/expat-discuss/2005-January/001726.html ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-26 22:08 Message: Logged In: YES user_id=290026 Your last suggestion seems reasonable. What about this - let's wait until after Expat 2.0, as the subsequent releases won't be backwards compatible anyway. Then we can simply add the "aspects" parameter to the existing XML_ParserReset() function without having to worry about compatibility. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-26 01:52 Message: Logged In: YES user_id=3066 The new function could be XML_ParserResetAspects(parser, aspects), where aspects is a mask of bits defined in the enum. The initial set of aspects could include XML_ASPECT_USERDATA XML_ASPECT_HANDLERS XML_ASPECT_DOCUMENT_CONTEXT I think that covers the aspects that are currently dealt with, but haven't reviewed the current code or the patch. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 13:02 Message: Logged In: YES user_id=290026 Maybe its the new member that could gain an extra argument. This could be an enum, so that we could add more choices later (if ever needed). XML_ParserResetDocument() isn't that clear to me either. What about XML_ParserResetCustom()? Or some name that shows that there are choices? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 12:21 Message: Logged In: YES user_id=3066 Perhaps XML_ParserResetDocument()? "Partial" isn't clear as to the intent. I understand the concern about too many API members. I think a good rule of thumb is that if you have a simple boolean that will (in practice) always be passed a constant value, it makes more sense to use separate entry points. If we expected someone to compute the value (or load from preferences, or whatever), it would make more sense to support it as an argument. The backward compatibility issue would still require a separate entry point in this case, however. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 11:48 Message: Logged In: YES user_id=290026 So, you suggest a new API member, let's call it XML_ParserPartialReset(parser, ...), which would then keep the handlers and certain other settings. I guess this is for backward compatibility, otherwise I would have suggested adding another argument to the call, like "XML_BOOL clearAll", as i don't like adding too many API members. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-25 11:27 Message: Logged In: YES user_id=3066 While I don't expect this change to affect most applications, it may well affect several in unexpected ways that are difficult to debug. For applications which set the handlers and never change them, it's not a problem, and does save some overhead when initializing the reset parser. A different approach to using the handlers, however, is to change the handlers as information is loaded. This is certainly done in at least one language binding (Python's PyExpat) to deal with error conditions; it's also a capability exposed to the user (which I know I've used). I think a new name should be assigned for the new semantics; there's no reason we can't support both. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-25 10:20 Message: Logged In: YES user_id=290026 I have created a patch against current CVS (xmlparse.c). XML_ParseReset will not clear any of the settings caused by these API functions: - all call-back handler setters (XML_Set...Handler) - XML_SetUserData - XML_SetBase - XML_UseParserAshandlerArg - XML_SetExternalEntityRefHandlerArg Please try the patch and report any problems it may cause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1109116&group_id=10127 From noreply at sourceforge.net Thu Jan 27 16:33:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 16:33:35 2005 Subject: [Expat-bugs] [ expat-Bugs-1021776 ] Recursion in macro "parsing", HP 11.0 Message-ID: Bugs item #1021776, was opened at 2004-09-03 08:06 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion in macro "parsing", HP 11.0 Initial Comment: uname -a HP-UX hprgs B.11.00 U 9000/800 76745 unlimited-user license ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... cat: Cannot open conftest. c: No such file or directory no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h hprgs:#/varios/perl/expat-1.95.8> ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h make /bin/sh ./libtool --silent --mode=compile /usr/ccs/ bin/cc -g -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/ xmlparse.lo -c lib/xmlparse.c (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: "lib/xmlparse.c", line 855: error 4065: Recursion in macro "parsing". *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 10:33 Message: Logged In: YES user_id=290026 Yes, finalBuffer needs fixing as well. What about these names: #define ps_parsing (parser->m_parsingStatus.parsing) #define ps_finalBuffer (parser->m_parsingStatus.finalBuffer) to indicate that they refer to members of members? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=3066 Less than ideal because it breaks the convention, but it's also expanding not to a member of the parser but a member of a member of the parser, so it's a little different anyway. After I submitted the patch, I realized that we could see the same problem for "finalBuffer" on the affected platform; if we don't I'll be very surprised actually. The final patch will need to include a comment explaining why the macros are different from the others, and cite this tracker issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:37 Message: Logged In: YES user_id=290026 The only objection I would have is that this breaks the naming convention for these types of macros. But that is not a showstopper for me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:23 Message: Logged In: YES user_id=3066 While this seems rather clearly to be a compiler problem, we can deal with this by renaming the "parsing" macro; that won't be a problem for the API (since the macro is strictly internal) nor will it be a problem for compliant compilers. I've attached a patch. If someone who can reproduce the problem can test the patch on an affected version of HP-UX, that would be quite helpful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 11:12 Message: Logged In: YES user_id=290026 I had a further look at the source and found these macros #define parsing (parser->m_parsingStatus.parsing) #define finalBuffer (parser->m_parsingStatus.finalBuffer) as the likely source of your problems. AFAIK, if a macro refers to itself, then the C preprocessor must not expand the reference, so it looks as if your compiler breaks that rule. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 09:29 Message: Logged In: YES user_id=290026 Must be a platform issue, but I have no expertise in it. However, we may get a build expert on board, and then I'll assign this issue to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-21 08:49 Message: Logged In: NO I have the same problem?? Steen.brandtmar@ementor.dk ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 04:55 Message: Logged In: NO I have the same issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 From noreply at sourceforge.net Thu Jan 27 16:48:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 27 16:48:27 2005 Subject: [Expat-bugs] [ expat-Bugs-1021776 ] Recursion in macro "parsing", HP 11.0 Message-ID: Bugs item #1021776, was opened at 2004-09-03 08:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion in macro "parsing", HP 11.0 Initial Comment: uname -a HP-UX hprgs B.11.00 U 9000/800 76745 unlimited-user license ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... cat: Cannot open conftest. c: No such file or directory no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h hprgs:#/varios/perl/expat-1.95.8> ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h make /bin/sh ./libtool --silent --mode=compile /usr/ccs/ bin/cc -g -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/ xmlparse.lo -c lib/xmlparse.c (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: "lib/xmlparse.c", line 855: error 4065: Recursion in macro "parsing". *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:48 Message: Logged In: YES user_id=3066 I think those names are fine. I'm replacing the patch to match. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 10:33 Message: Logged In: YES user_id=290026 Yes, finalBuffer needs fixing as well. What about these names: #define ps_parsing (parser->m_parsingStatus.parsing) #define ps_finalBuffer (parser->m_parsingStatus.finalBuffer) to indicate that they refer to members of members? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=3066 Less than ideal because it breaks the convention, but it's also expanding not to a member of the parser but a member of a member of the parser, so it's a little different anyway. After I submitted the patch, I realized that we could see the same problem for "finalBuffer" on the affected platform; if we don't I'll be very surprised actually. The final patch will need to include a comment explaining why the macros are different from the others, and cite this tracker issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:37 Message: Logged In: YES user_id=290026 The only objection I would have is that this breaks the naming convention for these types of macros. But that is not a showstopper for me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:23 Message: Logged In: YES user_id=3066 While this seems rather clearly to be a compiler problem, we can deal with this by renaming the "parsing" macro; that won't be a problem for the API (since the macro is strictly internal) nor will it be a problem for compliant compilers. I've attached a patch. If someone who can reproduce the problem can test the patch on an affected version of HP-UX, that would be quite helpful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 11:12 Message: Logged In: YES user_id=290026 I had a further look at the source and found these macros #define parsing (parser->m_parsingStatus.parsing) #define finalBuffer (parser->m_parsingStatus.finalBuffer) as the likely source of your problems. AFAIK, if a macro refers to itself, then the C preprocessor must not expand the reference, so it looks as if your compiler breaks that rule. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 09:29 Message: Logged In: YES user_id=290026 Must be a platform issue, but I have no expertise in it. However, we may get a build expert on board, and then I'll assign this issue to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-21 08:49 Message: Logged In: NO I have the same problem?? Steen.brandtmar@ementor.dk ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 04:55 Message: Logged In: NO I have the same issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:06:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:06:09 2005 Subject: [Expat-bugs] [ expat-Patches-888879 ] gb2312 encoding handle Message-ID: Patches item #888879, was opened at 2004-02-02 01:15 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=888879&group_id=10127 Category: None Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: hunter,liu (szhunter) Assigned to: Nobody/Anonymous (nobody) Summary: gb2312 encoding handle Initial Comment: an patch for expat that can let expat handle gb2312 encoding xml file. Developer must use Xml_SetUnknowEncodingHandle() to call XML_GbEncodingHandle() ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-02-07 09:19 Message: Logged In: YES user_id=290026 Thank you for your patch! For now we will leave it as a standalone patch, as we have not yet determined in which way support for additional encodings should be added to Expat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=888879&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:06:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:06:10 2005 Subject: [Expat-bugs] [ expat-Patches-987903 ] Add support of OSD_EBCDIC_DF04_1 Message-ID: Patches item #987903, was opened at 2004-07-09 08:09 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=987903&group_id=10127 Category: None Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Jean-frederic Clere (jfclere) Assigned to: Nobody/Anonymous (nobody) Summary: Add support of OSD_EBCDIC_DF04_1 Initial Comment: The patch allows to parse a document encoded in EBCDIC. OSD_EBCDIC_DF04_1 is an EBCDIC charset used on BS2000 mainframe and registered at IANA (See http://www.iana.org/assignments/character-sets). I am using the patch in APR (Apache Portable Rutime). The patch could be easly adapted to other EBCDIC encoding by changing the include files map_osd_ebcdic_df04_1.h and osd_ebcdic_df04_1.h ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-17 13:32 Message: Logged In: YES user_id=290026 Thank you for your patch! For now we will leave it as a standalone patch, as we have not yet determined in which way support for additional encodings should be added to Expat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=987903&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:22:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:22:09 2005 Subject: [Expat-bugs] [ expat-Bugs-1048448 ] Create different link symbols for different XML_Char sizes Message-ID: Bugs item #1048448, was opened at 2004-10-16 16:16 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1048448&group_id=10127 Category: None Group: Feature Request Status: Open >Resolution: Postponed Priority: 5 Submitted By: Steinar Bang (steinarb) Assigned to: Nobody/Anonymous (nobody) Summary: Create different link symbols for different XML_Char sizes Initial Comment: It would be nice if some C preprocessor magic could be used to make different XML_Char sizes, selected at compile time, result in different link symbols for the functions in the API. This would make it possible for different shared libraries making up an application on linux, to link against expat shared libraries that have been compiled with different values for XML_char. I ran into a problem when I had compiled my own shared library version of expat on linux, compiled with -DUNICODE, and a base library had been linked with the fontconfig library, to improve X11 font handling. The fontconfig library had an XML config file, and used expat to parse the file. It used the system installed version of expat, which had a char sized XML_Char. This resulted in the following console output at my application's startup: Fontconfig error: line 1: unknown encoding Fontconfig error: Cannot load default config file and the application started up with a strange-looking font named "Arioso", when what I expected was "Helvetica". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:22 Message: Logged In: YES user_id=3066 This should definately be done, but will break binary compatibility with recent releases. We'll plan to include this as a new feature in Expat 3 (Expat 2 will be the result of recent, not something incompatible with the current releases). Marking this "postponed"; this will be un-postponed when we start Expat 3 development. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1048448&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:26:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:26:47 2005 Subject: [Expat-bugs] [ expat-Bugs-1038755 ] Change xmltok_impl.c and xmltokns.c extension Message-ID: Bugs item #1038755, was opened at 2004-10-01 18:23 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1038755&group_id=10127 Category: www.libexpat.org Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Change xmltok_impl.c and xmltokns.c extension Initial Comment: It would be very good if you don't give c extensions to the files you include from anothers. While I used MS VC, it was only annoying not to take it as a source file. But Eclipse/CDT compile whole directories and so I have needed to rename xmltok_impl_c, xmltokns_c and changing the xmltok.c's source also... ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:26 Message: Logged In: YES user_id=3066 This seems like a bug in the tools you're using, though I agree it's very annoying. Naming them with another extension (.h comes to mind) is misleading as well, as these aren't headers. They don't represent compilation units, but they are C language source code, so I think we'll just have to live with the .c extension. Sorry, but I'm going to close this as "won't fix" since there's no clear "right" thing to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1038755&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:39:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:39:27 2005 Subject: [Expat-bugs] [ expat-Bugs-693747 ] compile problem on HP-UX 11 with expat version > 1.95.4 Message-ID: Bugs item #693747, was opened at 2003-02-26 11:47 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=693747&group_id=10127 Category: Build control >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: compile problem on HP-UX 11 with expat version > 1.95.4 Initial Comment: complie problem on HP-UX 11 with expat version > 1.95.4 ---------------------------------------- cc -w -O2 -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c cc: "xmlwf/xmlwf.c", line 602: error 1000: Unexpected symbol: "*". cc: error 2017: Cannot recover from earlier errors, terminating. make: *** [xmlwf/xmlwf.o] Error 1 ______________________ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:39 Message: Logged In: YES user_id=3066 The problem fixed by liebman is fixed in Makefile.in revision 1.50 (Expat 1.95.9). I'm closing this report under the suspicion that this is the same problem as described by the original poster. If the original problem persists with the changed Makefile, please follow up to this report or submit a new report. ---------------------------------------------------------------------- Comment By: Chris Liebman (liebman) Date: 2004-01-18 18:09 Message: Logged In: YES user_id=55478 I get the same error when compiling on a system that has an older version of expat.h already installed. In my case I'm adding additional include dirs... they are being placed befor -I./lib and -I. resulting in: gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I/home/liebman/ats-rt/include -I/home/liebman/ats-rt/ext/include -I./lib -I. -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c In file included from xmlwf/xmlwf.c:10: /home/liebman/ats-rt/ext/include/expat.h:704: warning: function declaration isn't a prototype xmlwf/xmlwf.c: In function `showVersion': xmlwf/xmlwf.c:602: error: syntax error before '*' token xmlwf/xmlwf.c:613: error: `features' undeclared (first use in this function) xmlwf/xmlwf.c:613: error: (Each undeclared identifier is reported only once xmlwf/xmlwf.c:613: error: for each function it appears in.) xmlwf/xmlwf.c:613: error: `XML_FEATURE_END' undeclared (first use in this function) make: *** [xmlwf/xmlwf.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=693747&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:42:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:42:26 2005 Subject: [Expat-bugs] [ expat-Bugs-1033965 ] Building application fails with Intel C compiler (1.95.7) Message-ID: Bugs item #1033965, was opened at 2004-09-24 07:12 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Arjen Markus (arjenmarkus) Assigned to: Greg Stein (gstein) Summary: Building application fails with Intel C compiler (1.95.7) Initial Comment: I tried to build a small application using the Intel C compiler under Linux. The compiler chokes on the use of the macro XMLCALL: ../lib/include/expat.h(261): warning #1287: invalid attribute for field "malloc_fcn" void *(XMLCALL *malloc_fcn)(size_t size); ^ The macro seems to be set to an empty string, as there is no specific information for that compiler in the header file, but I have not thoroughly investigated this. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:42 Message: Logged In: YES user_id=3066 I really don't like having bogus warnings being generated; if those can be cleared up, I'd like to do so. Is documentation for the Intel compiler available online? I'd be especially interested in material on compiler hints and attributes. ---------------------------------------------------------------------- Comment By: Arjen Markus (arjenmarkus) Date: 2004-09-27 05:41 Message: Logged In: YES user_id=400048 I tried with Expat 1.95.8: the result was two warnings only, but the C source was compiled and the program that finally results does the job correctly. Here are the warnings: ../expat-1.95.8/lib/expat.h(501): warning #1287: invalid attribute for field "convert" int (XMLCALL *convert)(void *data, const char *s); ^ ../expat-1.95.8/lib/expat.h(502): warning #1287: invalid attribute for field "release" void (XMLCALL *release)(void *data); ^ (As far as I am concerned: this version is okay :)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 08:58 Message: Logged In: YES user_id=290026 This might not be a problem with Expat 1.95.8. Could you please try? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:45:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:45:21 2005 Subject: [Expat-bugs] [ expat-Bugs-842049 ] Configure script error - CC or CPP Message-ID: Bugs item #842049, was opened at 2003-11-14 06:48 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=842049&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Configure script error - CC or CPP Initial Comment: expat-1.95.7 My check install is in a none standard location. I set the CFLAGS enviroment variable so the file could be found. You then get a configure warning: configure: WARNING: check.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: check.h: proceeding with the preprocessor's result This seems to be due to the preprocessor check using CPP and the CPPFLAGS while the compiler check uses CC and CFLAGS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:45 Message: Logged In: YES user_id=3066 Expat 1.95.9 will no longer use the check library; I'm closing this as out-of-date. ---------------------------------------------------------------------- Comment By: Magnus Henoch (legoscia) Date: 2004-10-10 11:40 Message: Logged In: YES user_id=920364 This patch seems to fix the problem. (I found no way to attach it...) Can it be installed in CVS? Index: conftools/expat.m4 =================================================================== RCS file: /cvsroot/expat/expat/conftools/expat.m4,v retrieving revision 1.1 diff -u -r1.1 expat.m4 --- conftools/expat.m4 9 Nov 2001 04:55:33 -0000 1.1 +++ conftools/expat.m4 10 Oct 2004 15:26:46 -0000 @@ -1,6 +1,6 @@ dnl Check if --with-expat[=PREFIX] is specified and dnl Expat >= 1.95.0 is installed in the system. -dnl If yes, substitute EXPAT_CFLAGS, EXPAT_LIBS with regard to +dnl If yes, substitute EXPAT_CPPFLAGS, EXPAT_LIBS with regard to dnl the specified PREFIX and set with_expat to PREFIX, or 'yes' if PREFIX dnl has not been specified. Also HAVE_LIBEXPAT, HAVE_EXPAT_H are defined. dnl If --with-expat has not been specified, set with_expat to 'no'. @@ -14,11 +14,11 @@ AM_CONDITIONAL(EXPAT_INSTALLED, test $with_expat != no) - EXPAT_CFLAGS= + EXPAT_CPPFLAGS= EXPAT_LIBS= if test $with_expat != no; then if test $with_expat != yes; then - EXPAT_CFLAGS="-I$with_expat/include" + EXPAT_CPPFLAGS="-I$with_expat/include" EXPAT_LIBS="-L$with_expat/lib" fi AC_CHECK_LIB(expat, XML_ParserCreate, @@ -29,15 +29,24 @@ if test $expat_found = no; then AC_MSG_ERROR([Could not find the Expat library]) fi - expat_save_CFLAGS="$CFLAGS" - CFLAGS="$CFLAGS $EXPAT_CFLAGS" + expat_save_CPPFLAGS="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS $EXPAT_CPPFLAGS" AC_CHECK_HEADERS(expat.h, , expat_found=no) if test $expat_found = no; then AC_MSG_ERROR([Could not find expat.h]) fi - CFLAGS="$expat_save_CFLAGS" + CPPFLAGS="$expat_save_CPPFLAGS" fi + AC_SUBST(EXPAT_CPPFLAGS) AC_SUBST(EXPAT_CFLAGS) AC_SUBST(EXPAT_LIBS) + + # Earlier versions of this script incorrectly used CFLAGS instead + # of CPPFLAGS, causing preprocessor-only autoconf tests to fail + # when expat was installed in a nonstandard location. The following + # lines make sure that existing scripts depending on this bug + # still work. + EXPAT_CFLAGS="$EXPAT_CPPFLAGS" + AC_SUBST(EXPAT_CFLAGS) ]) Magnus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=842049&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:49:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:50:00 2005 Subject: [Expat-bugs] [ expat-Bugs-1033923 ] building expat 1.95.8 on Solaris using Sun's compiler Message-ID: Bugs item #1033923, was opened at 2004-09-24 05:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033923&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: building expat 1.95.8 on Solaris using Sun's compiler Initial Comment: Hi, I'm building expat 1.95.8 on Solaris 8 using the Sun ONE Studio 7 compiler. The build succeeds, although I see some warnings that need to be fixed: "lib/xmlparse.c", line 1572: warning: enum type mismatch: op "=" "lib/xmlparse.c", line 1578: warning: enum type mismatch: op "=" "lib/xmlparse.c", line 1586: warning: enum type mismatch: op "=" "lib/xmlparse.c", line 1719: warning: enum type mismatch: op "=" "lib/xmlparse.c", line 1725: warning: enum type mismatch: op "=" "lib/xmlparse.c", line 1733: warning: enum type mismatch: op "=" The problem is that variable "result" has type "XML_Error" while the constants in the right part of the "=" operator have type "XML_Status". Otherwise I can confirm bug #1000112 where expat_external.h is not installed. Finally 'make run-xmltest' fails. Here is the complete log: wget --output-document=tests/xmlts.zip http://www.w3.org/XML/Test/xmlts20020606.zip --11:30:34-- http://www.w3.org/XML/Test/xmlts20020606.zip => `tests/xmlts.zip' Resolving www.w3.org... 128.30.52.25, 133.27.228.207, 18.7.14.127, ... Connecting to www.w3.org[128.30.52.25]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,551,683 [application/zip] 100%[====================================>] 1,551,683 195.26K/s ETA 00:00 11:30:43 (181.12 KB/s) - `tests/xmlts.zip' saved [1551683/1551683] cd tests && unzip -q xmlts.zip tests/xmltest.sh tests/xmltest.sh: /tmp/expat-1.95.8/tests/XML-Test-Suite/xmlconf/ibm/valid/P*/: does not exist gmake: *** [run-xmltest] Error 1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:49 Message: Logged In: YES user_id=3066 This seems fixed to me, and no one has complained about it using the CVS version of Expat. If there's any further problem with this in the CVS version or the coming Expat 1.95.9, please file a new bug report with detailed information on the error and the environment the test is run in. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-09-29 22:36 Message: Logged In: YES user_id=3066 I've modified the script to address the shell portability problems; if it's possible to test the CVS version, please do so and report your results. tests/xmltest.sh 1.4 ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2004-09-27 06:05 Message: Logged In: YES user_id=52414 The problem is with the following code: ########################## # well-formed test cases # ########################## cd "$TS/xmlconf" for xmldir in ibm/valid/P*/ ibm/invalid/P*/ xmltest/valid/ext-sa/ xmltest/valid/not-sa/ xmltest/invalid/ xmltest/invalid/not-sa/ xmltest/valid/sa/ sun/valid/ sun/invalid/ ; do Indeed the directories are there: $ ls -d tests/XML-Test-Suite/xmlconf/ibm/valid/P*/ tests/XML-Test-Suite/xmlconf/ibm/valid/P01/ [...] tests/XML-Test-Suite/xmlconf/ibm/valid/P89/ $ but the "for" loop should be written as: for xmldir in ibm/valid/P* ibm/invalid/P* xmltest/valid/ext-sa xmltest/valid/not-sa xmltest/invalid xmltest/invalid/not-sa xmltest/valid/sa sun/valid sun/invalid ; do instead of: for xmldir in ibm/valid/P*/ ibm/invalid/P*/ xmltest/valid/ext-sa/ xmltest/valid/not-sa/ xmltest/invalid/ xmltest/invalid/not-sa/ xmltest/valid/sa/ sun/valid/ sun/invalid/ ; do The trailing "/" is wrong, it just happens to work under bash. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 11:03 Message: Logged In: YES user_id=290026 This may have to do with slight differences in how shell scripts work on different platforms. I'll assign this to Fred, as he is more knowledgeable on Unix. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2004-09-24 09:51 Message: Logged In: YES user_id=52414 The directories seem to be there and wget seems to have downloaded xmlts20020606.zip. It rather looks like a bug in tests/xmltest.sh. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 09:24 Message: Logged In: YES user_id=290026 You may be right - I wasn't aware that the XML_Test-Suite gets downloaded. Can you find the downloaded directories? Maybe it has changed - the test scripts are only tested with a specific release of the test suite. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2004-09-24 09:14 Message: Logged In: YES user_id=52414 No, I haven't installed XML-Test-Suite manually. Isn't it supposed to be downloaded and installed automatically? It does seem to be downloaded automatically, using wget. See log. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 09:00 Message: Logged In: YES user_id=290026 I think the warning is fixed in CVS. For running the tests - did you download and install the XML-Test-Suite? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033923&group_id=10127 From noreply at sourceforge.net Fri Jan 28 05:52:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 05:52:30 2005 Subject: [Expat-bugs] [ expat-Bugs-1058158 ] building expat 1.95.8 on Solaris using Sun Compiler Message-ID: Bugs item #1058158, was opened at 2004-11-01 09:10 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1058158&group_id=10127 Category: Build control >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: building expat 1.95.8 on Solaris using Sun Compiler Initial Comment: Hi I'm trying to build on a Solaris system using a SUN compiler. ./configure returned host system type=sparc-sun-solaris2.8 However the build failed and returned the following /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file __eprintf lib/xmlparse.lo ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 make: *** [libexpat.la] Error 1 Any help or advice regarding building the expat 1.95.8 would be greatly appreciated. Regards Thomas thomas@robots.ox.ac.uk ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:52 Message: Logged In: YES user_id=3066 Expat 1.95.9 will be built using libtool 1.5.10, so this problem goes away. Closing this report as fixed by the coming release. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-11-10 18:06 Message: Logged In: NO Hi! I solved this problem by changing the line that starts with LIBTOOL on configure script this way(or Makefile if you want): # Always use our own libtool. #LIBTOOL='$(SHELL) $(top_builddir)/libtool' LIBTOOL='$(SHELL) /usr/local/bin/libtool' I used my own installed libtool : my_host# libtool --version ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. instead of the one that came with the expat-1.95.8 distribution: my_host#pwd /usr/local/src/expat-1.95.8 my_host# ./libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) You can change the line LIBTOOL on Makefile the same way I did on configure script if you don't want to do that on the script. With this simple change, the library compiled and then it was installed. Later it passed all the tests after making "check" . I hope you find this hepful Bye Crox Sanchez crox@ula.ve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1058158&group_id=10127 From noreply at sourceforge.net Fri Jan 28 06:02:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 06:02:07 2005 Subject: [Expat-bugs] [ expat-Bugs-780087 ] bad gcc flag when linking library in Solaris 2.8 Message-ID: Bugs item #780087, was opened at 2003-07-30 04:44 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: bad gcc flag when linking library in Solaris 2.8 Initial Comment: expat 1.95.5, 1.95.6 When libtool links the lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo into libexpat.la on Solaris 2.8 when using gcc(3.3 or 3.1), libgcc(3.1 or 3.3) and binutils (2.11.2) ,from SunFreeware.com, it includes the '-no- undefined' flag which causes the make to always fail with a "main not found in crt1.o" error. This of course is silly 'coz a library has no 'main', see gcc discusion http://www.geocrawler.com/mail/msg.php3? msg_id=2903632&list=28. Looking at libtools "link" case statement I see it sets "allow_undefined=yes" but this does not translate to the make line. Could this be a problem? When I manually edited the "make" line, removing the flag '-no-undefined' the library was built without error. As this stops expat building from source on the above platform can I sugest that this is considered an urgent bug to be fixed? Of course I could be wrong :-) Here's an example (I've used 1.95.5 to avoid all those regparm warning messages you get in 1.95.6 on Solaris with gcc 3.1/3.3) snip--- Script started on Wed Jul 30 09:41:53 2003 sh-2.03$ cd expat-1.95.5 sh-2.03$ make distclean ; ./configure ; make cd lib && rm -f libexpat.la *.o *.lo && rm -rf .libs _libs cd xmlwf && rm -f xmlwf *.o *.lo && rm -rf .libs _libs cd examples && rm -f elements outline *.o *.lo && rm - rf .libs _libs cd tests && rm -rf .libs runtests runtests.o chardata.o rm -rf .libs libexpat.la find . -name core | xargs rm -f rm -f expat_config.h config.status config.log config.cache libtool rm -f Makefile checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... /usr/local/bin/gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/local/bin/gcc accepts -g... yes checking for ld used by GCC... /usr/local/bin/gcc checking if the linker (/usr/local/bin/gcc) is GNU ld... no checking for /usr/local/bin/gcc option to reload object files... -r checking for BSD-compatible nm... /usr/local/bin/nm -B checking whether ln -s works... yes checking how to recognise dependant libraries... pass_all checking command to parse /usr/local/bin/nm -B output... ok checking how to run the C preprocessor... /usr/local/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/local/bin/gcc option to produce PIC... - fPIC checking if /usr/local/bin/gcc PIC flag -fPIC works... yes checking if /usr/local/bin/gcc static flag -static works... yes checking if /usr/local/bin/gcc supports -c -o file.o... yes checking if /usr/local/bin/gcc supports -c -o file.lo... yes checking if /usr/local/bin/gcc supports -fno-rtti -fno- exceptions... yes checking whether the linker (/usr/local/bin/gcc) supports shared libraries... ye s checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... solaris2.8 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool checking for gcc... (cached) /usr/local/bin/gcc checking whether we are using the GNU C compiler... (cached) yes checking whether /usr/local/bin/gcc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/local/bin/gcc option to accept ANSI C... none needed checking for an ANSI C-conforming const... yes checking for off_t... yes checking for size_t... yes checking for working memcmp... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for memmove... yes checking for bcopy... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmlparse. lo -c lib/xmlparse.c /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent -- mode=compile /usr/local/bin/gcc -g -O2 -Wall -Wmi ssing-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -o lib/xmlrole.l o -c lib/xmlrole.c /bin/bash ./libtool --silent -- mode=link /usr/local/bin/gcc -g -O2 -Wall -Wmissi ng-prototypes -Wstrict-prototypes -fexceptions - I./lib -I. -no-undefined -vers ion-info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file main /usr/local/lib/gcc-lib/sparc- sun-solaris2.8/ 3.3/crt1.o ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.4 .0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libexpat.la' sh-2.03$ exit script done on Wed Jul 30 09:43:53 2003 snip--- ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 00:02 Message: Logged In: YES user_id=3066 I think this is as fixed as it can be by using recent versions of libtool and autoconf when the distribution is built; these options are not specifically controlled as part of the Expat sources. Marking as fixed based on the most recent comment. If further problems are observed with the Expat 1.95.9 release, please file a separate report. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-08-11 08:13 Message: Logged In: NO I've failed to reproduce this on Solaris 8 with the latest Expat version (1.95.8) Expat: 1.95.8 Compiler: gcc 3.3.3 Libtool: 1.5 As an aside, -shared option should be used for linking shared libs on Solaris. -G ends up in the library apparently being linked but later errors about failing to find 'main' when linking an application. I can't see either mentioned above though. Another aside: -O2 is dangerous for some versions of gcc on SPARC, in particular 3.3.2, 3.3.3. -O2 should only be used with option -fno-peephole for the paranoid :-). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-06-08 19:37 Message: Logged In: NO have you resolved this? I'm having the same problem and unable to solve it Please let me know if you have any glue ---------------------------------------------------------------------- Comment By: Faye Gibbins (fgibbins) Date: 2003-11-03 08:04 Message: Logged In: YES user_id=837230 I'm still getting this on Solairs 2.8 with expat 1.95.7 snip--- /bin/bash ./libtool --silent --mode=compile /usr/local/bin/gcc - g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/bash ./libtool --silent --mode=compile /usr/local/bin/gcc - g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/bash ./libtool --silent --mode=link /usr/local/bin/gcc -g - O2 -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -no- undefined -version-info 5:0:5 - rpath /home/l347283/tmp/expat/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Undefined first referenced symbol in file main /usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3/crt1.o ld: fatal: Symbol referencing errors. No output written to .libs/libexpat.so.0.5.0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libexpat.la' [l347283@ifperf expat-1.95.7]$ snip--- ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-14 15:47 Message: Logged In: YES user_id=3066 There's a snapshot of the current CVS version at: http://www.libexpat.org/expat-2003-10-11.tar.gz Can anyone reproduce this using this snapshot? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=780087&group_id=10127 From noreply at sourceforge.net Fri Jan 28 06:02:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 06:03:01 2005 Subject: [Expat-bugs] [ expat-Bugs-707021 ] Improve internal entity reporting Message-ID: Bugs item #707021, was opened at 2003-03-20 12:30 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707021&group_id=10127 Category: None Group: Feature Request Status: Open >Resolution: Postponed Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Improve internal entity reporting Initial Comment: Currently there are limitations to the reporting of internal entities, which affects DOM building and validation on top of Epat: - When internal entities are expanded, then there is no way to determine when an entity starts or ends. - When they are not expanded (in content) then the entity references are reported through the skippedEntityHandler or the defaultHandler, which is a crude way to detect entity boundaries since it now places the burden of expansion on the call-back code. - PE references in entity values (declarations) and GE references in attribute values are always silently expanded (if possible) and there is no way to detect entity boundaries, even when skipped It would be nice to have a way to report internal entity boundaries in character content, entity values and attribute values in a uniform way, whether the entity is expanded or not. It could be an optional feature, but likely not through setting start/endEntityHandlers, since such handlers would not work for attribute and entity values, as these are not reported in a streaming fashion. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 00:02 Message: Logged In: YES user_id=3066 Postponed to Expat 3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=707021&group_id=10127 From noreply at sourceforge.net Fri Jan 28 06:20:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 06:20:40 2005 Subject: [Expat-bugs] [ expat-Bugs-1006708 ] unmatched braces in headers Message-ID: Bugs item #1006708, was opened at 2004-08-10 12:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1006708&group_id=10127 Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: unmatched braces in headers Initial Comment: expat.h contains: #ifdef __cplusplus } #endif and expat_external.h contains: #ifdef __cplusplus extern "C" { #endif Each file should both open and close these blocks. There are some cases where only expat_external.h is included in the expat sources. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 00:20 Message: Logged In: YES user_id=3066 Add test of Expat usage from C++; closing this report. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-08-10 14:22 Message: Logged In: YES user_id=290026 Fixed in revisions expat.h 1.71 and expat_external.h 1.2. Needs testing of C++ compilation. Already checked in a few fixes when doing so under MS VC++ 6.0. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-08-10 12:42 Message: Logged In: NO My name is Jon . Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1006708&group_id=10127 From noreply at sourceforge.net Fri Jan 28 14:59:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 14:59:58 2005 Subject: [Expat-bugs] [ expat-Bugs-1033965 ] Building application fails with Intel C compiler (1.95.7) Message-ID: Bugs item #1033965, was opened at 2004-09-24 13:12 Message generated for change (Comment added) made by arjenmarkus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Arjen Markus (arjenmarkus) Assigned to: Greg Stein (gstein) Summary: Building application fails with Intel C compiler (1.95.7) Initial Comment: I tried to build a small application using the Intel C compiler under Linux. The compiler chokes on the use of the macro XMLCALL: ../lib/include/expat.h(261): warning #1287: invalid attribute for field "malloc_fcn" void *(XMLCALL *malloc_fcn)(size_t size); ^ The macro seems to be set to an empty string, as there is no specific information for that compiler in the header file, but I have not thoroughly investigated this. ---------------------------------------------------------------------- >Comment By: Arjen Markus (arjenmarkus) Date: 2005-01-28 14:59 Message: Logged In: YES user_id=400048 Here are some comments on the Intel C compiler from a Linux user that seem relevant: http://www.mcsr.olemiss.edu/parallelogram/01_03/icc.html >From the Intel site: http://www.intel.com/software/products/compilers/clin/clinux.htm I do not know whether this will actually help you solve the problem. Perhaps a direct question to the Intel support people might help. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 05:42 Message: Logged In: YES user_id=3066 I really don't like having bogus warnings being generated; if those can be cleared up, I'd like to do so. Is documentation for the Intel compiler available online? I'd be especially interested in material on compiler hints and attributes. ---------------------------------------------------------------------- Comment By: Arjen Markus (arjenmarkus) Date: 2004-09-27 11:41 Message: Logged In: YES user_id=400048 I tried with Expat 1.95.8: the result was two warnings only, but the C source was compiled and the program that finally results does the job correctly. Here are the warnings: ../expat-1.95.8/lib/expat.h(501): warning #1287: invalid attribute for field "convert" int (XMLCALL *convert)(void *data, const char *s); ^ ../expat-1.95.8/lib/expat.h(502): warning #1287: invalid attribute for field "release" void (XMLCALL *release)(void *data); ^ (As far as I am concerned: this version is okay :)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 14:58 Message: Logged In: YES user_id=290026 This might not be a problem with Expat 1.95.8. Could you please try? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 From noreply at sourceforge.net Fri Jan 28 17:02:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 28 17:02:18 2005 Subject: [Expat-bugs] [ expat-Bugs-1033965 ] Building application fails with Intel C compiler (1.95.7) Message-ID: Bugs item #1033965, was opened at 2004-09-24 07:12 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Arjen Markus (arjenmarkus) Assigned to: Greg Stein (gstein) Summary: Building application fails with Intel C compiler (1.95.7) Initial Comment: I tried to build a small application using the Intel C compiler under Linux. The compiler chokes on the use of the macro XMLCALL: ../lib/include/expat.h(261): warning #1287: invalid attribute for field "malloc_fcn" void *(XMLCALL *malloc_fcn)(size_t size); ^ The macro seems to be set to an empty string, as there is no specific information for that compiler in the header file, but I have not thoroughly investigated this. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 11:02 Message: Logged In: YES user_id=3066 The second document refers to a compatibility guide which hints at the right information, but doesn't contain the specific details I'm looking for. I'll try contacting Intel or getting a copy of the compiler. It notes that the current version of the Intel compiler supports "most" of the GCC function attributes, but it doesn't say which ones specifically. The download page for the compatibility guide is: http://www.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm ---------------------------------------------------------------------- Comment By: Arjen Markus (arjenmarkus) Date: 2005-01-28 08:59 Message: Logged In: YES user_id=400048 Here are some comments on the Intel C compiler from a Linux user that seem relevant: http://www.mcsr.olemiss.edu/parallelogram/01_03/icc.html >From the Intel site: http://www.intel.com/software/products/compilers/clin/clinux.htm I do not know whether this will actually help you solve the problem. Perhaps a direct question to the Intel support people might help. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 23:42 Message: Logged In: YES user_id=3066 I really don't like having bogus warnings being generated; if those can be cleared up, I'd like to do so. Is documentation for the Intel compiler available online? I'd be especially interested in material on compiler hints and attributes. ---------------------------------------------------------------------- Comment By: Arjen Markus (arjenmarkus) Date: 2004-09-27 05:41 Message: Logged In: YES user_id=400048 I tried with Expat 1.95.8: the result was two warnings only, but the C source was compiled and the program that finally results does the job correctly. Here are the warnings: ../expat-1.95.8/lib/expat.h(501): warning #1287: invalid attribute for field "convert" int (XMLCALL *convert)(void *data, const char *s); ^ ../expat-1.95.8/lib/expat.h(502): warning #1287: invalid attribute for field "release" void (XMLCALL *release)(void *data); ^ (As far as I am concerned: this version is okay :)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-09-24 08:58 Message: Logged In: YES user_id=290026 This might not be a problem with Expat 1.95.8. Could you please try? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1033965&group_id=10127 From noreply at sourceforge.net Sat Jan 29 03:29:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 03:29:27 2005 Subject: [Expat-bugs] [ expat-Bugs-1021776 ] Recursion in macro "parsing", HP 11.0 Message-ID: Bugs item #1021776, was opened at 2004-09-03 08:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Recursion in macro "parsing", HP 11.0 Initial Comment: uname -a HP-UX hprgs B.11.00 U 9000/800 76745 unlimited-user license ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... cat: Cannot open conftest. c: No such file or directory no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h hprgs:#/varios/perl/expat-1.95.8> ./configure checking build system type... hppa2.0w-hp-hpux11.00 checking host system type... hppa2.0w-hp-hpux11.00 checking for gcc... /usr/ccs/bin/cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/ccs/bin/cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependant libraries... file_magic (s[0-9][0-9][0-9]|PA -RISC[0-9].[0-9]) shared library checking command to parse /usr/bin/nm -p output... ok checking how to run the C preprocessor... /usr/ccs/bin/ cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for /usr/ccs/bin/cc option to produce PIC... +Z checking if /usr/ccs/bin/cc PIC flag +Z works... yes checking if /usr/ccs/bin/cc static flag -Wl,-a -Wl,archive works... yes checking if /usr/ccs/bin/cc supports -c -o file.o... no checking if we can lock with hard links... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... no 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 creating libtool checking for gcc... (cached) /usr/ccs/bin/cc checking whether we are using the GNU C compiler... (cached) no checking whether /usr/ccs/bin/cc accepts -g... (cached) yes checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for /usr/ccs/bin/cc option to accept ANSI C... none needed checking for an ANSI C-conforming const... no checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... no checking check.h usability... no checking check.h presence... no checking for check.h... no checking for check.h... (cached) no configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h make /bin/sh ./libtool --silent --mode=compile /usr/ccs/ bin/cc -g -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o lib/ xmlparse.lo -c lib/xmlparse.c (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: "lib/xmlparse.c", line 855: error 4065: Recursion in macro "parsing". *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 21:29 Message: Logged In: YES user_id=3066 I went ahead and committed the patch as lib/xmlparse.c 1.144. Closing the issue as fixed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:48 Message: Logged In: YES user_id=3066 I think those names are fine. I'm replacing the patch to match. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 10:33 Message: Logged In: YES user_id=290026 Yes, finalBuffer needs fixing as well. What about these names: #define ps_parsing (parser->m_parsingStatus.parsing) #define ps_finalBuffer (parser->m_parsingStatus.finalBuffer) to indicate that they refer to members of members? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=3066 Less than ideal because it breaks the convention, but it's also expanding not to a member of the parser but a member of a member of the parser, so it's a little different anyway. After I submitted the patch, I realized that we could see the same problem for "finalBuffer" on the affected platform; if we don't I'll be very surprised actually. The final patch will need to include a comment explaining why the macros are different from the others, and cite this tracker issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-27 09:37 Message: Logged In: YES user_id=290026 The only objection I would have is that this breaks the naming convention for these types of macros. But that is not a showstopper for me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 00:23 Message: Logged In: YES user_id=3066 While this seems rather clearly to be a compiler problem, we can deal with this by renaming the "parsing" macro; that won't be a problem for the API (since the macro is strictly internal) nor will it be a problem for compliant compilers. I've attached a patch. If someone who can reproduce the problem can test the patch on an affected version of HP-UX, that would be quite helpful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 11:12 Message: Logged In: YES user_id=290026 I had a further look at the source and found these macros #define parsing (parser->m_parsingStatus.parsing) #define finalBuffer (parser->m_parsingStatus.finalBuffer) as the likely source of your problems. AFAIK, if a macro refers to itself, then the C preprocessor must not expand the reference, so it looks as if your compiler breaks that rule. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-12-21 09:29 Message: Logged In: YES user_id=290026 Must be a platform issue, but I have no expertise in it. However, we may get a build expert on board, and then I'll assign this issue to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-21 08:49 Message: Logged In: NO I have the same problem?? Steen.brandtmar@ementor.dk ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 04:55 Message: Logged In: NO I have the same issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1021776&group_id=10127 From noreply at sourceforge.net Sat Jan 29 03:35:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 03:35:26 2005 Subject: [Expat-bugs] [ expat-Bugs-1073661 ] Expat-1.95.8 win32bin mingw32 libraries Message-ID: Bugs item #1073661, was opened at 2004-11-26 05:28 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1073661&group_id=10127 >Category: Build control >Group: Platform Specific Status: Open Resolution: None >Priority: 4 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Expat-1.95.8 win32bin mingw32 libraries Initial Comment: There is a very little problem with the binary distribution of Expat-1.95.8. I've been building from scratch perl 5.8.5 on win32, and encountered the same problem across several modules. Most modules depend on external libraries. Most library distributions provide binary versions, some provide binaries. Expat provides both dll and libraries. The problem is that libraries are for vc++ or bc, not for mingw. The following procedure generates mingw dinamic libraries: pexports libexpat.dll > expat.def pexports libexpatw.dll > expatw.def dlltool -d expat.def -l libexpat.a dlltool -d expatw.def -l libexpatw.a The *.a files are mingw libraries. May be you can include them in the binary distribution. You NEED to put the *.dll in your %PATH%. Now you can just point XML-Parser instalation to your expat binary distribution: whatever\XML-Parser-2.34>perl Makefile.pl EXPATLIBPATH=whatever2\Expat-1.95.8\Lib s EXPATINCPATH=whatever2\Expat-1.95.8\Source\lib dmake dmake test dmake install Everything should run smoothly. Greets Bruno Diaz Briere bruno.diaz-[@can@be_reached@at_host-[_gmx.net ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 21:35 Message: Logged In: YES user_id=3066 Karl: Unless you want to do this, I'm inclined to reject this. If this is easy for a MinGW user to do, it's something that's reasonable for them to do themselves. That's simply part of using a minority compiler on a majority-centric platform. Assigning to you for a decision. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-11-26 08:56 Message: Logged In: YES user_id=290026 Why don't you provide a ready-made patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1073661&group_id=10127 From noreply at sourceforge.net Sat Jan 29 03:39:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 03:39:15 2005 Subject: [Expat-bugs] [ expat-Bugs-942460 ] how to configure the expat library for cross compilation. Message-ID: Bugs item #942460, was opened at 2004-04-26 12:34 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942460&group_id=10127 >Category: Documentation Group: Platform Specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: how to configure the expat library for cross compilation. Initial Comment: Hi, Iam using i686 architecure.I want to build my application using ppc_405 architecture.I have the gcc,lib,etc..for my ppc_405 architecture. In my application am using the expat library calls.So i have to reconfigure my expat library for PPC architecture.hope am right ? In that regard i want to know how to configure it for PPC architecture. i gave the following option. #./configure --host=ppc --prefix=. CC=ppc_405gcc is thiz fine ?? or else shud i give some more like --build ?? can you mail me direclty to sbabu_psgbits@yahoo.co.in thanks in advance, ~Babu.S ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 21:39 Message: Logged In: YES user_id=3066 Cross-compilation is a tools issue; this needs to be dealt with using the tools you have available. We use libtool and autoconf on Unix, so that should give you everything you need with a GCC-based toolchain. You should be able to use the standard documentation for your tools to deal with this. If it takes anything more than that, please let us know specifically what you had to do, and we'll add that to the documentation. Specific suggested text would be very helpful; I certainly don't have any cross-compilation experience myself. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-04-30 00:18 Message: Logged In: YES user_id=290026 I don't think our team has anyone with PPC expertise. It would be nice if you could find a solution and submit it back to this project as a patch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=942460&group_id=10127 From noreply at sourceforge.net Sat Jan 29 03:40:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 03:40:33 2005 Subject: [Expat-bugs] [ expat-Bugs-973851 ] Irix compilation Message-ID: Bugs item #973851, was opened at 2004-06-16 08:12 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=973851&group_id=10127 Category: Build control Group: Not a Bug >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Irix compilation Initial Comment: expat-1.95.7 On Irix, using cc 7.4.2m, you must use -O1 (or lower) optimization. If you use -O2 or -O3 then you will get a SIGSEGV in XmlInitUnknownEncoding (lib/xmltok.c - line ~1363) when running the test for XML-Parser-2.34. (Looks like a compiler optimization bug - the problem also goes away if you put any printf statements in there to see what is happening) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 21:40 Message: Logged In: YES user_id=3066 Given the lack of response to my request for information in a previous comment, I'm closing this as "Won't Fix". ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-15 19:37 Message: Logged In: YES user_id=3066 Can anyone tell if this is still a case with the CVS version of Expat? Does anyone know how to detect this platform via the configure script? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=973851&group_id=10127 From noreply at sourceforge.net Sat Jan 29 04:48:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 29 04:48:03 2005 Subject: [Expat-bugs] [ expat-Bugs-1073661 ] Expat-1.95.8 win32bin mingw32 libraries Message-ID: Bugs item #1073661, was opened at 2004-11-26 05:28 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1073661&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: Expat-1.95.8 win32bin mingw32 libraries Initial Comment: There is a very little problem with the binary distribution of Expat-1.95.8. I've been building from scratch perl 5.8.5 on win32, and encountered the same problem across several modules. Most modules depend on external libraries. Most library distributions provide binary versions, some provide binaries. Expat provides both dll and libraries. The problem is that libraries are for vc++ or bc, not for mingw. The following procedure generates mingw dinamic libraries: pexports libexpat.dll > expat.def pexports libexpatw.dll > expatw.def dlltool -d expat.def -l libexpat.a dlltool -d expatw.def -l libexpatw.a The *.a files are mingw libraries. May be you can include them in the binary distribution. You NEED to put the *.dll in your %PATH%. Now you can just point XML-Parser instalation to your expat binary distribution: whatever\XML-Parser-2.34>perl Makefile.pl EXPATLIBPATH=whatever2\Expat-1.95.8\Lib s EXPATINCPATH=whatever2\Expat-1.95.8\Source\lib dmake dmake test dmake install Everything should run smoothly. Greets Bruno Diaz Briere bruno.diaz-[@can@be_reached@at_host-[_gmx.net ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2005-01-28 22:48 Message: Logged In: YES user_id=290026 As far as I can tell, the .a files are import libraries which help the linker link against the actual Win32 Dll. I don't think we should include any mingw specific binaries, but I'll see if I can add the instructions to the Win32 docs. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-28 21:35 Message: Logged In: YES user_id=3066 Karl: Unless you want to do this, I'm inclined to reject this. If this is easy for a MinGW user to do, it's something that's reasonable for them to do themselves. That's simply part of using a minority compiler on a majority-centric platform. Assigning to you for a decision. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2004-11-26 08:56 Message: Logged In: YES user_id=290026 Why don't you provide a ready-made patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1073661&group_id=10127 From noreply at sourceforge.net Sun Jan 30 16:41:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 30 16:41:49 2005 Subject: [Expat-bugs] [ expat-Bugs-1105135 ] Win64 portability warnings Message-ID: Bugs item #1105135, was opened at 2005-01-19 10:45 Message generated for change (Comment added) made by hgoldman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Henrik Goldman (hgoldman) Assigned to: Nobody/Anonymous (nobody) Summary: Win64 portability warnings Initial Comment: I am trying to get my software ready for Win64 (AMD64 / IA64). Currently I'm using Visual Studio .NET 2003 with /Wp64 switch enabled. However theres some missing typecasts in expat to make it compile clean. Instead of waiting for someone to fix it I can probably do it myself but I'm only willing to if my changes will be considered for next release. I'm rather sure all the warnings will go away with apropriate typecasts. Please advise me how to continue. I'm using the downloaded version of expat 1.95.8: c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data c:\myprog\shared\libs\expat-1.95.8\lib\xmltok_impl.c (1717) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1604) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1606) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1615) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1628) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1642) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1761) : warning C4244: 'return' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1770) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(1771) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2318) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2323) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2511) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2516) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2541) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(2550) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3067) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3076) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(3938) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(4623) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(4669) : warning C4244: '=' : conve rsion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(5130) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(5135) : warning C4244: 'function' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(6017) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ../../shared\libs\expat-1.95.8\lib\xmlparse.c(6031) : warning C4244: 'initializi ng' : conversion from '__w64 int' to 'int', possible loss of data ---------------------------------------------------------------------- >Comment By: Henrik Goldman (hgoldman) Date: 2005-01-30 16:41 Message: Logged In: YES user_id=798004 Ok, so I patched my local 1.95.8 distribution and created a diff file. All the patches I made, are __int64 to int typecast warnings. All of them were fixed by adding parentheses and adding a (int) typecast. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-27 06:46 Message: Logged In: YES user_id=3066 We'll certainly consider patches. The best way to proceed would be to attach a patch to this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127