From noreply at sourceforge.net Tue Jan 3 15:37:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 06:37:03 -0800 Subject: [Expat-bugs] [ expat-Bugs-1368413 ] Prep AmigaOS changes for 2.0 release Message-ID: Bugs item #1368413, was opened at 2005-11-28 10:30 Message generated for change (Comment added) made by ssolie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1368413&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steven Solie (ssolie) Assigned to: Steven Solie (ssolie) Summary: Prep AmigaOS changes for 2.0 release Initial Comment: Prepare the AmigaOS specific expat changes for the pending 2.0 release. Some minor Makefile changes are needed and documentation updated. ---------------------------------------------------------------------- >Comment By: Steven Solie (ssolie) Date: 2006-01-03 07:37 Message: Logged In: YES user_id=1140661 Fixed and ready to go. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1368413&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:17:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:17:18 -0800 Subject: [Expat-bugs] [ expat-Bugs-1150814 ] expat_win32bin StaticLibs are wrong version Message-ID: Bugs item #1150814, was opened at 2005-02-24 02:42 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1150814&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat_win32bin StaticLibs are wrong version Initial Comment: Installed version of expat: expat_win32bin_1_95_8.exe, which contains both dynamic and static versions of the library. Linking against StaticLibs/libexpatw.lib and StaticLibs/libexpat.lib produce the following errors base.lib(XMLReader_Expat.obj) : error LNK2001: unresolved external symbol _XML_ResumeParser base.lib(XMLReader_Expat.obj) : error LNK2001: unresolved external symbol _XML_StopParser I suspected that the static libs were out of date, so I investigated a little... the files are dated September 06, 2002, 6:04:54 PM. 2002 is pretty old, so I'm guessing this is not new to 1.95.8. A temporary fix is to link against the multi-threaded (libexpatwMT.lib) static library, which seems to work just fine. - Tim Valenzuela tim _at_ deadlyninja.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:17 Message: Logged In: YES user_id=290026 Corrected with release 2.0 for Win32. Closing issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-12-26 13:59 Message: Logged In: YES user_id=290026 In later versions of MS VC++, the single-threaded runtime library is not supported anymore. Expat 2.0 will be the last release including the single-threaded static lib in the Windows binary distribution. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-02-24 08:58 Message: Logged In: YES user_id=290026 Another one for Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1150814&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:18:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:18:19 -0800 Subject: [Expat-bugs] [ expat-Bugs-1284386 ] Byte count in large XML files fails Message-ID: Bugs item #1284386, was opened at 2005-09-07 21:01 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1284386&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) Summary: Byte count in large XML files fails Initial Comment: XML_GetCurrentByteIndex(XML_Parser parser) returns a long, which is at least on the most 32 bit Systems 32 bit long. That means, for XML input larger than 2 GByte file size, XML_GetCurrentByteIndex() returns does not return the right number. Sure, such big XML files will be parsed in chunks, so it is possbile, to keep track about the nr of overflows by self, but come on. It's surely a limbo dance by its own to introcude long long in a source, so portable as expat, but that would be it. If you switch to long long if avaliable for this, please consider also XML_GetCurrentLineNumber() and XML_GetCurrentColumnNumber(). They return an int, which is on most 32-byte systems 2 Gig. Though, I'm not stumbled over this two limits in real life, as I in fact did with XML_GetCurrentByteIndex(). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:18 Message: Logged In: YES user_id=290026 Rolf, I think I can close that now. Do you agree, or is there something you are still missing? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-12-22 16:06 Message: Logged In: YES user_id=290026 Rolf, I think I go for the simple solution: use long long, and if a compiler doesn't support it, too bad, the programmer will have to use 32 bit integers: #ifdef XML_LARGE_SIZE typedef long long XML_Index; typedef unsigned long long XML_Size; #else typedef long XML_Index; typedef unsigned long XML_Size; #endif Even if undefined, the above declarations will change the return values of XML_GetCurrentLine/ColumnNumber from int to unsigned long. Hope that is not a problem (in theory, long >= int). Anyway, I'll apply the attached patch (LargeInt2.diff) sometime soon and create a pre-release for download. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-12-11 23:35 Message: Logged In: YES user_id=290026 Rolf, you are right about XML_GetCurrentLineNumber() and XML_GetCurrentColumnNumber(). The backwards compatibility is an issue for others, as far as I can tell, so I think I have it off by default. Attached is a patch I quickly put together today. Basic points: The switch is called "XML_LARGE_SIZE". I modified the type names to XML_Index (for signed large ints) and XML_Size (for unsigned large ints). If you have better names, let me know. Would you apply the patch and see how it works for you? (I assume long long works everywhere except Windows). Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-12-04 18:40 Message: Logged In: YES user_id=13222 Karl, I followed it. I must confess, I've no clear opinion about the backward compatibilty problem. For me, that is not a problem. I distribute the expat sources with my software and link it statically (so no problem even for binary distribution). One note: I don't think, that XML_GetCurrentLineNumber() and XML_GetCurrentColumnNumber() are seldom used calls. Any resonable XML processing software should be able to deal with the case, that it get feeded with not well-formed XML input. I'd guess, most programmers use that two calls to provide a usefull error msg to their users. I'm happy with any solution. I feel, it may be to much bloat (as you said) to have all that functions twice with different return type. So, I'd favour a build flag. (With the default 32 bit changed to 64 bit right after the 2.0 release). But I'm not really sure. Yes, I still have to provide some bits to check for a long long on unix plattforms, I now. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-30 09:31 Message: Logged In: YES user_id=290026 Rolf, I opened a discussion about this on the discussion list. The main issue - IMO - is backwards compatibility. I don't know how many apps on Linux, for instance, rely on the Expat API staying binary compatible. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-11-27 21:01 Message: Logged In: YES user_id=13222 XML_GetCurrentByteIndex() could return -1: Of course! You're right. And it makes sense. A freshly created or reseted parser without the first XML_Parse() call returns -1 on XML_GetCurrentByteIndex(), to signal this fact: it is not right at the start of the document, but there isn't any parsing started yet. Nice detail. I should have looked at the implementation, before replying. Note: That detail isn't mentioned in the documentation. I'm fine with a signed long long. 2^63 should be big enough, for the next few weeks ;-). Re the defines: Basically yes. It's just, that I'm pretty sure, we need one round more: some configure check for long long and depending on that result defining XML_?Int64 as long long or just long. I'll look something up (but being on deadline catching, may need a bit time). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 20:00 Message: Logged In: YES user_id=290026 On a 32bit CPU, 64bit integer operations are considerably slower than 32 bit operations. On the other hand XMLUpdatePosition isn't called that often - mostly when you actually request the line/column number. So, I agree - no configuration necessary. For the other point: If you look at the XML_GetCurrentByteIndex() code, it can return -1, and it is calculated using a subtraction. So in practice and theory, it must be a signed integer. XML_GetCurrentByteCount is derived from a subtraction as well, but we know it will be positive because eventEndPtr should always be larger than eventPtr. So we could risk using an unsigned integer. Just playing around, I added this to expat_external.h: #ifdef XML_USE_MSC_EXTENSIONS typedef __int64 XML_Int64; typedef unsigned __int64 XML_UInt64; #else typedef long long XML_Int64; typedef unsigned long long XML_UInt64; #endif What do you think? Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-11-27 19:33 Message: Logged In: YES user_id=13222 Configurable: No There is nearly no overhead: just a few variables (at max) 8 bytes long instead of 4 bytes. Also speedwise: not mesuarable. long long acceptable everywhere: Probably no Some very old or limited embedded system may not have a long long (or equivalent). Therefor we probably need defines. Byte index could be negative: don't think so. How could that happen? Byte index starts at 0 and grows. Or do I miss something.? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 18:21 Message: Logged In: YES user_id=290026 Just some notes, so that I don't forget - should it be configurable? some may not want the overhead of a 64bit integer, especially for line number and column number. - is long long acceptable everywhere else (other than VC++)? - the byte index could be negative, but not line/column number and byte count, right? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 15:31 Message: Logged In: YES user_id=290026 You are right, Rolf, it should be 64 bits even on a 32bit platform. I guess I should make a note in the docs that Expat supports > 2GB files, as long as each chunk passed to the XML_Parse routines is smaller than 2GB. There are also issues around compiling Expat on a 64bit platform, but at least for VC++, someone has provided a patch (bug # 1105135) which looks it should work on other platforms as well (just a bunch of type casts). One issue I have already seen is that VC++ 6.0 does not know about long long. Thanks for having a look at the cross-platform issue. I am trying to get Expat 2.0 released despite Fred not being active on Expat anymore. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2005-11-27 15:22 Message: Logged In: YES user_id=13222 Karl, Most reasonable 32bit platforms have support for file sizes > 2 GB these days even on 32. It was in fact a 32bit platform, at which I stumbled over the problem. That for your easy question. Much harder is how to slove this in a portable way. I'm afraid that may need platform depending #defines (with fallback to long). I'll go out digging what other portable software does in this case and will come back with a more concrete proposal. rolf ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 14:22 Message: Logged In: YES user_id=290026 Rolf, should the type be 64 bit integer on all platforms, or 32bit on 32bit platforms and 64bit on 64bit platforms? I think we are talking about m_parseEndByteIndex, POSITION.lineNumber and POSITION.columnNumber. Options could be size_t, ptrdiff_t. MS VC++ 6.0 does not know about long long, but it knows about __int64. Is there an ANSI definition for 64 bit ints? What do you suggest that works on all platforms? Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1284386&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:24:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:24:45 -0800 Subject: [Expat-bugs] [ expat-Bugs-1238204 ] Make check for expat-1.95.8 fails Message-ID: Bugs item #1238204, was opened at 2005-07-14 09:39 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1238204&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None Group: Test Required Status: Open >Resolution: Postponed Priority: 5 Submitted By: abhijitk (abhijitkankaria) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Make check for expat-1.95.8 fails Initial Comment: I have build expat 1.95.8 on Solaris 2.8 with the follwoing option: For UTF-16 output as wchar_t (incl. version/error strings),run: ./configure CFLAGS="-g -O2 -fshort-wchar" CPPFLAGS=-DXML_UNICODE_WCHAR_T It builds successfilly, now i want to run the test for expat it gives the following result as below: [me@:/mydir/expat-1.95.8] make check gcc -g -O2 -fshort-wchar -Wall -Wmissing-prototypes - Wstrict-prototypes -fexceptions - DHAVE_EXPAT_CONFIG_H - DXML_UNICODE_WCHAR_T -I./lib -I. -o tests/runtests.o -c tests/runtests.c tests/runtests.c: In function `_xml_failure': tests/runtests.c:57: warning: char format, different type arg (arg 3) tests/runtests.c: In function `_run_character_check': tests/runtests.c:225: warning: passing arg 1 of `strlen' from incompatible pointer type tests/runtests.c:225: warning: passing arg 2 of `XML_Parse' from incompatible pointer type tests/runtests.c: In function `_run_attribute_check': tests/runtests.c:242: warning: passing arg 1 of `strlen' from incompatible pointer type tests/runtests.c:242: warning: passing arg 2 of `XML_Parse' from incompatible pointer type tests/runtests.c: In function `test_danish_latin1': tests/runtests.c:256: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:256: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_french_charref_hexidecimal': tests/runtests.c:268: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:268: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_french_charref_decimal': tests/runtests.c:278: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:278: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_french_latin1': tests/runtests.c:288: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:288: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_french_utf8': tests/runtests.c:298: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:298: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_utf8_false_rejection': tests/runtests.c:310: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:310: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_latin1_umlauts': tests/runtests.c:392: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:392: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c:394: warning: passing arg 1 of `_run_attribute_check' from incompatible pointer type tests/runtests.c:394: warning: passing arg 2 of `_run_attribute_check' from incompatible pointer type tests/runtests.c: In function `start_element_event_handler2': tests/runtests.c:444: warning: char format, different type arg (arg 3) tests/runtests.c: In function `end_element_event_handler2': tests/runtests.c:456: warning: char format, different type arg (arg 3) tests/runtests.c: In function `testhelper_is_whitespace_normalized': tests/runtests.c:645: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:646: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:647: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:648: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:649: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:650: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:651: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:652: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:653: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:654: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:655: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:656: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:657: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:658: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:659: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:660: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:661: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:662: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c:663: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type tests/runtests.c: In function `check_attr_contains_normalized_whitespace': tests/runtests.c:675: warning: passing arg 2 of `strcmp' from incompatible pointer type tests/runtests.c:676: warning: passing arg 2 of `strcmp' from incompatible pointer type tests/runtests.c:677: warning: passing arg 2 of `strcmp' from incompatible pointer type tests/runtests.c:681: warning: char format, different type arg (arg 3) tests/runtests.c:681: warning: char format, different type arg (arg 4) tests/runtests.c: In function `UnknownEncodingHandler': tests/runtests.c:730: warning: passing arg 1 of `strcmp' from incompatible pointer type tests/runtests.c: In function `external_entity_loader_set_encoding': tests/runtests.c:774: warning: passing arg 2 of `XML_SetEncoding' from incompatible pointer type tests/runtests.c: In function `test_ext_entity_set_encoding': tests/runtests.c:794: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:794: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `test_dtd_default_handling': tests/runtests.c:933: warning: passing arg 1 of `_run_character_check' from incompatible pointer type tests/runtests.c:933: warning: passing arg 2 of `_run_character_check' from incompatible pointer type tests/runtests.c: In function `triplet_start_checker': tests/runtests.c:1003: warning: passing arg 2 of `strcmp' from incompatible pointer type tests/runtests.c:1004: warning: char format, different type arg (arg 3) tests/runtests.c:1007: warning: passing arg 2 of `strcmp' from incompatible pointer type tests/runtests.c:1008: warning: char format, different type arg (arg 3) tests/runtests.c: In function `triplet_end_checker': tests/runtests.c:1021: warning: passing arg 2 of `strcmp' from incompatible pointer type tests/runtests.c:1023: warning: char format, different type arg (arg 3) tests/runtests.c: In function `main': tests/runtests.c:1427: warning: char format, different type arg (arg 2) gcc -g -O2 -fshort-wchar -Wall -Wmissing-prototypes - Wstrict-prototypes -fexceptions - DHAVE_EXPAT_CONFIG_H - DXML_UNICODE_WCHAR_T -I./lib -I. -o tests/chardata.o -c tests/chardata.c tests/chardata.c: In function `CharData_CheckString': tests/chardata.c:96: warning: char format, different type arg (arg 5) gcc -g -O2 -fshort-wchar -Wall -Wmissing-prototypes - Wstrict-prototypes -fexceptions - DHAVE_EXPAT_CONFIG_H - DXML_UNICODE_WCHAR_T -I./lib -I. -o tests/minicheck.o -c tests/minicheck.c /bin/bash ./libtool --silent --mode=link gcc -g -O2 -fshort- wchar -Wall -Wmissing-prototypes -Wstrict-prototypes - fexceptions -DHAVE_EXPAT_CONFIG_H - DXML_UNICODE_WCHAR_T -I./lib -I. -o tests/runtests tests/runtests.o tests/chardata.o tests/minicheck.o libexpatw.la tests/runtests Assertion failed: !is_whitespace_normalized(" abc def ghi", 0), file tests/runtests.c, line 649 make: *** [check] Abort (core dumped) [me@:/mydir/expat-1.95.8] ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:24 Message: Logged In: YES user_id=290026 Yes, the tests are not written for non-default configurations. "make check" should not be executed when building Expat for UTF-16 output. If you like you can supply a patch to add this capability, since I doubt any of us will have the time to do it. ---------------------------------------------------------------------- Comment By: abhijitk (abhijitkankaria) Date: 2005-07-19 17:02 Message: Logged In: YES user_id=1312629 I did some study on this and my theory is that may be the test code of expat is not updated to support wchar_t, I have build the expat with -fshore_wchar and -DXML_UNICODE_WCHAR_T compiler option, but in the test code the input values to functions are passed as XML_Char i.e wchar_t in my case, infact this should be char as expat library takes input as char and not wide char. It gives a bunch of warnings while compilation like mentioned below and results in segmentation fault during execution of tests. tests/runtests.c: In function `end_element_event_handler2': tests/runtests.c:456: warning: char format, different type arg (arg 3) tests/runtests.c: In function `testhelper_is_whitespace_normalized': tests/runtests.c:645: warning: passing arg 1 of `is_whitespace_normalized' from incompatible pointer type Also when expat is build it uses the libtool to create the library (libexpatw.la) and while compiling the tests for expat using "make check" it used the object files created by gcc compiler with ext .o and library created by libtool with extension .la. According to the manual of libtool this type of combination should not compile, but in this case it does compile and result in segmentation fault while execution. I tried modifying the make file of expat to build object files with .lo using libtool for the test files instead of .o using gcc compiler, but it gives the same result of segmentation fault. 2. I modified the current test files for expat to have input as char instead of XML_Char i.e. wchar_t as per the compiler options. Now the test (tests/runtests) of expat executes with no segmentation fault but all of them are not successful. [me@:/mydir/expat-1.95.8] tests/runtests 66%: Checks: 48, Failed: 16 [me@:/mydir/expat-1.95.8] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1238204&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:34:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:34:26 -0800 Subject: [Expat-bugs] [ expat-Bugs-1230582 ] "make all" fails for libexpat Message-ID: Bugs item #1230582, was opened at 2005-06-30 16:19 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1230582&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: ken klein (kklein9) Assigned to: Greg Stein (gstein) Summary: "make all" fails for libexpat Initial Comment: aix 5.3 ml 02 power 5 on pSeries p570 partition. The complete output from the make all failure is below: root at f2sys1 (2133)[/home/ken/expat/expat-1.95.8]# make all /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONF IG_H -I./lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./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 ld: 0711-415 WARNING: Symbol _GLOBAL__F_XML_ParserCreate is already exported. ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlUtf8Encode is already exported. ld: 0711-415 WARNING: Symbol _GLOBAL__F_XmlPrologStateInit is already exported. gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/xmlwf.o -c xml wf/xmlwf.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/xmlfile.o -c x mlwf/xmlfile.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/codepage.o -c xmlwf/codepage.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o xmlwf/readfilemap.o -c xmlwf/readfilemap.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o libexpat.la gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I./lib -I. -o examples/elements.o -c examples/elements.c /bin/sh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_ H -I./lib -I. -o examples/elements libexpat.la ld: 0711-317 ERROR: Undefined symbol: .main ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:34 Message: Logged In: YES user_id=290026 I am not an AIX expert, and it appears no one else here is either. If you haven't found a solution, there is a link where you can download a binary build: http://aixpdslib.seas.ucla.edu/packages/expat.html Closing this issue as it looks like this is not an issue with Expat, given the link above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1230582&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:39:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:39:34 -0800 Subject: [Expat-bugs] [ expat-Bugs-1221160 ] storeAtts can trash tempPool Message-ID: Bugs item #1221160, was opened at 2005-06-15 09:15 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1221160&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peter Van der Beken (peter_vdb) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: storeAtts can trash tempPool Initial Comment: I ran into what I think is a bug in storeAtts. While looping over appAtts there's a small optimization to bail out early when nPrefixes is 0. The code then loops over the remaining attributes and does |((XML_Char *)(appAtts[i]))[-1] = 0;|. The problem is that because of the early bail out i didn't get incremented, and just before bailing out the code sets |appAtts[i] = s;| with s coming out of the tempPool, so in the second loop we end up nulling some memory inside the tempPool. One solution consists in incrementing i just before bailing out (I'm attaching a patch that does this). Another solution would be to make the first loop be |for (; nPrefixes && i < attIndex; i += 2) {| and drop the early bail-out. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:39 Message: Logged In: YES user_id=290026 Since Fred is not active anymore, there is no-one to write a test case. Closing the issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-06-15 10:25 Message: Logged In: YES user_id=290026 I believe you are correct. Fixed in xmlparse.cs rev. 1.148. Need to run a few tests with namespaces on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1221160&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:46:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:46:17 -0800 Subject: [Expat-bugs] [ expat-Bugs-1212506 ] exception handling under Solaris 9 Message-ID: Bugs item #1212506, was opened at 2005-06-01 04:00 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1212506&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: exception handling under Solaris 9 Initial Comment: I'm using expat version 1.95.8 and getting SIGABRT under Solaris 9 when I'm trying to throw exception somewhere at the element handler and expat library was linked dynamically. When I link expat to my application statically, exceptions are handled well. When I dynamically link expat to my application under Linux platform such as SuSE or Mandrake exceptions are handled fine too. Here's the result of debugging: Program received signal SIGABRT, Aborted. 0xff21d544 in _libc_kill () from /usr/lib/libc.so.1 (gdb) bt #0 0xff21d544 in _libc_kill () from /usr/lib/libc.so.1 #1 0xff1b56b0 in abort () from /usr/lib/libc.so.1 #2 0xff2da7f8 in __cxxabiv1::__terminate(void (*)()) ( handler=0xff1b55a8 ) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47 #3 0xff2da848 in std::terminate() () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57 I also attached small sample that causes described crash when compiled and executed if expat linked dynamically. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:46 Message: Logged In: YES user_id=290026 According to Gerrit P. Haase this is a libtool bug and should be fixed with libtool version >= 1.5, which is used for the Expat 2.0 release. Closing the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1212506&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:47:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:47:16 -0800 Subject: [Expat-bugs] [ expat-Bugs-1211302 ] building 2005-01-28 with mingw/msys Message-ID: Bugs item #1211302, was opened at 2005-05-30 08:31 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1211302&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Gerrit P. Haase (siebenschlaefer) Summary: building 2005-01-28 with mingw/msys Initial Comment: The libtool fails for some reason. I have no idea how to debug/improve this so I will try to use a prebuilt version. /usr/src/expat-2005-01-28 $ make /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -no-undefined -version-info 5:0:5 -rpath /usr/local/lib -L/aspell/lib -L/gw32/lib/ -L/mingw/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo Creating library file: .libs/libexpat.dll.a gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o xmlwf/codepage.o -c xmlwf/codepage.c gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -o xmlwf/readfilemap.o -c xmlwf/readfilemap.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -I/aspell/include -I/gw32/include/ -I/mingwlib/include -L/aspell/lib -L/gw32/lib/ -L/mingw/lib -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o libexpat.la ./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or directory ./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or directory ./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or directory ./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or directory ./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or directory ./libtool: .libs/lt-xmlwf/xmlwf.c: No such file or directory gcc.exe: .libs/lt-xmlwf/xmlwf.c: No such file or directory gcc.exe: no input files ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:47 Message: Logged In: YES user_id=290026 According to Gerrit P. Haase this is a libtool bug and should be fixed with libtool version >= 1.5, which is used for the Expat 2.0 release. Closing the issue. ---------------------------------------------------------------------- Comment By: Gerrit P. Haase (siebenschlaefer) Date: 2005-11-28 12:49 Message: Logged In: YES user_id=76037 This only happens when using an old libtool release like the one included with the released tarball. I always replace ltmain.sh and libtool.m4 with the latest Cygwin version when doing a binary release for Cygwin. If Karl is going to make the next release on his Cygwin installation it should be fixed this way. So basically it is a libtool bug. If you want to build the 1.95.8 release, fetch the source tarball form one of the Cygwin mirrors and use that instead of the official source release. Gerrit ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-06-15 08:40 Message: Logged In: YES user_id=290026 Assigned to our Cygwin expert. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1211302&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:55:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:55:30 -0800 Subject: [Expat-bugs] [ expat-Bugs-1217217 ] Expat 1.95.8 does not obey $DESTDIR on install Message-ID: Bugs item #1217217, was opened at 2005-06-08 16:12 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1217217&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Expat 1.95.8 does not obey $DESTDIR on install Initial Comment: Submitted by mjbauer (at) rent-a-clue (dot) com The Makefile.in in src/ in the build tree has no references whatsoever to $DESTDIR or ${DESTDIR}. The environment variable is utterly ignored on make install run against the generated Makefile. I have edited Makefile.in to properly obey $DESTDIR; below is a diff of the old and new versions. Please include a $DESTDIR-obeying Makefile.in in future releases. > diff Makefile.in.old Makefile.in 76,78c76,78 < $(mkinstalldirs) $(bindir) $(man1dir) < $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf < $(INSTALL_DATA) $(MANFILE) $(man1dir) --- > $(mkinstalldirs) ${DESTDIR}$(bindir) ${DESTDIR}$(man1dir) > $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf > ${DESTDIR}$(bindir)/xmlwf > $(INSTALL_DATA) $(MANFILE) ${DESTDIR}$(man1dir) 81,83c81,83 < $(mkinstalldirs) $(libdir) $(includedir) < $(LIBTOOL) --mode=install $(INSTALL) $(LIBRARY) > $(libdir)/$(LIBRARY) < $(INSTALL_DATA) $(APIHEADER) $(includedir) --- > $(mkinstalldirs) ${DESTDIR}$(libdir) ${DESTDIR}$(includedir) > $(LIBTOOL) --mode=install $(INSTALL) $(LIBRARY) > ${DESTDIR}$(libdir)/$(LIBRARY) > $(INSTALL_DATA) $(APIHEADER) ${DESTDIR}$(includedir) 86,87c86,87 < $(LIBTOOL) --mode=uninstall rm -f $(bindir)/xmlwf < rm -f $(man1dir)/xmlwf.1 --- > $(LIBTOOL) --mode=uninstall rm -f ${DESTDIR}$(bindir)/xmlwf > rm -f ${DESTDIR}$(man1dir)/xmlwf.1 90,91c90,91 < $(LIBTOOL) --mode=uninstall rm -f $(libdir)/$(LIBRARY) < rm -f $(includedir)/$(APIHEADER) --- > $(LIBTOOL) --mode=uninstall rm -f > ${DESTDIR}$(libdir)/$(LIBRARY) > rm -f ${DESTDIR}$(includedir)/$(APIHEADER) ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:55 Message: Logged In: YES user_id=290026 In Makefile.in rev. 1.48 this was added: ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif and seems to work. Closing issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-06-15 08:42 Message: Logged In: YES user_id=290026 Fred, you are better on make files. Assigned to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1217217&group_id=10127 From noreply at sourceforge.net Fri Jan 13 01:58:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:58:41 -0800 Subject: [Expat-bugs] [ expat-Bugs-1124544 ] expat.dsw and *.dsp unix line endings Message-ID: Bugs item #1124544, was opened at 2005-02-17 02:48 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1124544&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.dsw and *.dsp unix line endings Initial Comment: expat-1.95.8.tar.gz expat.dsw and *.dsp all have unix line endings, and MSVS6 doesn't like that please take care to change those when releasing tarballs ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 19:58 Message: Logged In: YES user_id=290026 Fixed in tarball for Expat 2.0. Closing the issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-02-17 08:49 Message: Logged In: YES user_id=290026 Only you can do that, Fred. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1124544&group_id=10127 From noreply at sourceforge.net Fri Jan 13 02:00:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 17:00:25 -0800 Subject: [Expat-bugs] [ expat-Bugs-1171968 ] Solaris 9 build version 1.95.8 Message-ID: Bugs item #1171968, was opened at 2005-03-28 12:10 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1171968&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Solaris 9 build version 1.95.8 Initial Comment: After running ./configure on Solaris 9 and executing make the following errors occur: "lib/xmlparse.c", line 855: parsing: macro recursion "lib/xmlparse.c", line 918: parsing: macro recursion "lib/xmlparse.c", line 918: parsing: macro recursion "lib/xmlparse.c", line 919: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 925: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 927: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1146: parsing: macro recursion "lib/xmlparse.c", line 1146: parsing: macro recursion "lib/xmlparse.c", line 1159: parsing: macro recursion "lib/xmlparse.c", line 1159: parsing: macro recursion "lib/xmlparse.c", line 1179: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1184: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1411: parsing: macro recursion "lib/xmlparse.c", line 1411: parsing: macro recursion "lib/xmlparse.c", line 1424: parsing: macro recursion "lib/xmlparse.c", line 1427: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1430: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1432: parsing: macro recursion "lib/xmlparse.c", line 1436: finalBuffer: macro recursion "lib/xmlparse.c", line 1438: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1449: parsing: macro recursion "lib/xmlparse.c", line 1453: XML_STATUS_SUSPENDED: macro recursion "lib/xmlparse.c", line 1456: parsing: macro recursion "lib/xmlparse.c", line 1459: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1464: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1530: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1542: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1544: parsing: macro recursion "lib/xmlparse.c", line 1547: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1550: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1552: parsing: macro recursion "lib/xmlparse.c", line 1560: finalBuffer: macro recursion "lib/xmlparse.c", line 1567: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1570: parsing: macro recursion "lib/xmlparse.c", line 1572: XML_STATUS_SUSPENDED: macro recursion "lib/xmlparse.c", line 1577: parsing: macro recursion "lib/xmlparse.c", line 1592: parsing: macro recursion "lib/xmlparse.c", line 1671: parsing: macro recursion "lib/xmlparse.c", line 1675: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1677: parsing: macro recursion "lib/xmlparse.c", line 1681: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1687: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1690: parsing: macro recursion "lib/xmlparse.c", line 1693: parsing: macro recursion "lib/xmlparse.c", line 1695: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1701: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1703: parsing: macro recursion "lib/xmlparse.c", line 1705: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1707: parsing: macro recursion "lib/xmlparse.c", line 1714: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1717: parsing: macro recursion "lib/xmlparse.c", line 1719: XML_STATUS_SUSPENDED: macro recursion "lib/xmlparse.c", line 1723: finalBuffer: macro recursion "lib/xmlparse.c", line 1724: parsing: macro recursion "lib/xmlparse.c", line 2003: finalBuffer: macro recursion "lib/xmlparse.c", line 2039: finalBuffer: macro recursion "lib/xmlparse.c", line 2046: finalBuffer: macro recursion "lib/xmlparse.c", line 2053: finalBuffer: macro recursion "lib/xmlparse.c", line 2083: parsing: macro recursion "lib/xmlparse.c", line 2095: finalBuffer: macro recursion "lib/xmlparse.c", line 2101: finalBuffer: macro recursion "lib/xmlparse.c", line 2119: finalBuffer: macro recursion "lib/xmlparse.c", line 2569: parsing: macro recursion "lib/xmlparse.c", line 2988: finalBuffer: macro recursion "lib/xmlparse.c", line 3047: parsing: macro recursion "lib/xmlparse.c", line 3103: parsing: macro recursion "lib/xmlparse.c", line 3127: finalBuffer: macro recursion "lib/xmlparse.c", line 3172: parsing: macro recursion "lib/xmlparse.c", line 3412: finalBuffer: macro recursion "lib/xmlparse.c", line 3435: parsing: macro recursion "lib/xmlparse.c", line 3455: finalBuffer: macro recursion "lib/xmlparse.c", line 3475: finalBuffer: macro recursion "lib/xmlparse.c", line 3502: finalBuffer: macro recursion "lib/xmlparse.c", line 3519: finalBuffer: macro recursion "lib/xmlparse.c", line 3552: finalBuffer: macro recursion "lib/xmlparse.c", line 4499: parsing: macro recursion "lib/xmlparse.c", line 4530: parsing: macro recursion "lib/xmlparse.c", line 4554: finalBuffer: macro recursion "lib/xmlparse.c", line 4560: finalBuffer: macro recursion "lib/xmlparse.c", line 4569: parsing: macro recursion "lib/xmlparse.c", line 4622: parsing: macro recursion "lib/xmlparse.c", line 4668: parsing: macro recursion "lib/xmlparse.c", line 4686: finalBuffer: macro recursion "lib/xmlparse.c", line 4694: finalBuffer: macro recursion Updating xmlparse.c and expat.h from CVS results in fewer errors for the same type, as well as additional errors due to undefined variables/functions. email: dejan.nikolic at veritas.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 20:00 Message: Logged In: YES user_id=290026 Not really an Expat bug. Closing the issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-03-29 08:11 Message: Logged In: YES user_id=290026 Either switch to gcc (it is free), or investigate if there are compiler options which increase standards adherence. In the latter case the configure script could be fixed, I guess. ---------------------------------------------------------------------- Comment By: Dejan Nikolic (dnikolic) Date: 2005-03-28 15:47 Message: Logged In: YES user_id=1248125 Unfortunatelly compiler upgrade is not an option. Any other workarounds? Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-03-28 14:06 Message: Logged In: YES user_id=290026 Looks like a compiler issue. Can you upgrade your compiler, or switch to gcc? ---------------------------------------------------------------------- Comment By: Dejan Nikolic (dnikolic) Date: 2005-03-28 13:44 Message: Logged In: YES user_id=1248125 Kevin, pulled in a whole lib 1.76 revision and am still getting errors. Here they are: "lib/xmlparse.c", line 921: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 927: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 929: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1181: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1186: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1429: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1432: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1440: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1455: XML_STATUS_SUSPENDED: macro recursion "lib/xmlparse.c", line 1461: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1466: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1535: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1547: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1552: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1555: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1572: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1577: XML_STATUS_SUSPENDED: macro recursion "lib/xmlparse.c", line 1680: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1686: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1692: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1700: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1706: XML_STATUS_OK: macro recursion "lib/xmlparse.c", line 1710: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1719: XML_STATUS_ERROR: macro recursion "lib/xmlparse.c", line 1724: XML_STATUS_SUSPENDED: macro recursion Aparently if does not like redefinitions of macros. Compiler is cc version: Sun WorkShop 6 update 2 C 5.3 2001/05/15 Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-03-28 12:25 Message: Logged In: YES user_id=290026 We had a similar problem in bug # 1021776. It was a compiler issue, however, we implemented a small workaround. Which compiler are you using? Btw, you should update *all* files from CVS, not just selected ones. Try again with everything at CVS revision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1171968&group_id=10127 From noreply at sourceforge.net Fri Jan 13 02:03:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 17:03:14 -0800 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 (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1095888&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected 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 at smius.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-12 20:03 Message: Logged In: YES user_id=290026 Problem seems to have been solved. Closing issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-02-23 03:09 Message: Logged In: NO make fails on mandrake linux,konsole terminal, the following message is displayed: : *** No rule to make target `lib/xmlparse.lo', needed by `libexpat.la'. Stop. I tried to change the line related to lib/xmlparse.lo in the make file, but no changes ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-02-10 10:38 Message: Logged In: NO Sorry Fred. You're right. When I compiled with the missing .h I got a heap of errors. I thought that they were similar to the ones reported here. On closer inspection of these errors I realise they differ. If its any consolation I had no further problems installing 1.95.8 on Solaris 9 once I fixed the missing ".h" file. Once again sorry for wasting your time. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-02-10 09:38 Message: Logged In: YES user_id=3066 donsi: This has nothing to do with the installation problem you observed (which has already been fixed in CVS) or bug #1114960 which you cite. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-02-10 08:53 Message: Logged In: YES user_id=290026 I guess you should try the CVS version of Expat. ---------------------------------------------------------------------- Comment By: donsi (donsi) Date: 2005-02-10 06:21 Message: Logged In: YES user_id=1216186 I have found this problem too today while trying to install on solaris 9. I tracked the problem down to the following line in Makefile.in: $(INSTALL_DATA) $(APIHEADER) $(includedir) At build time, this expands out to something like: conftools/install-sh -c -m 644 ./lib/expat.h ./lib/expat_external.h installdir/include On solaris at least, it appears that install-sh does not handle installing multiple files. As a consequence the expat_external.h is not installed. A manual workaround to this problem is to install the expat_external.h file by hand. I think this bug is related to 1114960. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-05 14: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 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 Fri Jan 13 02:05:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 17:05:52 -0800 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 kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1063934&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Third-party Bug >Status: Closed >Resolution: Fixed 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 at 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 at 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: Karl Waclawek (kwaclaw) Date: 2006-01-12 20:05 Message: Logged In: YES user_id=290026 The Expat 2.0 tarball uses libtool 1.5.22, so this issue is fixed, according to Gerrit P. Haase. Closing issue. ---------------------------------------------------------------------- Comment By: Gerrit P. Haase (siebenschlaefer) Date: 2005-11-28 12:58 Message: Logged In: YES user_id=76037 See: http://sourceforge.net/tracker/index.php?func=detail&aid=1211302&group_id=10127&atid=110127 ---------------------------------------------------------------------- Comment By: heromyth (heromyth) Date: 2005-03-27 23:01 Message: Logged In: YES user_id=1190746 Use the newer script to do Make, just get a static lib, there is no shared lib. ---------------------------------------------------------------------- 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 Fri Jan 13 02:08:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 17:08:42 -0800 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 kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=863550&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Feature Request >Status: Closed >Resolution: Fixed 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: Karl Waclawek (kwaclaw) Date: 2006-01-12 20:08 Message: Logged In: YES user_id=290026 The Expat 2.0 tarball was made using libtool 1.5.22. Closing the issue. ---------------------------------------------------------------------- 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 Fri Jan 13 14:52:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 05:52:34 -0800 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 kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1105135&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Henrik Goldman (hgoldman) Assigned to: Karl Waclawek (kwaclaw) 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: Karl Waclawek (kwaclaw) Date: 2006-01-13 08:52 Message: Logged In: YES user_id=290026 No issues reported. Closing this bug. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-28 15:12 Message: Logged In: YES user_id=290026 Applied the type casts in xmlparse.c rev. 1.150 and xmltok_impl.c rev. 1.11. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2005-11-27 15:44 Message: Logged In: YES user_id=290026 It seems this patch should work on other platforms as well. I'll have a look at this together with issue # 1284386. Karl ---------------------------------------------------------------------- Comment By: Henrik Goldman (hgoldman) Date: 2005-03-27 06:52 Message: Logged In: YES user_id=798004 I don't understand why anyone hasn't looked at the patches yet? Sooner or later you will get more of these Win64 x64 requests because it's soon to be released as final and then people will want to write software for it. The patches I submitted are quite trivial which you will see when looking through them. Thanks. ---------------------------------------------------------------------- Comment By: Henrik Goldman (hgoldman) Date: 2005-02-07 10:11 Message: Logged In: YES user_id=798004 So did anyone look at the patch? ---------------------------------------------------------------------- Comment By: Henrik Goldman (hgoldman) Date: 2005-01-30 10: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 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 Fri Jan 13 21:33:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 12:33:41 -0800 Subject: [Expat-bugs] [ expat-Bugs-1405186 ] LF sent to CharacterDataHandler Message-ID: Bugs item #1405186, was opened at 2006-01-13 15:33 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=1405186&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Baker (sbaker48) Assigned to: Nobody/Anonymous (nobody) Summary: LF sent to CharacterDataHandler Initial Comment: I just compiled v2.0.0 VC++ on Windows as a static library. After the data inside a tag is sent to the CharacterDataHandler, I get one or more calls to the handler with a length of 1, containing the LF character (0x0a). If there is a compiler setting or file encoding setting that makes this go away, I have not yet found it. --Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 From noreply at sourceforge.net Fri Jan 13 21:55:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 12:55:14 -0800 Subject: [Expat-bugs] [ expat-Bugs-1405186 ] LF sent to CharacterDataHandler Message-ID: Bugs item #1405186, was opened at 2006-01-13 15:33 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Baker (sbaker48) Assigned to: Nobody/Anonymous (nobody) Summary: LF sent to CharacterDataHandler Initial Comment: I just compiled v2.0.0 VC++ on Windows as a static library. After the data inside a tag is sent to the CharacterDataHandler, I get one or more calls to the handler with a length of 1, containing the LF character (0x0a). If there is a compiler setting or file encoding setting that makes this go away, I have not yet found it. --Sean ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-13 15:55 Message: Logged In: YES user_id=290026 Are there associated line breaks in the input? If yes, then this is correct behaviour, as required by the specs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 From noreply at sourceforge.net Fri Jan 13 22:05:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 13:05:12 -0800 Subject: [Expat-bugs] [ expat-Bugs-1405186 ] LF sent to CharacterDataHandler Message-ID: Bugs item #1405186, was opened at 2006-01-13 15:33 Message generated for change (Comment added) made by sbaker48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Baker (sbaker48) Assigned to: Nobody/Anonymous (nobody) Summary: LF sent to CharacterDataHandler Initial Comment: I just compiled v2.0.0 VC++ on Windows as a static library. After the data inside a tag is sent to the CharacterDataHandler, I get one or more calls to the handler with a length of 1, containing the LF character (0x0a). If there is a compiler setting or file encoding setting that makes this go away, I have not yet found it. --Sean ---------------------------------------------------------------------- >Comment By: Sean Baker (sbaker48) Date: 2006-01-13 16:05 Message: Logged In: YES user_id=1426840 Sorry, I realise what the problem was now. There were no line breaks in the data until after the closing tag, and I had thought I was getting the callback before I received the EndHandler callback. But it now appears that I was not, my breakpoint on the end handler had gotten misplaced. Everything is functioning properly. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-13 15:55 Message: Logged In: YES user_id=290026 Are there associated line breaks in the input? If yes, then this is correct behaviour, as required by the specs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 From noreply at sourceforge.net Fri Jan 13 22:15:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 13:15:34 -0800 Subject: [Expat-bugs] [ expat-Bugs-1405186 ] LF sent to CharacterDataHandler Message-ID: Bugs item #1405186, was opened at 2006-01-13 15:33 Message generated for change (Settings changed) made by sbaker48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Sean Baker (sbaker48) Assigned to: Nobody/Anonymous (nobody) Summary: LF sent to CharacterDataHandler Initial Comment: I just compiled v2.0.0 VC++ on Windows as a static library. After the data inside a tag is sent to the CharacterDataHandler, I get one or more calls to the handler with a length of 1, containing the LF character (0x0a). If there is a compiler setting or file encoding setting that makes this go away, I have not yet found it. --Sean ---------------------------------------------------------------------- Comment By: Sean Baker (sbaker48) Date: 2006-01-13 16:05 Message: Logged In: YES user_id=1426840 Sorry, I realise what the problem was now. There were no line breaks in the data until after the closing tag, and I had thought I was getting the callback before I received the EndHandler callback. But it now appears that I was not, my breakpoint on the end handler had gotten misplaced. Everything is functioning properly. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-13 15:55 Message: Logged In: YES user_id=290026 Are there associated line breaks in the input? If yes, then this is correct behaviour, as required by the specs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1405186&group_id=10127 From noreply at sourceforge.net Tue Jan 17 13:20:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 04:20:49 -0800 Subject: [Expat-bugs] [ expat-Bugs-1408143 ] "make check" failure Message-ID: Bugs item #1408143, was opened at 2006-01-17 04:20 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=1408143&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: "make check" failure Initial Comment: From: Peter Breitenlohner expat-2.0.0 When running "make check" (with VPATH, i.e. outside the source tree), g++ was invoked without any '-I' and thus has included some old installed headers from 1.95.8 resulting in a compilation error due to the missing declaration of XML_Size. Attached is a small patch fixing this. The patch also makes a difference between CFLAGS and CXXFLAGS in order to avoid the warnings that g++ doesn't want "-Wmissing-prototypes -Wstrict-prototypes". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1408143&group_id=10127 From noreply at sourceforge.net Wed Jan 18 23:04:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 14:04:58 -0800 Subject: [Expat-bugs] [ expat-Bugs-1409451 ] Missing XML_UNICODE_WCHAR_T define in VisualC project Message-ID: Bugs item #1409451, was opened at 2006-01-18 14:04 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=1409451&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Missing XML_UNICODE_WCHAR_T define in VisualC project Initial Comment: Not sure if this is a bug, it seems like that. There's a missing XML_UNICODE_WCHAR_T #define in the Microsoft Visual Studio project file expatw_static.dsp, in the "Win32 debug" build configuration. It is correctly there for the "Win32 release" configuration in the same project file. In this case the expatw_static library is not correctly compiled in debug with UTF-16 as it should be. This problem is present in release 1.95.8 and 2.0.0. Roal Zanazzi roal.zanazzi at tiscali.it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1409451&group_id=10127 From noreply at sourceforge.net Thu Jan 19 02:05:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 17:05:22 -0800 Subject: [Expat-bugs] [ expat-Bugs-1409451 ] Missing XML_UNICODE_WCHAR_T define in VisualC project Message-ID: Bugs item #1409451, was opened at 2006-01-18 17:04 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1409451&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Missing XML_UNICODE_WCHAR_T define in VisualC project Initial Comment: Not sure if this is a bug, it seems like that. There's a missing XML_UNICODE_WCHAR_T #define in the Microsoft Visual Studio project file expatw_static.dsp, in the "Win32 debug" build configuration. It is correctly there for the "Win32 release" configuration in the same project file. In this case the expatw_static library is not correctly compiled in debug with UTF-16 as it should be. This problem is present in release 1.95.8 and 2.0.0. Roal Zanazzi roal.zanazzi at tiscali.it ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-18 20:05 Message: Logged In: YES user_id=290026 Yes, I agree, the #define is missing. Corrected in expatw_static.dsp rev. 1.6. Closing this issue as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1409451&group_id=10127 From noreply at sourceforge.net Fri Jan 20 15:02:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 06:02:39 -0800 Subject: [Expat-bugs] [ expat-Bugs-1410812 ] XML in XML; Message-ID: Bugs item #1410812, was opened at 2006-01-20 06:02 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=1410812&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML in XML; Initial Comment: BUG in 1.95.8 and 2.0: Expat has with embedded xml with against-manufactures problems. To Parsende the XML looks so out: <?xml version="1.0" encoding="UTF-8"?> <signal> <outputrate>1</outputrate> </signal> which from it comes out looks then so out: <--that is ok <--that is wrong between the attributes version and encoding that blank is removed 1<--that is ok thanks many for the assistance ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 From noreply at sourceforge.net Fri Jan 20 16:29:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 07:29:43 -0800 Subject: [Expat-bugs] [ expat-Bugs-1410812 ] XML in XML; Message-ID: Bugs item #1410812, was opened at 2006-01-20 09:02 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML in XML; Initial Comment: BUG in 1.95.8 and 2.0: Expat has with embedded xml with against-manufactures problems. To Parsende the XML looks so out: <?xml version="1.0" encoding="UTF-8"?> <signal> <outputrate>1</outputrate> </signal> which from it comes out looks then so out: <--that is ok <--that is wrong between the attributes version and encoding that blank is removed 1<--that is ok thanks many for the assistance ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-20 10:29 Message: Logged In: YES user_id=290026 Works fine for me. Are you taking into account that the character data handler can be called multiple times for a contigues string of characters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 From noreply at sourceforge.net Mon Jan 23 15:04:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 06:04:52 -0800 Subject: [Expat-bugs] [ expat-Bugs-1410812 ] XML in XML; Message-ID: Bugs item #1410812, was opened at 2006-01-20 06:02 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML in XML; Initial Comment: BUG in 1.95.8 and 2.0: Expat has with embedded xml with against-manufactures problems. To Parsende the XML looks so out: <?xml version="1.0" encoding="UTF-8"?> <signal> <outputrate>1</outputrate> </signal> which from it comes out looks then so out: <--that is ok <--that is wrong between the attributes version and encoding that blank is removed 1<--that is ok thanks many for the assistance ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-01-23 06:04 Message: Logged In: NO Many thanks for your efforts. This error is located by our side! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-20 07:29 Message: Logged In: YES user_id=290026 Works fine for me. Are you taking into account that the character data handler can be called multiple times for a contigues string of characters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 From noreply at sourceforge.net Mon Jan 23 15:15:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 06:15:56 -0800 Subject: [Expat-bugs] [ expat-Bugs-1410812 ] XML in XML; Message-ID: Bugs item #1410812, was opened at 2006-01-20 09:02 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML in XML; Initial Comment: BUG in 1.95.8 and 2.0: Expat has with embedded xml with against-manufactures problems. To Parsende the XML looks so out: <?xml version="1.0" encoding="UTF-8"?> <signal> <outputrate>1</outputrate> </signal> which from it comes out looks then so out: <--that is ok <--that is wrong between the attributes version and encoding that blank is removed 1<--that is ok thanks many for the assistance ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-23 09:15 Message: Logged In: YES user_id=290026 Closing the issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-01-23 09:04 Message: Logged In: NO Many thanks for your efforts. This error is located by our side! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-20 10:29 Message: Logged In: YES user_id=290026 Works fine for me. Are you taking into account that the character data handler can be called multiple times for a contigues string of characters? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1410812&group_id=10127 From mostman at gmail.com Tue Jan 24 20:04:20 2006 From: mostman at gmail.com (Mike Ostman) Date: Tue, 24 Jan 2006 14:04:20 -0500 Subject: [Expat-bugs] question about [ and ] inside CDATA tags Message-ID: I am trying to specify a CDATA element where the data has hard brackets. Specifically - here is my example: First - this is legal - correct? I opened the file in some XML editors and it seemed to parse just fine. When I parsed this with expat - all I get back in my CDATA handler is "]" (The closing hard bracket) Has anyone else noticed this? Thank you in advance- -Mike From noreply at sourceforge.net Tue Jan 24 22:25:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 13:25:58 -0800 Subject: [Expat-bugs] [ expat-Bugs-1414066 ] make failes on hpux Message-ID: Bugs item #1414066, was opened at 2006-01-24 15:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1414066&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Warren Smith (warren_smith) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: make failes on hpux Initial Comment: Make fails with builtin make with this error: Make: Must be a separator on rules line 48. Stop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1414066&group_id=10127 From noreply at sourceforge.net Tue Jan 24 23:52:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 14:52:06 -0800 Subject: [Expat-bugs] [ expat-Bugs-1414066 ] make failes on hpux Message-ID: Bugs item #1414066, was opened at 2006-01-24 16:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1414066&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Warren Smith (warren_smith) >Assigned to: Greg Stein (gstein) Summary: make failes on hpux Initial Comment: Make fails with builtin make with this error: Make: Must be a separator on rules line 48. Stop. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-24 17:52 Message: Logged In: YES user_id=290026 I don't have HPUX available, and neither does the SF compile farm. Unless Greg has an idea, I am afraid the best help you can get is by debugging this on your own, and then post the solution here for others to see. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1414066&group_id=10127 From noreply at sourceforge.net Thu Jan 26 00:07:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 15:07:53 -0800 Subject: [Expat-bugs] [ expat-Bugs-1408143 ] "make check" failure Message-ID: Bugs item #1408143, was opened at 2006-01-17 07:20 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1408143&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: "make check" failure Initial Comment: From: Peter Breitenlohner expat-2.0.0 When running "make check" (with VPATH, i.e. outside the source tree), g++ was invoked without any '-I' and thus has included some old installed headers from 1.95.8 resulting in a compilation error due to the missing declaration of XML_Size. Attached is a small patch fixing this. The patch also makes a difference between CFLAGS and CXXFLAGS in order to avoid the warnings that g++ doesn't want "-Wmissing-prototypes -Wstrict-prototypes". ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-01-25 18:07 Message: Logged In: YES user_id=290026 After some discussion and testing from other team members, the attached patch was accepted (except for the changes to configure, as this file is a generated file and not in CVS). Applied in Makefile.in rev. 1.54 and configure.in rev. 1.42. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1408143&group_id=10127