From karl at waclawek.net Tue Sep 2 14:12:00 2003 From: karl at waclawek.net (Karl Waclawek) Date: Tue Sep 2 13:19:25 2003 Subject: [Expat-bugs] question about expat-1.95.6 on Solaris 8 References: <200308291653.h7TGrnnT019085@rosewood.cse.tek.com> Message-ID: <00c201c37175$52b805d0$9e539696@citkwaclaww2k> > I am building expat-1.95.6 on Solaris 8 with gcc-3.2.3 > > It seems to be making, however I get 79 of these at various points > > ../expat-1.95.6/lib/xmltok.c:1216: warning: `regparm' attribute directive ignored > > > Are these really just a warning or is something wrong? I think this warning can be ignored. regparm deals with parameter passing in registers. I assume this is not an Intel CPU? Karl From noreply at sourceforge.net Sat Sep 13 10:44:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 10:44:59 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 07:37 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-13 07:44 Message: Logged In: NO this is simply a matter of the expat.h file being wrongly organised so that "enum XML_Status" is used several times before it is declared. 30 seconds copying and pasting will fix it. currently nothing using expat.h compiles under gcc 3.2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-07-18 06:16 Message: Logged In: NO After I read all this comments, i saw that u were right. : ) I placed the following definitions enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; at the beginning of the expat.h file, before any call to it, and it compiled succesfully. After this I compiled sablot with no problems. thank u guys ... : ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 08:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 13:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 13:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 06:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 00:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 00:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 06:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 02:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 03:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 18:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 17:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-13 23:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 12:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 12:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 06:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 02:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 10:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 07:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Sat Sep 13 12:19:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 12:20:25 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 10:37 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 12:19 Message: Logged In: YES user_id=290026 Has been fixed in CVS for a long time. Btw, CVS is generally stable, as we are quite careful to commit changes only when they have been tested. No guarantees, of course. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-13 10:44 Message: Logged In: NO this is simply a matter of the expat.h file being wrongly organised so that "enum XML_Status" is used several times before it is declared. 30 seconds copying and pasting will fix it. currently nothing using expat.h compiles under gcc 3.2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-07-18 09:16 Message: Logged In: NO After I read all this comments, i saw that u were right. : ) I placed the following definitions enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; at the beginning of the expat.h file, before any call to it, and it compiled succesfully. After this I compiled sablot with no problems. thank u guys ... : ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 11:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 16:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 16:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 09:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 03:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 03:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 09:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 05:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 06:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 21:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 20:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-14 02:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 15:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 15:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 09:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 05:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 13:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 10:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Sat Sep 13 13:26:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 13:26:53 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 13:26 Message: Logged In: YES user_id=290026 Added three e-mail messages I sent to Fred Drake regarding benchmarks for this patch. The file names are Benchmarking1,2,3.txt. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-28 16:32 Message: Logged In: YES user_id=290026 Added one more improvement (attached as hashpatch3.diff): Removed the need to initialize the hash table for the duplicate prefixed attributes check (see function storeAttributes()). The size of the hash table will be at least twice the largest number of prefixed attributes encountered in any one element. Once that element is processed, any subsequent call to storeAttributes() would need to clear the entire (large) hash table as long as there is at least one prefixed attribute. The solution was to add a version counter such that all hash table entries get a version flag, which is updated with every call to storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-27 12:43 Message: Logged In: YES user_id=290026 Attached new patch file hashpatch2.diff. Includes changes suggested in comment from 2003-04-01. Also changed hash function to be closer to Python's string hash and improved comments on the inlined attributes hash table in storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-01 12:50 Message: Logged In: YES user_id=290026 The last change is not necessary, since the cast to unsigned char takes care of overflow. It actually introduces a bug, since for small sizes the step size can now be larger than the table size. We can change back and write it like this: #define SECOND_HASH(hash, mask, power) \ ((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((SECOND_HASH(hash, mask, power)) | 1)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-28 20:40 Message: Logged In: YES user_id=290026 Further change for PROBE_STEP macro: To prevent overflow (the result should fit into one Byte) we replace "& (mask >> 2)" with "& (unsigned long)0xFF": #define BYTE_MASK ((unsigned long)0xFF) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) \ & BYTE_MASK) \ | (unsigned char)(1)) which limits the maxium step size to 0xFF. Large steps are not a good idea anyway, since that might lead to cache misses. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 13:29 Message: Logged In: YES user_id=290026 Improvement to first patch version (hashpatch1.diff): For calculating second hash, don't overwrite the rightmost bit of the hash value's unused portion. This means: change ">> (power)" to ">> ((power) - 1)": #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) \ + | (unsigned char)(1)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From noreply at sourceforge.net Sat Sep 13 16:29:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 16:30:05 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 07:37 Message generated for change (Comment added) made by jyljyljyl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-09-13 13:29 Message: Logged In: YES user_id=63723 Are you planning -- please? -- to make another file release containing these fixes? Asking my users to build expat from the current release is not working, because of this bug. As a result, I'm recommending to my users to get/use an older version of expat without the new nifty features. --JYL ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 09:19 Message: Logged In: YES user_id=290026 Has been fixed in CVS for a long time. Btw, CVS is generally stable, as we are quite careful to commit changes only when they have been tested. No guarantees, of course. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-13 07:44 Message: Logged In: NO this is simply a matter of the expat.h file being wrongly organised so that "enum XML_Status" is used several times before it is declared. 30 seconds copying and pasting will fix it. currently nothing using expat.h compiles under gcc 3.2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-07-18 06:16 Message: Logged In: NO After I read all this comments, i saw that u were right. : ) I placed the following definitions enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; at the beginning of the expat.h file, before any call to it, and it compiled succesfully. After this I compiled sablot with no problems. thank u guys ... : ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 08:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 13:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 13:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 06:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 00:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 00:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 06:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 02:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 03:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 18:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 17:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-13 23:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 12:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 12:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 06:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 02:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 10:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 07:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Sat Sep 13 16:43:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 16:43:28 2003 Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum XML_Status Message-ID: Bugs item #676844, was opened at 2003-01-29 10:37 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 Category: Build control Group: None Status: Open Resolution: Fixed Priority: 9 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat.h compile error: enum XML_Status Initial Comment: c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c context.cpp -fPIC -DPIC -o .libs/context.lo In file included from parser.h:45, from guard.h:143, from context.cpp:45: /usr/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/include/expat.h:736: multiple definition of `enum XML_Status' when building sablotron. Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 16:42 Message: Logged In: YES user_id=290026 We intend to release soon. All that is holding us up is finding the time to actually do it. Fred will be back in a week, and I hope he can find the time then. Now, since your users are expert enough to build Expat from source, what is holding them back from using the current CVS? It is pretty much what we will release, except possibly for minor details, or if someone finds a bug, of course. We do actually want users to build from CVS, as our desire to have stable file releases means that we want our changes to be tested as much as possible. ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-09-13 16:29 Message: Logged In: YES user_id=63723 Are you planning -- please? -- to make another file release containing these fixes? Asking my users to build expat from the current release is not working, because of this bug. As a result, I'm recommending to my users to get/use an older version of expat without the new nifty features. --JYL ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 12:19 Message: Logged In: YES user_id=290026 Has been fixed in CVS for a long time. Btw, CVS is generally stable, as we are quite careful to commit changes only when they have been tested. No guarantees, of course. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-13 10:44 Message: Logged In: NO this is simply a matter of the expat.h file being wrongly organised so that "enum XML_Status" is used several times before it is declared. 30 seconds copying and pasting will fix it. currently nothing using expat.h compiles under gcc 3.2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-07-18 09:16 Message: Logged In: NO After I read all this comments, i saw that u were right. : ) I placed the following definitions enum XML_Status { XML_STATUS_ERROR = 0, #define XML_STATUS_ERROR XML_STATUS_ERROR XML_STATUS_OK = 1 #define XML_STATUS_OK XML_STATUS_OK }; at the beginning of the expat.h file, before any call to it, and it compiled succesfully. After this I compiled sablot with no problems. thank u guys ... : ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-19 11:36 Message: Logged In: NO in configure..:: checking XML::Parser perl module... no: documentation requires XML::Parser module and will not be built. checking whether to build under GPL... no checking whether to build the debugger... no checking where to find xml parser... expat (new) checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-30 16:47 Message: Logged In: YES user_id=290026 Yes, the file to fix is expat.h. Two things you can do: 1) get the latest expat.h from CVS, or 2) use your editor to search expat.h for the first location where XML_STATUS is used and then move the definition of XML_STATUS to some location before that point. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-05-30 16:26 Message: Logged In: NO I have the same problem has other senders, but the fix is unclear as you did not indicate which file needs fixing (I assume expat.h) or line number to place the def of enum XML_Status. Please assume people are stupid.. checking expat.h usability... no checking expat.h presence... yes configure: WARNING: expat.h: present but cannot be compiled configure: WARNING: expat.h: check for missing prerequisite headers? configure: WARNING: expat.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for expat.h... yes checking whether expat.h is broken... yes configure: error: You probably have expat version 1.95.6. Please refer to: http://sourceforge.net/tracker/index.php?func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-05-08 09:18 Message: Logged In: YES user_id=290026 See above - original submission: Hand editing the file to place the def of enum XML_Status before any references to it fixes the problem. ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 03:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Donche, Pieter (pdon) Date: 2003-05-08 03:20 Message: Logged In: YES user_id=774177 SUN Sparc Enterprise 2170 Solaris 2.8 gcc 3.2 Downloaded expat-1.95.6.tar.gz ./configure, make, make install OK Downloaded Sablot-0.98.tar.gz (Sablotron package, from www.gingerall.com) ./configure says: ... checking expat.h presence... yes expat.h: present but cannot be compiled expat.h: check for missing prerequisite headers? expat.h: proceeding with the preprocessor's result ##-------------------------------------------------## ## Report this to bug-autoconf@gnu.org ## ##-------------------------------------------------## checking for expat.h... yes checking wether expat.h is broken... yes error: You probably have expat version 1.95.6. Please refer to http://sourceforge.net/tracker/index.php? func=detail&aid=676844&group_id=10127&atid=110127 for a description of the problem -- Looked at that web-page. Don't see a solution there. Wath is the solution ? Pieter.Donche@ua.ac.be ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-16 09:59 Message: Logged In: YES user_id=290026 Changed priority to highest to make it more visible, so that double reporting incidents occur less frequently. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-27 05:42 Message: Logged In: NO Same problem and the same fix under Linux and gcc 2.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-07 06:20 Message: Logged In: NO same problem, same fix when building 1.95.6 on vms (just downloaded .tar.gz & processed - got the rpm, but don't know what to do with it - not an archive type I know how to handle on vms, or windows either) - chris.sharman@ccagroup.co.uk ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-28 21:03 Message: Logged In: YES user_id=290026 Strange - I had no problems with MS VC++ 6.0. Which service pack level have you applied? ---------------------------------------------------------------------- Comment By: Jacob Levy (jyljyljyl) Date: 2003-02-28 20:35 Message: Logged In: YES user_id=63723 This makes Expat 1.95.6 unusable for people who create libraries that depend on Expat but don't include their own copy of Expat. Sure, I can edit expat.h and fix it, but my users should not be expected to do that. For that reason I'm staying with Expat 1.95.5 until this problem is fixed. It'd be really nice if you could make Expat 1.95.7 soon.. In my case GCC 2.95.2 and VC++ 6.0 are complaining. ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-14 02:56 Message: Logged In: YES user_id=212431 Yes, that works. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-02-06 15:47 Message: Logged In: YES user_id=290026 But current CVS works for you, right? ---------------------------------------------------------------------- Comment By: Melvyn Sopacua (nyvlem) Date: 2003-02-06 15:17 Message: Logged In: YES user_id=212431 > So far only gcc3.2 has complained. Nope: /usr/local/include/expat.h:657: use of enum `XML_Status' without previous declaration /usr/local/include/expat.h:736: multiple definition of `enum XML_Status' gmake[2]: *** [context.lo] Error 1 gmake[2]: Leaving directory `/home/mdev/cvs/sablot/src/engine' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src' gmake: *** [all-recursive] Error 1 $ gcc --version 2.95.3 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-31 09:43 Message: Logged In: YES user_id=290026 It *is* fixed in CVS. Are you sure you checked out the right version, which is expat.h 1.51? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-31 05:34 Message: Logged In: NO I just got the same error, already fixed it. But don't understand why it isn't fixed in CVS ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 13:44 Message: Logged In: YES user_id=3066 I've not checked the C89 standard yet, but Expat 1.95.6 is certainly dodgy in this case. ;-( The first draft of the C spec I found online certainly seemed to imply that any use of an incomplete enum is not allowed; I'm not likely to go out and buy a copy of the final spec to check further. ;-) As noted, this has been fixed in CVS. Fixed the summary to better indicate what this report is about, and lowered the priority to get it out of the way for maintainers. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 10:51 Message: Logged In: YES user_id=290026 So far only gcc3.2 has complained. Not sure if this is a bug, since most compilers accept it, but it has been fixed in CVS already anyway. Set resolution status to fixed, but leave open. There may be other users who would report this as a bug and I want them to see the open report instead of having duplicates created. Assigned to Fred - since he may know more about whether this truly is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127 From noreply at sourceforge.net Sun Sep 14 15:55:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 14 15:55:52 2003 Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement Message-ID: Patches item #699487, was opened at 2003-03-07 11:31 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Karl Waclawek (kwaclaw) Assigned to: Karl Waclawek (kwaclaw) Summary: Hash table improvement Initial Comment: This patch addresses two areas: 1) The current hash function ignores the high byte of UTF-16 characters. This is not good. 2) There is a cheap way to switch from the current method of linear probing (to resolve collisions) to the slightly better double hashing. Ad 1) hashing of wide characters: Currently, the algorithm is like this: h = h * 33 + (unsigned char)c; where h is the hash value and c is a character in the string argument (char or wchar_t). It seems this hashing algorithm belongs to a family of algorithms of the type: h = h * + character where is taken froma list of tried and proven values like 31, 33, 37, 41, 65599 which should be (but are not always) prime numbers. I added a wchar_t version (#ifdef XML_UNICODE) of this type: h = h * 65599 + (unsigned short)c; Ad 2) double hashing: Currently the hash table index is calculated from the hash value by masking out the lower bits according to table size. This works because the table size is a power of 2. But this also means that some bits of the hash value are unused. From these we can therefore generate the second hash value with little extra effort. The patch also updates the inlined hash table implementation used for detecting duplicate prefixed attributes (in function storeAtts()). See the attached file hashpatch1.diff (to be applied against xmlparse.c rev. 1.109). ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-14 15:55 Message: Logged In: YES user_id=290026 Patch for xmlparse.c committed on 2003/09/13. New revision: xmlparse.c 1.110. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-13 13:26 Message: Logged In: YES user_id=290026 Added three e-mail messages I sent to Fred Drake regarding benchmarks for this patch. The file names are Benchmarking1,2,3.txt. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-28 16:32 Message: Logged In: YES user_id=290026 Added one more improvement (attached as hashpatch3.diff): Removed the need to initialize the hash table for the duplicate prefixed attributes check (see function storeAttributes()). The size of the hash table will be at least twice the largest number of prefixed attributes encountered in any one element. Once that element is processed, any subsequent call to storeAttributes() would need to clear the entire (large) hash table as long as there is at least one prefixed attribute. The solution was to add a version counter such that all hash table entries get a version flag, which is updated with every call to storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-08-27 12:43 Message: Logged In: YES user_id=290026 Attached new patch file hashpatch2.diff. Includes changes suggested in comment from 2003-04-01. Also changed hash function to be closer to Python's string hash and improved comments on the inlined attributes hash table in storeAttributes(). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-04-01 12:50 Message: Logged In: YES user_id=290026 The last change is not necessary, since the cast to unsigned char takes care of overflow. It actually introduces a bug, since for small sizes the step size can now be larger than the table size. We can change back and write it like this: #define SECOND_HASH(hash, mask, power) \ ((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((SECOND_HASH(hash, mask, power)) | 1)) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-28 20:40 Message: Logged In: YES user_id=290026 Further change for PROBE_STEP macro: To prevent overflow (the result should fit into one Byte) we replace "& (mask >> 2)" with "& (unsigned long)0xFF": #define BYTE_MASK ((unsigned long)0xFF) #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) \ & BYTE_MASK) \ | (unsigned char)(1)) which limits the maxium step size to 0xFF. Large steps are not a good idea anyway, since that might lead to cache misses. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-03-24 13:29 Message: Logged In: YES user_id=290026 Improvement to first patch version (hashpatch1.diff): For calculating second hash, don't overwrite the rightmost bit of the hash value's unused portion. This means: change ">> (power)" to ">> ((power) - 1)": #define PROBE_STEP(hash, mask, power) \ ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2)) \ + | (unsigned char)(1)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127 From noreply at sourceforge.net Thu Sep 18 01:35:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 01:35:32 2003 Subject: [Expat-bugs] [ expat-Bugs-808331 ] Faulty code generation in function "lookup" Message-ID: Bugs item #808331, was opened at 2003-09-17 22:35 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=808331&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Faulty code generation in function "lookup" Initial Comment: The function "lookup" in source "xmlparse.c" generates faulty code when built for a PocketPC2002 device in eMbedded Visual C++ v3.0. Note that this only occurs for a release build, and not for a debug build. Specifically this block of code at line 5306: for (i = h & (table->size - 1); table->v[i]; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return table->v[i]; } The return statement is generated as a branch to the return statement at the end of the function. The code generation fault is in the failure to shift the index i to account for the size of the elements of v. The alternative is to declare a local variable of type NAMED ** to be assigned in the condition clause of the for loop and return that instead. NAMED **n; for (i = h & (table->size - 1); (n = table->v[i]) != NULL; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return n; } email address: adam@xtreamlok.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=808331&group_id=10127 From noreply at sourceforge.net Fri Sep 19 08:45:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 19 08:45:47 2003 Subject: [Expat-bugs] [ expat-Bugs-809235 ] xmlwin32url.cxx Bugs Message-ID: Bugs item #809235, was opened at 2003-09-19 14:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=809235&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Thomas Engelmeier (tom_e) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwin32url.cxx Bugs Initial Comment: (Yeah, I know that file is deprecated ;-) - processURL doesn't init the QuitInfo.hr field and fails due to that. - Callback::OnDataAvailable sets the XML encoding at least for some UTF-8 testdata to "usascii" which has some undesirable sideffects for umlaut-rich XML. When that block is commented out, it works better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=809235&group_id=10127 From noreply at sourceforge.net Wed Sep 24 11:45:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 24 11:45:36 2003 Subject: [Expat-bugs] [ expat-Patches-808331 ] Faulty code generation in function "lookup" Message-ID: Patches item #808331, was opened at 2003-09-18 01:35 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=808331&group_id=10127 Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Faulty code generation in function "lookup" Initial Comment: The function "lookup" in source "xmlparse.c" generates faulty code when built for a PocketPC2002 device in eMbedded Visual C++ v3.0. Note that this only occurs for a release build, and not for a debug build. Specifically this block of code at line 5306: for (i = h & (table->size - 1); table->v[i]; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return table->v[i]; } The return statement is generated as a branch to the return statement at the end of the function. The code generation fault is in the failure to shift the index i to account for the size of the elements of v. The alternative is to declare a local variable of type NAMED ** to be assigned in the condition clause of the for loop and return that instead. NAMED **n; for (i = h & (table->size - 1); (n = table->v[i]) != NULL; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return n; } email address: adam@xtreamlok.com ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-24 11:45 Message: Logged In: YES user_id=290026 Thank you for the info. This does not seem to be a bug, but rather a workaround for a faulty compiler. Re-classified as a patch. Assigned to Fred for comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=808331&group_id=10127 From noreply at sourceforge.net Wed Sep 24 11:47:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 24 11:47:29 2003 Subject: [Expat-bugs] [ expat-Patches-808331 ] Faulty code generation in function "lookup" Message-ID: Patches item #808331, was opened at 2003-09-18 01:35 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=808331&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Faulty code generation in function "lookup" Initial Comment: The function "lookup" in source "xmlparse.c" generates faulty code when built for a PocketPC2002 device in eMbedded Visual C++ v3.0. Note that this only occurs for a release build, and not for a debug build. Specifically this block of code at line 5306: for (i = h & (table->size - 1); table->v[i]; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return table->v[i]; } The return statement is generated as a branch to the return statement at the end of the function. The code generation fault is in the failure to shift the index i to account for the size of the elements of v. The alternative is to declare a local variable of type NAMED ** to be assigned in the condition clause of the for loop and return that instead. NAMED **n; for (i = h & (table->size - 1); (n = table->v[i]) != NULL; i == 0 ? i = table->size - 1 : --i) { if (keyeq(name, table->v[i]->name)) return n; } email address: adam@xtreamlok.com ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-24 11:45 Message: Logged In: YES user_id=290026 Thank you for the info. This does not seem to be a bug, but rather a workaround for a faulty compiler. Re-classified as a patch. Assigned to Fred for comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=808331&group_id=10127 From noreply at sourceforge.net Wed Sep 24 19:48:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 24 19:48:21 2003 Subject: [Expat-bugs] [ expat-Bugs-569461 ] OASIS XML Test Suite Message-ID: Bugs item #569461, was opened at 2002-06-15 15:34 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Karl Waclawek (kwaclaw) >Summary: OASIS XML Test Suite Initial Comment: I've tested expat-1.95.3 (with xmltok.c updated to rev. 1.17, becase of bug 566240, all other files are the original 1.95.3) against the recently updated OASIS xml test suite (XML 1.0 (Second Edition) errata 20020320, W3C Conformance Test Suite 20020606), avaliable via http://www.w3.org/XML/Test/ and found a few new problems, that are not triggered by older versions of this test suite. As in previous reports, I checked all not-wellformedness tests (should all raise error) and all valid tests (should all pass) of the test-suites xmltest, ibm, sun and oasis with xmlwf -p. Especially for the well-formedness tests, I have _not_ throughout checked if the error reason, reported by expat is the expected error, but checked only mechanical, if the test has raised an error, regardless of the exact error reason. This method is clearly not perfect, and this time we have an example, that underlines this. ibm/not-wf/P32/ibm32n09.xml This is a new test, not included in previous versions. Problem is, that the standalone document declaration has the value "yes" and there is an external markup declaration of an entity (other than amp, lt, gt, apos, quot). xmlwf -p doesn't report an error. The not well-formedness problem is, that standalone="yes" means, that all informations needed to build the XML infoset must be found in the document entity (standalone="yes" doesn't mean, that the document must not have an external subset or external PE's, only that this external entities doesn't change - per attribute defaults or as in this case, entity declarations - change the info in the document entity. See the last sentence of "Well-Formedness Constraint: Entity Declared" (P68). ibm/not-wf/P68/ibm68n06.xml Same reason as the test befor. This test _was_ present in previous versions of the test suite. But with the previous version of the external subset of this test, xmlwf claimed a "syntax error" error in the external subset, which I plain can't understand (eventually an other expat bug?), but is clearly not the expected error. In the new version of the test suite, this external subset now has an XML declaration with explicite encoding (the older version had only an XML declaration without encoding) and is accepted by expat. xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml This tests are new in this edition of the test suite. Unfortunately, this both tests seems to be not documented, either in the test files isself nor in the documentation file xmlconf-20020606.htm. As far as I see, this tests test "Validity Constraint: Proper Declaration/PE Nesting" (P29). xmltest/not-wf/not-sa/005.xml This test raised error with previous expat versions, but does not anymore due to the changes, discussed in bug 548690. This is intentional, according to the 548690 discussion. This test is now listed under "XML Documents with Optional Errors". The test suite documentation says: "Conforming XML 1.0 Processors are permitted to ignore certain errors, or to report them at user option. In this section of this test report are found descriptions of test cases which fit into this category. Processor behavior on such test cases does not affect conformance to the XML 1.0 (Second Edition) Recommendation, except as noted." So, according to this, it's OK, that expat doesn't report an error for this case. Since both reporting error and not reporting error are OK, it may be debatably, which behavior is more convenient for the expat user. (Karl: ;-)) sun/not-wf/not-sa03.xml This is a new test in this edition of the test suite. Unfortunately, this test seems not to be documented. As far as I see, it tests the same as xmltest/not-wf/not-sa/005.xml Tests, that still are wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml These are already discussed in the past. Well, that's all. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-09-24 19:48 Message: Logged In: YES user_id=290026 Just changed the summary to be more generic, as this bug will probably stay open permanently, assuming we will never pass 100% of all test cases. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-29 16:26 Message: Logged In: YES user_id=290026 This is just to report that the new release Expat 1.95.6 passes the OASIS test suite (same version - 20020606) with the exact same results as Expat 1.95.5. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-21 14:21 Message: Logged In: YES user_id=290026 For comparison purposes, I ran the xmltest.sh test script against release 1.95.5. The results are attached as TestResults_1_95_5.txt. Discussion of results: There are many cases were "output differs"is reported, but these are due to xmlwf having a different definition of "canonical XML" than used in the test suite. Leaving these out, and those that were discussed already in this thread, we have the following errors reported: (Note: the two test cases ibm/not-wf/P32/ibm32n09.xml and ibm/not-wf/P68/ibm68n06.xml are not reported anymore by the script) * In ibm/invalid/P49/: ibm49i02.xml:7:1: error in processing external entity reference: The associated DTD file does not exist - an error in the test suite. The next three documents are not UTF-8 encoded, and do not have an XML declaration, so Expat rejects them, which is correct. An error in the test suite. * In xmltest/valid/sa/: 049.xml:2:0: not well-formed (invalid token) * In xmltest/valid/sa/: 050.xml:2:0: not well-formed (invalid token) * In xmltest/valid/sa/: 051.xml:2:0: not well-formed (invalid token) The next two documents are classified as invalid, but well-formed, but they contain faulty UTF-16 encoding, so they should be classified as not well-formed. Expat seems correct here. * In sun/invalid/: utf16b.xml:2:0: not well-formed (invalid token) * In sun/invalid/: utf16l.xml:1:40: not well-formed (invalid token) The next three are not marked as why they should fail, so the script thinks they are not well-formed, but in fact they are: * Well formed: oasis/p06fail1.xml * Well formed: oasis/p08fail1.xml * Well formed: oasis/p08fail2.xml So, no new test case errors have really been added for release 1.95.5. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-01-19 14:01 Message: Logged In: YES user_id=290026 Just a comment: This bug report will likely stay open until Expat passes the OASIS test suite without any problem at all. Since no parser currently achieves this, there is a good chance this bug report will stay open for a long time to come.. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-07-07 11:39 Message: Logged In: YES user_id=290026 Patch #587161 should fix some of the problems, but I specifically made no attempt to fix the problems Expat has with: - xmltest/not-wf/not-sa/010.xml and - xmltest/not-wf/not-sa/011.xml. Reason: It turns out, after consulting with the mailing list for the XML test suite, public-xml-testsuite@w3.org, that these two violate WFC: PE Between Declarations. There is no quick and easy fix for this in Expat, and I would have to spend some time thinking about it, which I don't have at the moment. Karl ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 23:15 Message: Logged In: YES user_id=290026 Assigned to me, but only for the three test cases described in my last message. Karl ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2002-06-17 19:21 Message: Logged In: YES user_id=13222 Agreed ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-06-17 15:05 Message: Logged In: YES user_id=290026 Given an improved understanding of section 4.1 in the XML spec, I will try to fix the following test cases in the next Expat release: ibm/not-wf/P32/ibm32n09.xml, ibm/not-wf/P68/ibm68n06.xml and sun/not-wf/not-sa03.xml In my opinion, the third one is not the same type as xmltest/not-wf/not-sa/005.xml, but the same type as the other two. About the test cases xmltest/not-wf/not-sa/010.xml and xmltest/not-wf/not-sa/011.xml: If they really check validity constraint P29, as Rolf has suggested, then it is OK that Expat does not report an error. So, If I am successful, we would be left with only: ibm/not-wf/misc/432gewf.xml and sun/not-wf/uri01.xml, conformance with which does not seem a 100% necessity, as previously discussed. Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=569461&group_id=10127 From nivasa at terra.es Thu Sep 25 19:06:37 2003 From: nivasa at terra.es (=?ISO-8859-1?Q?Nicol=E1s_V=E1zquez?= Sabater) Date: Thu Sep 25 22:52:23 2003 Subject: [Expat-bugs] Problems with SOAP Fault Message-ID: <1064531197.1889.21.camel@localhost> Hi. I'm developing a SOAP client tha uses te Google API. The parser i using is ExPat v 1.95. I have a problem parsing messages SOAP Fault of this kind: HTTP/1.0 500 Internal Server Error Date: Mon, 22 Sep 2003 22:46:37 GMT Server: e h c a p a Content-Length: 541 Content-Type: text/xml; charset=utf-8 Age: 1 SOAP-ENV:Client parsing error: org.xml.sax.SAXParseException: The element type "phrase" must be terminated by the matching end-tag "". /search/beta2 The request has the character ?, my problen is not using that character. My problem is that the parser makes an exception while parsesthe response message because there is and tag in the content of faultstring element. I probed sendig a request to Google server which has a tag in his elements and it crashes while parsing. I think that the problem is in the Apache SOAP server where is installed Google API, but im not sure. I will be thankfull if you answer me. Nicolas. PD: Sorry, my english is very very poor. :( From noreply at sourceforge.net Sun Sep 28 11:27:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 11:27:52 2003 Subject: [Expat-bugs] [ expat-Bugs-765227 ] MacOSX build error with Expat 1.95.6 (included with PyXML) Message-ID: Bugs item #765227, was opened at 2003-07-03 03:32 Message generated for change (Comment added) made by jtalkington You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=765227&group_id=10127 Category: None Group: Platform Specific Status: Open Resolution: None Priority: 7 Submitted By: David Kaasen (davidkaasen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: MacOSX build error with Expat 1.95.6 (included with PyXML) Initial Comment: I had trouble with the expat 1.95.6 that is included with PyXML 0.8.2 on MacOSX 10.2.6. The build of PyXML gave error messages (but didn't halt) when compiling xmltok.c. It appears to be problems with the macros FASTCALL, PTRCALL and PTRFASTCALL in internal.h. Defining these to nothing made the compile succeed. Here is the diff output: *** PyXML-0.8.2/extensions/expat/lib/internal.h~ Sat Jan 25 12:18:09 2003 --- PyXML-0.8.2/extensions/expat/lib/internal.h Thu Jul 3 11:12:36 2003 *************** *** 27,33 **** --- 27,36 ---- and let's try this: */ + /* It doesn't work on MacOSX (__MACH__ and __APPLE__ == MacOSX). */ + #if !(defined(__MACH__) && defined(__APPLE__)) #define FASTCALL __attribute__((regparm(3))) #define PTRCALL #define PTRFASTCALL __attribute__((regparm(3))) + #endif /* Not MacOSX */ #elif defined(WIN32) ---------------------------------------------------------------------- Comment By: Jerry Talkington (jtalkington) Date: 2003-09-28 08:27 Message: Logged In: YES user_id=715462 FWIW, this was fixed with the checkin for bug 692878. However, the fix for that bug is incorrect, as it checks for __GNUC__ and __linux__. regparm is an i386 only feature, so that will still generate a warning on Linux PPC. The correct fix is to check for __GNUC__ and __i386__. I confirmed this on Linux and FreeBSD 4 (which is left out of the current fix.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-27 09:40 Message: Logged In: YES user_id=3066 Bumping priority; this must be fixed for 1.95.7. I've held back mostly since I now have reasonable access to a Mac OS X box, but haven't had time to really do much with it (like testing Expat!). ---------------------------------------------------------------------- Comment By: David Kaasen (davidkaasen) Date: 2003-07-03 03:59 Message: Logged In: YES user_id=20933 I should have mentioned that I am using Fink and Fink's Python distribution. Using /usr/bin/python instead only gives warnings, but then, there are problems with LDFLAGS containing "-arch i386" in /usr/lib/python2.2/config/Makefile. If that string is removed from LDFLAGS, everything seems to go well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=765227&group_id=10127 From noreply at sourceforge.net Sun Sep 28 17:55:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 17:55:42 2003 Subject: [Expat-bugs] [ expat-Bugs-765227 ] MacOSX build error with Expat 1.95.6 (included with PyXML) Message-ID: Bugs item #765227, was opened at 2003-07-03 03:32 Message generated for change (Comment added) made by gstein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=765227&group_id=10127 Category: None Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: David Kaasen (davidkaasen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: MacOSX build error with Expat 1.95.6 (included with PyXML) Initial Comment: I had trouble with the expat 1.95.6 that is included with PyXML 0.8.2 on MacOSX 10.2.6. The build of PyXML gave error messages (but didn't halt) when compiling xmltok.c. It appears to be problems with the macros FASTCALL, PTRCALL and PTRFASTCALL in internal.h. Defining these to nothing made the compile succeed. Here is the diff output: *** PyXML-0.8.2/extensions/expat/lib/internal.h~ Sat Jan 25 12:18:09 2003 --- PyXML-0.8.2/extensions/expat/lib/internal.h Thu Jul 3 11:12:36 2003 *************** *** 27,33 **** --- 27,36 ---- and let's try this: */ + /* It doesn't work on MacOSX (__MACH__ and __APPLE__ == MacOSX). */ + #if !(defined(__MACH__) && defined(__APPLE__)) #define FASTCALL __attribute__((regparm(3))) #define PTRCALL #define PTRFASTCALL __attribute__((regparm(3))) + #endif /* Not MacOSX */ #elif defined(WIN32) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2003-09-28 14:55 Message: Logged In: YES user_id=6501 I've applied jtalkington's suggested change. Thanks! ---------------------------------------------------------------------- Comment By: Jerry Talkington (jtalkington) Date: 2003-09-28 08:27 Message: Logged In: YES user_id=715462 FWIW, this was fixed with the checkin for bug 692878. However, the fix for that bug is incorrect, as it checks for __GNUC__ and __linux__. regparm is an i386 only feature, so that will still generate a warning on Linux PPC. The correct fix is to check for __GNUC__ and __i386__. I confirmed this on Linux and FreeBSD 4 (which is left out of the current fix.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-27 09:40 Message: Logged In: YES user_id=3066 Bumping priority; this must be fixed for 1.95.7. I've held back mostly since I now have reasonable access to a Mac OS X box, but haven't had time to really do much with it (like testing Expat!). ---------------------------------------------------------------------- Comment By: David Kaasen (davidkaasen) Date: 2003-07-03 03:59 Message: Logged In: YES user_id=20933 I should have mentioned that I am using Fink and Fink's Python distribution. Using /usr/bin/python instead only gives warnings, but then, there are problems with LDFLAGS containing "-arch i386" in /usr/lib/python2.2/config/Makefile. If that string is removed from LDFLAGS, everything seems to go well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=765227&group_id=10127