From noreply at sourceforge.net Sat Jan 17 17:03:40 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:03:40 +0000 Subject: [Expat-bugs] [ expat-Bugs-1742315 ] Harmful XML_ParserCreateNS suggestion Message-ID: Bugs item #1742315, was opened at 2007-06-23 23:54 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1742315&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: Documentation Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Bj?rn H?hrmann (hoehrmann) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Harmful XML_ParserCreateNS suggestion Initial Comment: The documentation for XML_ParserCreateNS says for the sep parameter "you should pick a character for sep that can't be part of a legal URI". This is a very bad suggestion, for example, the test suite uses the space character and Google code search suggests other people are using among other things "|", "!", "#", "&", ":", "/", and tab. It is true that legal URIs cannot contain some of these characters such as space and tab, but xmlns attributes certainly can and Expat does not filter them out. Poorly written name expansion code is so easily vulnerable to attack. Instead, the documentation should strongly recommend against using any of these characters and recommend to use a character that cannot occur in XML_Char arrays. In particular, -1 and WCHAR_MAX cannot occur because UTF-8 prohibits 0xFF and XML prohibits U+FFFF. Another suggestion would be 0x01 if Expat will never support XML 1.1. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:03 Message: No complaints about fix. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-06-24 13:22 Message: Logged In: YES user_id=290026 Originator: NO Although I am not quite sure how one would create an attack based on this weakness - not being a hacker myself, I do agree that the docs should be worded stronger. I think this issue has come up before, e.g. in bug # 918730. I committed a fix in reference.html rev. 1.74. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1742315&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:05:48 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:05:48 +0000 Subject: [Expat-bugs] [ expat-Bugs-1515600 ] Segfault after removing character data handler Message-ID: Bugs item #1515600, was opened at 2006-07-01 13:21 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1515600&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 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Segfault after removing character data handler Initial Comment: Removing the character data handler from within the character data handler while character data remains to be reported causes a call to a NULL pointer (generally followed by a memory access violation of your platform's favorite flavor). If the XML_StopParser() API has been called, this is not a problem with the version in CVS. This is admittedly an odd use case. The recent fixes to make the XML_StopParser() calls supported makes the parser behave well when accessed from languages that support exceptions (the host language API can call XML_StopParser to abort further work from Expat when an exception occurs). The case of a character data handler removing itself is unusual (in context, there can be no calls to anything else other than a decoding handler). I think there are two possible solutions: 1) Document that the character data handler cannot remove itself without calling XML_StopParser(). This avoids introducing a performance penalty for really this really odd case, but I don't know how bad testing for a NULL value would really be at this point, since there are a few other checks and an indirect assignment. 2) Add a check that the character data handler is still set before the loop goes around again, and fall back to the defaultHandler for the remaining data. This would introduce a single check for a NULL pointer in the loop in the XML_TOK_DATA_CHARS case in doContent(). I've attached a patch with a test case that demonstrates this bug; the test generates a segfault on Unix. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:05 Message: No complaints about fix. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 14:53 Message: Logged In: YES user_id=290026 Originator: NO Assigned to Fred for testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-10 15:03 Message: Logged In: YES user_id=290026 Applied an improved patch that preserves default handler failover logic. See xmlparse.c rev. 1.158. Docs updated as well. Python compatibility still needs testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 09:09 Message: Logged In: YES user_id=290026 Applied patch in xmlparse.c rev. 1.156 and reference.html rev. 1.71. Please let nme know if we should discuss special treatment of aborting vs. suspending. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-04 13:42 Message: Logged In: YES user_id=290026 I replaced my last attachment with one that includes an update to the docs (reference.html). This solution should fix issue # 1515266 as well. I intend to commit this soon, if no objections are made. Note to Fred: I took out your test for XML_FINISHED and XML_SUSPENDED, as it currently introduces an issue for XML_SUSPENDED, and inconsistent behaviour for XML_FINISHED. We can discuss special treatment of aborting vs. suspending (i.e. ensure no more call-backs when aborting) later, but even as it is, subsequent call-backs can be suppressed by setting the affected handlers to NULL. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-04 09:55 Message: Logged In: YES user_id=290026 The same issue also exists in the doCdataSection() function, and I think the solution I suggested (putting the check if the character data handler is set into the internal loop) also solves bug # 1515266, as I described there. For the case where there is only one call-back, this should not be a performance penalty at all, as there still would be only one check if the handler is set. Attached as xmlparse.c.diff (Internal loop solution) - this also fixes the doCdataSection() function. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-03 16:40 Message: Logged In: YES user_id=290026 I think in most cases this is not a problem. The general parsing loop in doContent() always checks if the characterDataHandler is set first. In the specific case you mentioned, there is a loop within the general loop, and in that internal loop there is no check for NULL. We could, for instance, pull the NULL check inside the loop, like your 2nd case, and the result would look like this: case XML_TOK_DATA_CHARS: if (MUST_CONVERT(enc, s)) { for (;;) { if (characterDataHandler) { ICHAR *dataPtr = (ICHAR *)dataBuf; XmlConvert(enc, &s, next, &dataPtr, (ICHAR *)dataBufEnd); *eventEndPP = s; characterDataHandler(handlerArg, dataBuf, (int)(dataPtr - (ICHAR *)dataBuf)); if (s == next) break; *eventPP = s; } } } else if (characterDataHandler) { characterDataHandler(handlerArg, (XML_Char *)s, (int)((XML_Char *)next - (XML_Char *)s)); } else if (defaultHandler) reportDefault(parser, enc, s, next); break; I am not sure if the performance penalty is that high. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1515600&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:09:57 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:09:57 +0000 Subject: [Expat-bugs] [ expat-Bugs-1515266 ] missing check of stopped parser in doContent() 'for' loop Message-ID: Bugs item #1515266, was opened at 2006-06-30 14:04 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1515266&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: missing check of stopped parser in doContent() 'for' loop Initial Comment: In Expat 2.0.0, in expat.c:doConvert() there is a 'for' loop for the XML_TOK_DATA_CHARS case. There is unfortunately no check in that loop whether the parser was stopped during that call because of an error. This was discovered in Python (Lib/test/crashers/xml_parsers.py) because pyexpat, upon error where there is no error return code like with characterDataHandlers, sets all handlers to 0, sets parsingStatus to XML_FINISHED, and sets errorCode. This leads to a segfault if the 'for' loop goes around again because parser->m_characterDataHandler is set to 0. A simple check if the parser is stopped fixes the problem. I have attached a simple patch that just breaks out of the loop and lets execution fall through to the bottom of the 'switch' statement. I don't know if returning errorCode directly would be better or if checking for XML_SUSPENDED is also desirable. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:09 Message: Comment for Fred: So, do we need to address this last comment - i.e. that Python is supposedly broken with release 2.0.1? Karl ---------------------------------------------------------------------- Comment By: David Leverton (dleverton) Date: 2008-05-24 19:50 Message: Logged In: YES user_id=2011415 Originator: NO > Python compatibility still needs testing. This does indeed break Python: when it clears the handler, it sets the variable containing the Python-side handler to NULL, and then assumes that said variable is non-null when expat calls the old handler. (The vanilla Python distribution uses a bundled copy of expat from before this change was made, which is probably why no-one's complained until now, but some Linux distros like to use the system copy instead of the bundled one.) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-25 12:41 Message: Logged In: YES user_id=290026 Originator: NO Is anyone testing CVS for this solution? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-10 15:02 Message: Logged In: YES user_id=290026 Applied the patch preserving default handler failover. See xmlparse.c rev. 1.158. Docs updated as well. Python compatibility still needs testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-06 13:19 Message: Logged In: YES user_id=290026 I am attaching a patch to current CVS that preserves the default handler failover logic by saving the character data handler to a local variable instead of moving the NULL check into the inner for loop (file "localCharDataHandlerPatch.diff"). The drawback: Even if the handler is cleared, it will be called back on as long as the inner for loop is active. Could be a problem for Python, if it cannot deal with a few more call-backs despite clearing the handlers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-07-06 13:03 Message: Logged In: YES user_id=357491 Yes, I'm listening, Fred. =) If you look at PEP 356 (http://www.python.org/dev/peps/pep-0356/) it seems like b2 is due on July 12 and rc1 August 1. So there is still time to get whatever change/fix needed to Python's wrapper before we hit final release. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-06 08:56 Message: Logged In: YES user_id=290026 One way to preserver the old default handler logic would be this: Revert back to the original code, but save the character data handler into a local variable for the duration of the inner for loop. This would prevent the segfault, but would enforce the call-backs in the loop to go on until the loop terminates, even if the character data handler was cleared. I personally like this solution, but the question is how Python could handle it if there were more call-backs even after the handlers were cleared. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-06 01:15 Message: Logged In: YES user_id=3066 Python (on the trunk) is no longer quite as sensitive to the Expat implementation for this, so that's not a source of time pressure to come up with the final fix for this. Reducing priority back to "Medium" ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-05 23:23 Message: Logged In: YES user_id=3066 The tests now pass, but agree that the lack of falling back to the default handler is undesirable. As noted, I'm not sure how much we want to worry about this in code, though, rather than through documentation. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 22:55 Message: Logged In: YES user_id=290026 The bug is quite obvious when you look at it. When the character data handler is cleared, the for loop will do nothing forever. Please check again with xmlparse.c rev. 1.157. However this quick fix is not quite satisfying. There is one piece of logic that becomes ill-fitted now: the "fail-over" to the default handler does not work as expected anymore, so I'll have some more thinking to do. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-05 22:38 Message: Logged In: YES user_id=3066 The tests no longer complete, but take up all the CPU the system will let them have. Hallmarks of an infinite loop, if you ask me. :-) Are you able to run the tests on Windows? I don't know if a MSVC++ target was ever built for them, and don't have access to a Windows development machine most of the time. One thing that can be done is to document that the character data handler can't be removed (though it can be replaced), during parsing, except from some non-character data (and non-decoding-related) handler. Then the Python bindings can use an alternate approach, replacing the character handler with a completely no-op handler until it can be safely removed completely. Brett, are you still paying attention? I can make the needed changes to the Python bindings to isolate those from some of the changes in Expat, hopefully no later than sometime this weekend. Not sure what the release schedule is, though. Karl, I'm generally inclined to make Expat as safe from segfaults as possible, so I'd like things to "just work" in even some of the oddball scenarios that exception-handling wrappers built to support scripting languages might present, though I don't object to making them go through a bit of extra work. I know our main audience is very performance-sensitive, so I don't want to pay too high a cost on that front. It might be worth taking the discussion of alternatives to the mailing list, but I vaguely recall that we've done that before. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 09:26 Message: Logged In: YES user_id=290026 Corrected Summary. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 09:14 Message: Logged In: YES user_id=290026 Applied the patch for bug # 1515600 which solves this issue as well. Removed the check for XML_FINISHED/XML_SUSPENDED. We could discuss special treatment of XML_FINISHED, but if one is clearing all handlers anyway, then special treatment of XML_FINISHED is not necessary. For Fred: I have not re-run the test cases. Please do so and close the issue if successful. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-04 09:37 Message: Logged In: YES user_id=290026 I am re-opening this issue because in the case of a suspended parser, breaking out of the inner loop in XML_TOK_DATA_CHARS means that character call-backs are missed when resuming the parser. We should let the inner loop finish reporting all characters. The documentation already states that after calling XML_StopParser() there may still be a few call-backs that would otherwise be missed, so this would not be new behaviour, but consistent with existing behaviour. The solution to the problem described is the same as suggested for bug # 1515600 (Segfault after removing character data handler). Just put the NULL check for the character data handler inside the internal loop. Btw, the same problem exists in the doCdataSection() function. I'll attach a patch suggestion to bug # 1515600. We might decide to treat XML_FINISHED different from XML_SUSPENDED such that no other call-backs will happen, but in that case we need to review all the other places where this would need to be done as well (and update the documentation, of course). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-01 11:32 Message: Logged In: YES user_id=3066 Confirmed that the suspend behavior parallels the abort behavior Brett's patch fixed; fixed and added a regression test in lib/xmlparse.c 1.155 and tests/runtests.c 1.66. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-01 11:02 Message: Logged In: YES user_id=3066 Added a regression test in tests/runtests.c revision 1.65. Closing this report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-01 00:00 Message: Logged In: YES user_id=3066 That seems fine, but can be done faster within the Expat implementation. I've committed the simplified patch as lib/xmlparse.c revision 1.154. I'll have a test case committed tomorrow as well. Leaving this report open for now since I need to finish up the test case. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-30 14:40 Message: Logged In: YES user_id=3066 The Python folks need this dealt with before Python 2.5, so I'll try and take a look at it this weekend if no one beats me to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1515266&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:11:35 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:11:35 +0000 Subject: [Expat-bugs] [ expat-Bugs-2192678 ] zOS make compile fails Message-ID: Bugs item #2192678, was opened at 2008-10-24 16:27 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2192678&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 Private: No Submitted By: John (john_hoel) Assigned to: Greg Stein (gstein) Summary: zOS make compile fails Initial Comment: Building expat on zOS 1.4W. I set the following environment variables for ./configure (without LD it failed): LD=c89 CC=c89 I then had to change all instances of the following in ./configure to make it work (C compiler will not accept .cc extension): ac_ext=cc changed to ac_ext=c Then 'make' failed as follows. How do I change libtool to fix this? make /bin/sh ./libtool --silent --mode=compile c89 -I./lib -I. -g -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -o. make: *** [lib/xmlparse.lo] Error 1 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:11 Message: Following Sebastian's recommendation. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-10-24 17:37 Message: That's sad. So unless there is a more recent version of libtool that can handle this compiler I propose to close this as "won't fix". ---------------------------------------------------------------------- Comment By: John (john_hoel) Date: 2008-10-24 17:27 Message: There is no switch. Simply suppress -o entirely. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-10-24 17:16 Message: I recommend we proceed as following: - Find out if IBM's compiler has a different switch to specify the output filename - If so make libtool handle it in the next release - File a build sytsme update request for Expat after What do you think? ---------------------------------------------------------------------- Comment By: John (john_hoel) Date: 2008-10-24 17:08 Message: No, that error stopped me cold. I need to remove the '-o' command line argument and the generated libtool is impossible to understand (at least for me). c89 is the name of the IBM ANSI C/C++ compiler on zOS. There is nothing 'behind' it. ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-10-24 17:05 Message: John, have you tried renaming occurences of ".lo" (or "lo" but I guess that's too general) within related files? What compiler is running behind "c89"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2192678&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:15:44 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:15:44 +0000 Subject: [Expat-bugs] [ expat-Bugs-1990430 ] Parser crash with specially formatted UTF-8 sequences Message-ID: Bugs item #1990430, was opened at 2008-06-11 00:45 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1990430&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org >Group: Test Required Status: Open Resolution: Fixed Priority: 5 Private: Yes Submitted By: Peter Valchev (petervalchev) Assigned to: Karl Waclawek (kwaclaw) Summary: Parser crash with specially formatted UTF-8 sequences Initial Comment: I have discovered a way to crash libexpat's xml parser with certain specially formatted UTF-8 sequences. All applications that link w/ expat and use it to render user-provided XML files are affected. As far as I see, the issue is not exploitable, just denial of service. This is the patch that I have come up with, also attached to this email: +++ lib/xmltok_impl.c 2007-12-21 11:11:42.054417000 -0800 @@ -1745,6 +1745,9 @@ switch (BYTE_TYPE(enc, ptr)) { #define LEAD_CASE(n) \ case BT_LEAD ## n: \ + if (end - ptr < n) { \ + return; \ + } \ ptr += n; \ break; LEAD_CASE(2) LEAD_CASE(3) LEAD_CASE(4) The parser's updatePosition function which keeps track of the current position pointer increments the ptr by {2, 3, 4} to skip past multibyte character ombinations, and this causes ptr in the "while (ptr != end)" loop to jump past the terminating condition, causing the loop to continue reading past 'end' and into out of bounds memory until a crash. In general this parser does not appear the most robust and could be the source of some security issues. A fault file is attached. To reproduce, compile examples/outline.c and run against it. This patch may not be 100% complete... Contact: Peter Valchev ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:15 Message: Has anyone tested current CVS for this issue's fix? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2008-06-13 13:48 Message: Logged In: YES user_id=290026 Originator: NO I know what you mean and I had the exact same thoughts. I think at least for older CPUs doing a "<" comparison might have been slower than doing a comparison for equality, so I am not sure how that would work out now. Also, we have to consider that this could modify the logic, with a slight risk of introducing an error. Anyway, I think there are other parts of the code (like the encoding checking) that ensures that pathological situations like the one you found don't happen. It is also important to observe that the crash seems to happen only *after* the parser returned with an error, and the code gets called again to get the error location while the parser is already in an error state. Don't forget, Expat is by default installed on most Linux distributions and it is used by Firefox/Mozilla, so Expat has been given a real good workout with millions of installations. The bugs you reported are the first bug reports we received in a long time (except for platform specific build issues). Nevertheless, please keep digging, we really want Expat to be resistant to pathological input. Thanks for the efforts, Karl ---------------------------------------------------------------------- Comment By: Peter Valchev (petervalchev) Date: 2008-06-13 12:41 Message: Logged In: YES user_id=2114255 Originator: YES Yes, I originally had the same patch (while ptr < end) but chose the latter to keep in line with the rest of the file, sigh. Now the next question is, there are many while (ptr != end) loops still left in that file if you search.. some of the look like they could have the same problem. Should all of them be changed, to be on the paranoid side? The original construct is just evil and waiting for bugs like this to happen... ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2008-06-13 09:24 Message: Logged In: YES user_id=290026 Originator: NO I applied the original fix I had in mind, which I didn't use because I thought yours might perform better. It is quite simple: replace "while (ptr != end)" with "while (ptr < end)". Seems to work so far. Fixed in xmltok_impl.c rev. 1.15. Karl ---------------------------------------------------------------------- Comment By: Peter Valchev (petervalchev) Date: 2008-06-13 01:15 Message: Logged In: YES user_id=2114255 Originator: YES Ugh the padding I inserted broke the example. New attached tarball with expat-fault3.xml crashes both outline and xmlwf (gdb) r < /tmp/expat-fault3. Starting program: /usr/src/lib/libexpat/examples/outline < /tmp/expat-fault3. /bin/ksh: cannot open /tmp/expat-fault3.: No such file or directory Program exited with code 01. You can't do that without a process to debug. (gdb) r < /tmp/expat-fault3.xml Starting program: /usr/src/lib/libexpat/examples/outline < /tmp/expat-fault3.xml Program received signal SIGSEGV, Segmentation fault. little2_updatePosition (enc=0x2676dec0, ptr=0x7f4ba000
, end=0x7f4b9003 "", pos=0x7de87198) at xmltok_impl.c:1748 1748 switch (BYTE_TYPE(enc, ptr)) { (gdb) bt #0 little2_updatePosition (enc=0x2676dec0, ptr=0x7f4ba000
, end=0x7f4b9003 "", pos=0x7de87198) at xmltok_impl.c:1748 #1 0x0676b8a3 in XML_GetCurrentLineNumber (parser=0x7de87000) at /usr/src/lib/libexpat/lib/xmlparse.c:1799 #2 0x1c000a24 in main () File Added: expat-fault3.tar.gz ---------------------------------------------------------------------- Comment By: Peter Valchev (petervalchev) Date: 2008-06-13 01:14 Message: Logged In: YES user_id=2114255 Originator: YES Ugh the padding I inserted broke the example. New attached tarball with expat-fault3.xml crashes both outline and xmlwf (gdb) r < /tmp/expat-fault3. Starting program: /usr/src/lib/libexpat/examples/outline < /tmp/expat-fault3. /bin/ksh: cannot open /tmp/expat-fault3.: No such file or directory Program exited with code 01. You can't do that without a process to debug. (gdb) r < /tmp/expat-fault3.xml Starting program: /usr/src/lib/libexpat/examples/outline < /tmp/expat-fault3.xml Program received signal SIGSEGV, Segmentation fault. little2_updatePosition (enc=0x2676dec0, ptr=0x7f4ba000
, end=0x7f4b9003 "", pos=0x7de87198) at xmltok_impl.c:1748 1748 switch (BYTE_TYPE(enc, ptr)) { (gdb) bt #0 little2_updatePosition (enc=0x2676dec0, ptr=0x7f4ba000
, end=0x7f4b9003 "", pos=0x7de87198) at xmltok_impl.c:1748 #1 0x0676b8a3 in XML_GetCurrentLineNumber (parser=0x7de87000) at /usr/src/lib/libexpat/lib/xmlparse.c:1799 #2 0x1c000a24 in main () File Added: expat-fault3.tar.gz ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2008-06-12 22:40 Message: Logged In: YES user_id=290026 Originator: NO What is supposed to happen with the second test case? It reports an error, but does not crash with xmlwf or outline. IE reports the same error, so that is probably OK. ---------------------------------------------------------------------- Comment By: Peter Valchev (petervalchev) Date: 2008-06-12 18:08 Message: Logged In: YES user_id=2114255 Originator: YES Thanks. Actually rechecking in this area again, I think I found another issue, which seems to not be covered with the patch I provided :( I am attaching the new test case. I haven't found many other issues at this point... I stumbled upon this one fairly quickly and my above observations were more general than anything. If I do find more I'll be sure to tell you. File Added: expat-fault2.xml ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2008-06-11 10:46 Message: Logged In: YES user_id=290026 Originator: NO Can reproduce. The problem is that this code can be called *after* an error has been found (to report line and column number). Therefore it should not rely on correct byte counts for multibyte characters. Patch applied in xmltok_impl.c rev. 1.14. Would you please also report all the other issues you have found? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1990430&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:27:40 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:27:40 +0000 Subject: [Expat-bugs] [ expat-Bugs-2038222 ] Linux Build missing expat.h ? Message-ID: Bugs item #2038222, was opened at 2008-08-04 21:09 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2038222&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 Private: No Submitted By: Antony (somervia) Assigned to: Greg Stein (gstein) Summary: Linux Build missing expat.h ? Initial Comment: bash-2.05b# /data/configs/dnsOne/API/perl/bin/perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser bash-2.05b# make make[1]: Entering directory `/data/configs/dnsOne/API/dependancies/XML-Parser-2.36/Expat' cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /data/configs/dnsOne/API/perl/bin/perl /data/configs/dnsOne/API/perl/lib/5.10.0/ExtUtils/xsubpp -noprototypes -typemap /data/configs/dnsOne/API/perl/lib/5.10.0/ExtUtils/typemap -typemap typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c cc -c -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -DVERSION=\"2.36\" -DXS_VERSION=\"2.36\" -fPIC "-I/data/configs/dnsOne/API/perl/lib/5.10.0/i686-linux/CORE" Expat.c Expat.xs:12:19: expat.h: No such file or directory Expat.xs:60: syntax error before "XML_Parser" Expat.xs:60: warning: no semicolon at end of struct or union ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:27 Message: This is the wrong place for the Perl bindings of Expat. ---------------------------------------------------------------------- Comment By: Antony (somervia) Date: 2008-08-04 21:18 Message: Logged In: YES user_id=2168393 Originator: YES -bash-2.05b$ uname -a Linux somehost 2.4.21-47.0.1.ELsmp #1 SMP Fri Oct 13 17:56:20 EDT 2006 i686 i686 i386 GNU/Linux -bash-2.05b$ cc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58) -bash-2.05b$ /data/configs/dnsOne/API/perl/bin/perl -v This is perl, v5.10.0 built for i686-linux Copyright 1987-2007, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. -bash-2.05b$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2038222&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:31:12 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:31:12 +0000 Subject: [Expat-bugs] [ expat-Bugs-1983953 ] outdated config.sub/config.guess Message-ID: Bugs item #1983953, was opened at 2008-06-03 18:39 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&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: Accepted Priority: 5 Private: No Submitted By: Scott McCreary (scottmc) >Assigned to: Sebastian Pipping (hartwork) Summary: outdated config.sub/config.guess Initial Comment: Seems to be time to update config.sub and config.guess again. Haiku for one needs this to be updated: http://tools.assembla.com/BePorts/wiki/dev-libs/expat ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:31 Message: Sorry for forgetting about this one - way too busy in the last 6 months. OK, Sebastian, go ahead. To be honest, I have to trust you on this one, I have never been a build expert on Linux. Karl ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 11:57 Message: Logged In: YES user_id=1022691 Originator: NO [2/2] This patch would be needed for Haiku on top of the former. Extracted from the source given by Scott. Do I have green for both? File Added: expat_cvs_head_1983953_2_satisfy_haiku.patch ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 11:54 Message: Logged In: YES user_id=1022691 Originator: NO [1/2] Here's the patch to update our CVS head to config.{guess,sub} of libTool 1.5.26. File Added: expat_cvs_head_1983953_1_update_libtool_1_5_26.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:33:14 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:33:14 +0000 Subject: [Expat-bugs] [ expat-Bugs-1796209 ] Build failed on SUSE linux with gcc (GCC) version 3.2 Message-ID: Bugs item #1796209, was opened at 2007-09-17 09:22 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1796209&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Build failed on SUSE linux with gcc (GCC) version 3.2 Initial Comment: we are looking for a UNICODE build of expat-2.0.1 our platform details are as follows : OS name and version details : SUSE Linux 2.4.21-138-default i686 gcc compiler version: 3.2 we have followed following steps: 1) ./configure --prefix=/home/eXpat/binaries/debug/ --disable-static CFLAGS="-g -O2 -fshort-wchar" CPPFLAGS="-DXML_UNICODE_WCHAR_T" 2)make then it throws following errors : /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /home/gcuser/venkat/eXpat/binaries/debug//lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c xmlwf/xmlwf.c: In function `characterData': xmlwf/xmlwf.c:34: warning: implicit declaration of function `fputws' xmlwf/xmlwf.c:53: warning: implicit declaration of function `fwprintf' xmlwf/xmlwf.c:57: warning: implicit declaration of function `putwc' xmlwf/xmlwf.c: In function `attcmp': xmlwf/xmlwf.c:117: warning: implicit declaration of function `wcscmp' xmlwf/xmlwf.c: In function `nsattcmp': xmlwf/xmlwf.c:159: warning: implicit declaration of function `wcsrchr' xmlwf/xmlwf.c: In function `startElementNS': xmlwf/xmlwf.c:176: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c:197: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c: In function `endElementNS': xmlwf/xmlwf.c:222: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c: In function `metaStartElement': xmlwf/xmlwf.c:353: warning: implicit declaration of function `wcslen' xmlwf/xmlwf.c: In function `unknownEncoding': xmlwf/xmlwf.c:575: warning: implicit declaration of function `wcschr' xmlwf/xmlwf.c:575: warning: initialization makes pointer from integer without a cast xmlwf/xmlwf.c: At top level: xmlwf/xmlwf.c:644: warning: no previous prototype for `wmain' xmlwf/xmlwf.c: In function `wmain': xmlwf/xmlwf.c:779: warning: initialization makes pointer from integer without a cast xmlwf/xmlwf.c:795: warning: implicit declaration of function `wcscpy' xmlwf/xmlwf.c:796: warning: implicit declaration of function `wcscat' xmlwf/xmlwf.c:798: warning: implicit declaration of function `_wfopen' xmlwf/xmlwf.c:798: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c:800: warning: implicit declaration of function `_wperror' xmlwf/xmlwf.c:853: warning: implicit declaration of function `_wremove' gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c xmlwf/xmlfile.c: In function `reportError': xmlwf/xmlfile.c:66: warning: implicit declaration of function `fwprintf' xmlwf/xmlfile.c: In function `resolveSystemId': xmlwf/xmlfile.c:114: warning: implicit declaration of function `wcslen' xmlwf/xmlfile.c:118: warning: implicit declaration of function `wcscpy' xmlwf/xmlfile.c:120: warning: implicit declaration of function `wcsrchr' xmlwf/xmlfile.c:121: warning: assignment makes pointer from integer without a cast xmlwf/xmlfile.c: In function `processStream': xmlwf/xmlfile.c:160: warning: implicit declaration of function `_wopen' xmlwf/xmlfile.c:162: warning: implicit declaration of function `_wperror' xmlwf/xmlfile.c:173: warning: pointer type mismatch in conditional expression xmlwf/xmlfile.c:178: warning: pointer type mismatch in conditional expression xmlwf/xmlfile.c:184: warning: pointer type mismatch in conditional expression gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/codepage.o -c xmlwf/codepage.c gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la /usr/lib/gcc-lib/i486-suse-linux/3.2/../../../crt1.o: In function `_start': /usr/lib/gcc-lib/i486-suse-linux/3.2/../../../crt1.o(.text+0x18): undefined reference to `main' xmlwf/xmlwf.o: In function `wmain': /home/gcuser/venkat/eXpat/expat-2.0.1/xmlwf/xmlwf.c:798: undefined reference to `_wfopen' /home/gcuser/venkat/eXpat/expat-2.0.1/xmlwf/xmlwf.c:853: undefined reference to `_wremove' /home/gcuser/venkat/eXpat/expat-2.0.1/xmlwf/xmlwf.c:800: undefined reference to `_wperror' xmlwf/xmlfile.o: In function `processStream': /home/gcuser/venkat/eXpat/expat-2.0.1/xmlwf/xmlfile.c:160: undefined reference to `_wopen' /home/gcuser/venkat/eXpat/expat-2.0.1/xmlwf/xmlfile.c:178: undefined reference to `_wperror' /home/gcuser/venkat/eXpat/expat-2.0.1/xmlwf/xmlfile.c:162: undefined reference to `_wperror' collect2: ld returned 1 exit status make: *** [xmlwf/xmlwf] Error 1 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:33 Message: Fred, can we close this issue, or is there something to do? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2007-11-09 08:32 Message: Logged In: YES user_id=3066 Originator: NO Not if I'm actually careful about building it; reconfiguring an existing build doesn't cause the object files to be re-built, so I was still using the UTF-8 build. Doing a "make clean" before reconfiguring yields similar results on my Mac OS X (Leopard) machine (errors below). I don't think this ever worked before, but I've rarely built anything other than the UTF-8 version. /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c xmlwf/xmlwf.c: In function ?characterData?: xmlwf/xmlwf.c:34: warning: implicit declaration of function ?fputws? xmlwf/xmlwf.c:53: warning: implicit declaration of function ?fwprintf? xmlwf/xmlwf.c:57: warning: implicit declaration of function ?putwc? xmlwf/xmlwf.c: In function ?attcmp?: xmlwf/xmlwf.c:117: warning: implicit declaration of function ?wcscmp? xmlwf/xmlwf.c: In function ?nsattcmp?: xmlwf/xmlwf.c:159: warning: implicit declaration of function ?wcsrchr? xmlwf/xmlwf.c: In function ?startElementNS?: xmlwf/xmlwf.c:176: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c:197: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c: In function ?endElementNS?: xmlwf/xmlwf.c:222: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c: In function ?metaStartElement?: xmlwf/xmlwf.c:353: warning: implicit declaration of function ?wcslen? xmlwf/xmlwf.c: In function ?unknownEncoding?: xmlwf/xmlwf.c:575: warning: implicit declaration of function ?wcschr? xmlwf/xmlwf.c:575: warning: initialization makes pointer from integer without a cast xmlwf/xmlwf.c: At top level: xmlwf/xmlwf.c:644: warning: no previous prototype for ?wmain? xmlwf/xmlwf.c: In function ?wmain?: xmlwf/xmlwf.c:779: warning: initialization makes pointer from integer without a cast xmlwf/xmlwf.c:795: warning: implicit declaration of function ?wcscpy? xmlwf/xmlwf.c:796: warning: implicit declaration of function ?wcscat? xmlwf/xmlwf.c:798: warning: implicit declaration of function ?_wfopen? xmlwf/xmlwf.c:798: warning: assignment makes pointer from integer without a cast xmlwf/xmlwf.c:800: warning: implicit declaration of function ?_wperror? xmlwf/xmlwf.c:853: warning: implicit declaration of function ?_wremove? gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c xmlwf/xmlfile.c: In function ?reportError?: xmlwf/xmlfile.c:66: warning: implicit declaration of function ?fwprintf? xmlwf/xmlfile.c: In function ?resolveSystemId?: xmlwf/xmlfile.c:114: warning: implicit declaration of function ?wcslen? xmlwf/xmlfile.c:118: warning: implicit declaration of function ?wcscpy? xmlwf/xmlfile.c:120: warning: implicit declaration of function ?wcsrchr? xmlwf/xmlfile.c:121: warning: assignment makes pointer from integer without a cast xmlwf/xmlfile.c: In function ?processStream?: xmlwf/xmlfile.c:160: warning: implicit declaration of function ?_wopen? xmlwf/xmlfile.c:162: warning: implicit declaration of function ?_wperror? xmlwf/xmlfile.c:173: warning: pointer type mismatch in conditional expression xmlwf/xmlfile.c:178: warning: pointer type mismatch in conditional expression xmlwf/xmlfile.c:184: warning: pointer type mismatch in conditional expression gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/codepage.o -c xmlwf/codepage.c gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c /bin/sh ./libtool --silent --mode=link gcc -std=gnu99 -I./lib -I. -g -O2 -fshort-wchar -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DXML_UNICODE_WCHAR_T -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la Undefined symbols: "__wfopen", referenced from: _wmain in xmlwf.o "_main", referenced from: start in crt1.10.5.o "__wopen", referenced from: _processStream in xmlfile.o "__wremove", referenced from: _wmain in xmlwf.o "__wperror", referenced from: _wmain in xmlwf.o _processStream in xmlfile.o _processStream in xmlfile.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [xmlwf/xmlwf] Error 1 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-11-09 08:03 Message: Logged In: YES user_id=290026 Originator: NO I am not even sure xmlwf was ever meant to be built for UTF-16. The README seems to mention that (under Unix) you should only run "make buildlib" for UTF-16 output, which builds the Expat library itself, and nothing else. Fred, does a complete UTF-16 build really work for you? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2007-11-08 23:20 Message: Logged In: YES user_id=3066 Originator: NO I don't have access to a SUSE linux system at this time; hopefully someone else will be able to test and reproduce. I'll see if I can put together a SUSE linux environment if I can squeeze out some time, but I don't know anything about that distribution, so I may be stabbing in the dark. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-09-17 10:26 Message: Logged In: YES user_id=290026 Originator: NO It looks like the Expat parser still builds OK, but xmlwf doesn't. Not sure if any of our Unix experts can step in to resolve this issue ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1796209&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:37:38 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:37:38 +0000 Subject: [Expat-bugs] [ expat-Bugs-1715957 ] pkg-config file please Message-ID: Bugs item #1715957, was opened at 2007-05-09 13:25 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715957&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Aidan Delaney (aidandelaney) Assigned to: Greg Stein (gstein) Summary: pkg-config file please Initial Comment: Any chance of an expat.pc pkg-config file? ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:37 Message: Addressed in issue #1749198. ---------------------------------------------------------------------- Comment By: Dan Nicholson (dbnichol) Date: 2007-07-06 11:44 Message: Logged In: YES user_id=1198355 Originator: NO Sorry, Sourceforge makes me want to cry. See here: http://sourceforge.net/tracker/index.php?func=detail&aid=1749198&group_id=10127&atid=310127 I didn't know that was going to create a new bug. Does anyone know why I can't just add an attachment to this bug? ---------------------------------------------------------------------- Comment By: Dan Nicholson (dbnichol) Date: 2007-07-06 10:56 Message: Logged In: YES user_id=1198355 Originator: NO I've written a patch which works on my Linux system. It's pretty straightforward and non-intrusive to the rest of the build. Since I can't figure out how to add an attachment in Sourceforge, patch is here: http://www.linuxfromscratch.org/~dnicholson/patches/expat-pkgconfig.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1715957&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:40:39 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:40:39 +0000 Subject: [Expat-bugs] [ expat-Bugs-1785430 ] expat build fails on linux-amd64 with gcc version>=4.1 -O3 Message-ID: Bugs item #1785430, was opened at 2007-08-31 04:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1785430&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Karl Waclawek (kwaclaw) Summary: expat build fails on linux-amd64 with gcc version>=4.1 -O3 Initial Comment: Hi, xmlparse.c contains a cast from const XML_Char* to XML_Char* which newer versions of gcc don't like at all. cc1: warnings being treated as errors src/external/expat-2.0.0/lib/xmlparse.c: In function 'doProlog': src/external/expat-2.0.0/lib/xmlparse.c:3771: warning: passing argument 1 of 'normalizePublicId' discards qualifiers from pointer target type make: *** [obj/src/external/expat-2.0.0/lib/xmlparse.o] Error 1 Thus I devised the attached work-around. Regards, Thomas Jahns ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:40 Message: Is anyone testing this? I'd like to close this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-09-03 12:35 Message: Logged In: YES user_id=290026 Originator: NO Fixed in xmlparse.c 1.1.62. Please check out from CVS and test! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1785430&group_id=10127 From noreply at sourceforge.net Sat Jan 17 17:43:36 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 16:43:36 +0000 Subject: [Expat-bugs] [ expat-Bugs-1463666 ] expat-1.95.8 linking fails on aix Message-ID: Bugs item #1463666, was opened at 2006-04-03 12:34 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1463666&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 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: expat-1.95.8 linking fails on aix Initial Comment: *** expat-1.95.8/Makefile.in Mon Apr 3 11:21:48 2006 --- expat-1.95.8/Makefile.in Mon Apr 3 11:22:19 2006 *************** *** 103,109 **** LIBTOOL = @LIBTOOL@ INCLUDES = -I$(srcdir)/lib -I. ! LDFLAGS = @LDFLAGS@ CPPFLAGS = @CPPFLAGS@ CFLAGS = @CFLAGS@ -DHAVE_EXPAT_CONFIG_H VSNFLAG = -version-info @LIBCURRENT@:@LIBREVISION@:@LIBAGE@ --- 103,109 ---- LIBTOOL = @LIBTOOL@ INCLUDES = -I$(srcdir)/lib -I. ! LDFLAGS = @LDFLAGS@ -static CPPFLAGS = @CPPFLAGS@ CFLAGS = @CFLAGS@ -DHAVE_EXPAT_CONFIG_H VSNFLAG = -version-info @LIBCURRENT@:@LIBREVISION@:@LIBAGE@ ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:43 Message: No follow-ups. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:06 Message: Logged In: YES user_id=290026 Greg, can you clear this up? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-04-03 19:05 Message: Logged In: YES user_id=290026 I am not the Unix build expert here, and don't know what effect this has on builds for other platforms. AFAIK, Expat should build and link OK on AIX. You should contact Greg Stein about it. Have you tried Expat 2.0 yet? Does the problem still exist? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-04-03 18:24 Message: Logged In: NO It fixes Makefile.in so that the resultant expat library can be linked into applications on aix. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-04-03 15:45 Message: Logged In: YES user_id=290026 I don't understand. What does the diff above describe? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1463666&group_id=10127 From noreply at sourceforge.net Sat Jan 17 19:27:40 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 18:27:40 +0000 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 12:36 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Test Required >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: additional config for INSTALL_ROOT Initial Comment: When I install expat 2.0.0, it shows me the following error always. but expat 1.9.5 is fine. camelot# make install make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen the line 48 is as following: 47:ifndef INSTALL_ROOT 48:INSTALL_ROOT=$(DESTDIR) 49:if ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 13:27 Message: No complaints received. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-10 09:00 Message: Logged In: YES user_id=290026 Originator: NO Good! Now, if Enrico confirms that it still works for him, I'll close this issue as fixed. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-10 05:51 Message: Logged In: YES user_id=839786 Originator: NO Works as (I have) expected here on solaris9, solaris10, aix53, hpux11.11, hpux11.23 and interix now, thanks! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 14:39 Message: Logged In: YES user_id=290026 Originator: NO Correction: I went back to CVS and realized, before Enrico's patch, neither INSTALL_ROOT and DESTDIR were handled in the makefile. So I went ahead and committed the latest proposal. Applied in Makefile.in rev. 1.58. Please check out and test. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-09 13:10 Message: Logged In: YES user_id=290026 Originator: NO Before Enrico's change, we had exactly what Michael is suggesting, only that the roles of DESTDIR and INSTALL_ROOT were exchanged. Why does the newest proposal work, and not the the way it used to be before the we introduced the conditional? Does this have to do with how each of them is "usually" used? By changing to the new proposal, whose usage patterns would we break? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-09 12:50 Message: Logged In: YES user_id=839786 Originator: NO > Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) > many people use DESTDIR. To reduce confusions, I intendet to support both > variables. As you do not use DESTDIR as make-argument, but INSTALL_ROOT as environment variable, my proposed change should work, because INSTALL_ROOT itself is not defined in the Makefile, and thus the environment-value of INSTALL_ROOT is used for DESTDIR (see also '-e' below). In GNU world, DESTDIR normally is used as make-parameter, not from environment, so when DESTDIR is set as make-argument, INSTALL_ROOT environment variable becomes irrelevant. > But I really suggest evryone to use GNU make, even on nun-GNU platforms > (AFAIK it should run on most other unix'es too). This releaves us from the > ugly job of supporting each single esotic make. Agreed somewhat - but if it is that easy to avoid an additional specific dependency, why not do it (especially if you do not need to fix it yourself) ? > Ah, important to mention: env variables should *NOT* be overwritten by > defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" > or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's > life much, much easier. This only is true if you pass '-e' to make(1), as stated in the manpages, it is _not_ done by default: -e, --environment-overrides Give variables taken from the environment precedence over vari- ables from makefiles. According to their manpages, this is true for GNU-make as well as native make on hpux, aix, solaris, freebsd, interix (do not have access to others). With my proposed patch, both your methods should work. It will not work only if you: 1) have DESTDIR in the environment set to a value != INSTALL_ROOT 2) _and_ pass '-e' to make (commandline or in MAKEFLAGS/MFLAGS environment variable). ---------------------------------------------------------------------- Comment By: kosch (kosch) Date: 2007-05-09 12:15 Message: Logged In: YES user_id=34470 Originator: NO Hi folks, as I'm the one who introduced that change I should tell you why I did it that way: Traditionally we use INSTALL_ROOT @ expat. But (especially in GNU world) many people use DESTDIR. To reduce confusions, I intendet to support both variables. The order is irrelevant for me, so I assume either one of them is set (if both, they really should have the same value). In case of not being empty, it should stay so. I'm not sure how non-GNU make's handle conditionals - I never used 'em ;-O But I really suggest evryone to use GNU make, even on nun-GNU platforms (AFAIK it should run on most other unix'es too). This releaves us from the ugly job of supporting each single esotic make. Ah, important to mention: env variables should *NOT* be overwritten by defaults. It really should be irrelevant if I cal "INSTALL_ROOT=... make" or "make install INSTALL_ROOT=...". This makes distro-maintainer/sysop's life much, much easier. cu ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-08 21:23 Message: Logged In: YES user_id=290026 Originator: NO > I've got another idea now: > If you really need/want to support the latter, completely switch to DESTDIR, > and use $(INSTALL_ROOT) as the default-value for DESTDIR: Can anyone conform that this will do the same job as the existing make instructions? Fred? Greg? ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-05-07 04:50 Message: Logged In: YES user_id=839786 Originator: NO Hmm, in those two bugs they all want to use DESTDIR, not INSTALL_ROOT. Thus I cannot find a reason for setting INSTALL_ROOT only if empty or undefined. Non-GNU make do not understand any "if" direction, this is a GNU-make extension only. AFAIKT package builders want to use (the automake-style): $ make install DESTDIR=/path/to/imagedir instead of (which style is this one ?): $ INSTALL_ROOT=/path/to/imagedir make install 've got another idea now: If you really need/want to support the latter, completely switch to DESTDIR, and use $(INSTALL_ROOT) as the default-value for DESTDIR: -ifndef INSTALL_ROOT -INSTALL_ROOT=$(DESTDIR) -endif +DESTDIR=$(INSTALL_ROOT) install: xmlwf/xmlwf installlib - $(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL_ROOT)$(man1dir) + $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) Why this works: $ make install DESTDIR=/path/to/image overrides the in-makefile set DESTDIR, while both $ INSTALL_ROOT=/path/to/image make install $ make install INSTALL_ROOT=/path/to/image use DESTDIR=$(INSTALL_ROOT), even if DESTDIR eventually is defined in the environment, because variable-setting priority is 1) commandline 2) in-makefile 3) environment Or do you have other requirements I've not seen yet ? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:27 Message: Logged In: YES user_id=290026 Originator: NO The reason why the condition syntax was introduced is to support package builders. See bugs # 985235, 1217217 and patch # 779334. Now, we have to concede that Expat builds are targeted towards the GNU tool chain. We do try hard to make our build system work on other platforms, but the syntax of make file is unfortunately too different on the various platforms, so we really can't satisfy everyone. In an attempt to make Makefile.in more compatibl across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Michael Haubenwallner (mhaubi) Date: 2007-01-25 08:18 Message: Logged In: YES user_id=839786 Originator: NO Using "INSTALL_ROOT ?= ${DESTDIR}" still seems to work with GNU make only. It does not work with native make at least on these platforms: hpux11.11, hpux11.23, aix5.2, solaris2.9 I have tried expat-2.0.0 with changing the "ifndef-endif" to "?=" Question is why setting INSTALL_ROOT unconditionally is not sufficient ? INSTALL_ROOT = ${DESTROOT} Thing is, when calling make install INSTALL_ROOT=/some/install/root the commandline value has precedence over the value set in Makefile, so for this style of doing 'make install' there is no need to set INSTALL_ROOT conditionally. OTOH, an automake-using package needs to be installed using this style: make install DESTDIR=/some/install/root This works if there is no condition, but it may not work if INSTALL_ROOT is preset in the environment... Well, I can think of only one (uncommon?) style of doing 'make install' which requires that condition: INSTALL_ROOT=/some/install/root make install Has this style been used in the past ? And if so, is there any requirement where this style needs to continue to work ? ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-13 19:17 Message: Logged In: YES user_id=1660778 Originator: NO Yep removing the 3 lines seems to correct the problem on Solaris CC ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:29 Message: Logged In: YES user_id=290026 Originator: NO It seems the ifndef syntax is only supported by GNU Make. I think that using "?=" instead is acceptable, although it is not the same. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. Made the change accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Todd Rinaldo (todd_rinaldo) Date: 2006-12-04 16:13 Message: Logged In: YES user_id=1660778 Originator: NO I too am having this problem... downloaded the gz, not the CVS ./configure --prefix=/apps/customdir/perl588_32/site ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 13:07 Message: Logged In: YES user_id=290026 Originator: NO What happens if you check out from CVS and then run make-release.sh to build your own tarball? Does that work? If no response I'll close this issue. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-04 12:54 Message: Logged In: NO Same problem with the .gz file expat-2.0.0 Solaris 5.10 root cosmo #./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -fPIC checking if f77 PIC flag -fPIC works... no checking if f77 static flag -static works... no checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ccs/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... f90: Warning: Option -print-search-dirs passed to ld, if ld is invoked, ignored otherwise Usage: f90 [ options ] files. Use 'f90 -flags' for details solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install-sh -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h config.status: expat_config.h is unchanged root cosmo #make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 15:32 Message: Logged In: NO Sorry, it's Solaris 9 :-). But you get the idea - same error as other people. I also tried './configure --prefix =/usr/local', no difference. Changed ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) endif to INSTALL_ROOT=$(prefix) and it put eveything in /usr/local/usr/local. Perhaps a Solaris/GNU make syntax problem. Tried GNU make, no luck. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-27 14:46 Message: Logged In: NO I'm getting the same error, expat-2.0.0.tar.gz, Solaris 8 on Sparc, using Sun Forte 7 cc. zeus:/tmp/expat-2.0.0# which make /usr/ccs/bin/make zeus:/tmp/expat-2.0.0# which cc /opt/forte7/SUNWspro/bin/cc zeus:/tmp/expat-2.0.0# ./configure checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... egrep checking for non-GNU ld... /usr/ucb/ld checking if the linker (/usr/ucb/ld) is GNU ld... no checking for /usr/ucb/ld option to reload object files... - r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... CC checking whether we are using the GNU C++ compiler... no checking whether CC accepts -g... yes checking how to run the C++ preprocessor... CC -E checking for g77... no checking for f77... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/ccs/bin/nm -p output from cc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for cc option to produce PIC... -KPIC checking if cc PIC flag -KPIC works... yes checking if cc static flag -Bstatic works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking for CC option to produce PIC... -KPIC checking if CC PIC flag -KPIC works... yes checking if CC static flag -Bstatic works... yes checking if CC supports -c -o file.o... yes checking whether the CC linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for f77 option to produce PIC... -KPIC checking if f77 PIC flag -KPIC works... yes checking if f77 static flag -Bstatic works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/ucb/ld) supports shared libraries... yes checking dynamic linker characteristics... solaris2.9 ld.so checking how to hardcode library paths into programs... immediate checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) no checking whether cc accepts -g... (cached) yes checking for cc option to accept ANSI C... (cached) none needed checking for a BSD-compatible install... conftools/install- sh -c checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for memmove... yes checking for bcopy... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for off_t... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for an ANSI C99-conforming __func__... yes configure: creating ./config.status config.status: creating Makefile config.status: creating expat_config.h zeus:/tmp/expat-2.0.0# make make: Fatal error in reader: Makefile, line 48: Unexpected end of line seen INSTALL_ROOT=$(DESTDIR) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-01 17:01 Message: Logged In: YES user_id=290026 Could you please try a checkout from CVS. If you still have a problem, then maybe "make" on your system is too old, or otherwise different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-06-01 16:33 Message: Logged In: NO I'm having the same problem building in a Solaris 10 on Sparc environment. I'm using 2.0.0 from a .gz tarball. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-17 13:19 Message: Logged In: YES user_id=290026 In which environment do you try to build expat? Is this a checkout from CVD or did you download the .gz archive? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1490371&group_id=10127 From noreply at sourceforge.net Sat Jan 17 19:29:45 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 18:29:45 +0000 Subject: [Expat-bugs] [ expat-Bugs-1498374 ] runtests.cpp does not compile Message-ID: Bugs item #1498374, was opened at 2006-05-31 13:51 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1498374&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: runtests.cpp does not compile Initial Comment: The Makefile of the test directory includes -I./lib and not -I../lib for expat.h and expat_external.h If there is no installed copy of the .h filesn compile of runtests.c doesn't work. Looks like the Makefile.in is not correct. peter.sylvester at edelweb.fr ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 13:29 Message: Seems this was fixed by another issue's fix. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-05-28 07:06 Message: Logged In: NO The following change (as pointed by http://sourceforge.net/tracker/index.php?func=detail&aid=1597115&group_id=10127&atid=110127) works for me: --- expat-2.0.0/Makefile.in.old 2007-05-28 10:58:17.000000000 +0000 +++ expat-2.0.0/Makefile.in 2007-05-28 10:48:18.000000000 +0000 @@ -107,7 +107,7 @@ INCLUDES = -I$(srcdir)/lib -I. LDFLAGS = @LDFLAGS@ -CPPFLAGS = @CPPFLAGS@ +CPPFLAGS = @CPPFLAGS@ $(INCLUDES) $(DEFS) CFLAGS = @CFLAGS@ -DHAVE_EXPAT_CONFIG_H VSNFLAG = -version-info @LIBCURRENT@:@LIBREVISION@:@LIBAGE@ ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-01 11:59 Message: Logged In: YES user_id=3066 There is no Makefile in the tests/ directory; the top-level Makefile is responsible for building the tests. When that runs, the top-level directory should be the current directory, so ./lib is the right path for the includes. Unfortunately, I don't have access to a machine that doesn't have at least some version of Expat installed by the base system, so I'll leave this open until I have a chance to run that test to confirm. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-05-31 13:56 Message: Logged In: YES user_id=290026 I think Fred needs something to do. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1498374&group_id=10127 From noreply at sourceforge.net Sat Jan 17 19:30:33 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 18:30:33 +0000 Subject: [Expat-bugs] [ expat-Bugs-1613457 ] Makefile.in problem on NETBSD 3.1 Message-ID: Bugs item #1613457, was opened at 2006-12-11 14:50 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1613457&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Makefile.in problem on NETBSD 3.1 Initial Comment: After running the configure script, then trying to run make, it errors out: squallbsr at karasu2 [~/source/expat-2.0.0]$ make make: "/Users/squallbsr/source/expat-2.0.0/Makefile" line 47: Need an operator make: "/Users/squallbsr/source/expat-2.0.0/Makefile" line 49: Need an operator make: Fatal errors encountered -- cannot continue This can be fixed by adjusting the ifndef INSTALL_ROOT section around lines 47-49 in Makefile.in I changed it to: INSTALL_ROOT ?= $(DESTDIR) which worked on NetBSD and for my application, this of course would need more testing as all I wanted was for expat to complile, not install. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 13:30 Message: No complaints received. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 13:28 Message: Logged In: YES user_id=290026 Originator: NO The latest patch (see the related issue #1490371) removes the conditional directive altogether, but reverses the roles of INSTALL_ROOT and DESDIR. This should hopefully work for most use cases while still being more cross-platform compatible. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:28 Message: Logged In: YES user_id=290026 Originator: NO In an attempt to make Makefile.in more compatible across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: davidharpe (davidharpe) Date: 2007-01-02 14:23 Message: Logged In: YES user_id=1681745 Originator: NO I had the same problem on FreeBSD. Change lines 47-49 to: .ifndef INSTALL_ROOT INSTALL_ROOT=$(DESTDIR) .endif (note the leading period) Seems to work fine. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-13 12:27 Message: Logged In: YES user_id=290026 Originator: NO Well, I thought about it, and "?=" seems acceptable. It only assigns if the symbol is undefined, whereas "ifndef" assigns when the symbol is the empty string or undefined. I'll change that accordingly. Committed in Makefile.in rev. 1.56. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-12 14:32 Message: Logged In: YES user_id=290026 Originator: NO Apparently - after doing a Goole search - Solaris as well as BSD Make have issues with the "ifndef" syntax. Is there a way to keep the logic with another syntax? It looks as if "?=" does not have exactly the same logic. ---------------------------------------------------------------------- Comment By: Bryan Rehbein (squallbsr) Date: 2006-12-11 14:54 Message: Logged In: YES user_id=950269 Originator: NO Bug reported by: br39290 at squall.us ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1613457&group_id=10127 From noreply at sourceforge.net Sat Jan 17 19:31:04 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 18:31:04 +0000 Subject: [Expat-bugs] [ expat-Bugs-1513566 ] readfilemap fails with file size 0 Message-ID: Bugs item #1513566, was opened at 2006-06-27 16:16 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513566&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 Private: No Submitted By: MikeG (greenemk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: readfilemap fails with file size 0 Initial Comment: xmlwf compiled with readfilemap.c will fail with an "out of memory" error on file size zero when executing malloc( ) . The attached patch handles 0 size files in the same manner as in win32filemap.c. The patch also includes a close( ) of the open file if malloc( ) fails. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 13:31 Message: No complaints received. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-11-26 14:52 Message: Logged In: YES user_id=290026 Originator: NO Re-assigned to Fred for testing. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-06-27 22:57 Message: Logged In: YES user_id=290026 The same issue was detected by Mike in unixfilemap.c. Fix committed in readfilemap.c rev. 1.12 and unixfilemap.c rev. 1.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513566&group_id=10127 From noreply at sourceforge.net Sat Jan 17 19:32:06 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 18:32:06 +0000 Subject: [Expat-bugs] [ expat-Bugs-1810655 ] Cannot compile on solaris 8 / gcc-4.2.1 Message-ID: Bugs item #1810655, was opened at 2007-10-10 04:37 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1810655&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Cannot compile on solaris 8 / gcc-4.2.1 Initial Comment: % ./configure --prefix=... % make ... /bin/ksh ./libtool --silent --mode=link gcc -I./lib -I. -I/rtools/workspaces/sol28-64/gcc-4.2.1/readline-5.2/include -I/rtools/workspaces/sol28-64/gcc-4.2.1/bzip2-1.0.4/include -I/rtools/workspaces/sol28-64/gcc-4.2.1/zlib-1.2.3/include -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /rtools/workspaces/sol28-64/gcc-4.2.1/expat-2.0.1/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/readline-5.2/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/bzip2-1.0.4/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/zlib-1.2.3/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ld: warning: option -o appears more than once, first setting taken ld: fatal: file libexpat.so.1: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/libexpat.so.1.5.2 collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 when running ksh -x ./libtool --silent ... ... + : gcc -shared lib/.libs/xmlparse.o lib/.libs/xmltok.o lib/.libs/xmlrole.o -L/rtools/workspaces/sol28-64/gcc-4.2.1/readline-5.2/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/bzip2-1.0.4/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/zlib-1.2.3/lib -lc -Wl,-soname -Wl,libexpat.so.1 -o .libs/libexpat.so.1.5.2 + eval gcc -shared lib/.libs/xmlparse.o lib/.libs/xmltok.o lib/.libs/xmlrole.o -L/rtools/workspaces/sol28-64/gcc-4.2.1/readline-5.2/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/bzip2-1.0.4/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/zlib-1.2.3/lib -lc -Wl,-soname -Wl,libexpat.so.1 -o .libs/libexpat.so.1.5.2 + gcc -shared lib/.libs/xmlparse.o lib/.libs/xmltok.o lib/.libs/xmlrole.o -L/rtools/workspaces/sol28-64/gcc-4.2.1/readline-5.2/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/bzip2-1.0.4/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/zlib-1.2.3/lib -lc -Wl,-soname -Wl,libexpat.so.1 -o .libs/libexpat.so.1.5.2 ld: warning: option -o appears more than once, first setting taken ld: fatal: file libexpat.so.1: open failed: No such file or directory ld: fatal: File processing errors. No output written to .libs/libexpat.so.1.5.2 collect2: ld returned 1 exit status + lt_exit=1 + test link = relink + exit 1 I removed '-Wl,libexpat.so.1' from the cmd and I ran manually : gcc -shared lib/.libs/xmlparse.o lib/.libs/xmltok.o lib/.libs/xmlrole.o -L/rtools/workspaces/sol28-64/gcc-4.2.1/readline-5.2/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/bzip2-1.0.4/lib -L/rtools/workspaces/sol28-64/gcc-4.2.1/zlib-1.2.3/lib -lc -Wl,-soname -o .libs/libexpat.so.1.5.2 which works ... ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 13:32 Message: Maybe Fred has time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1810655&group_id=10127 From noreply at sourceforge.net Sat Jan 17 19:33:55 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jan 2009 18:33:55 +0000 Subject: [Expat-bugs] [ expat-Bugs-1618673 ] expat 2.0.0 compile problem on SCO-Unix 5.0.5 Message-ID: Bugs item #1618673, was opened at 2006-12-19 05:02 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1618673&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: www.libexpat.org Group: Third-party Bug >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat 2.0.0 compile problem on SCO-Unix 5.0.5 Initial Comment: Message from mstabile at metsogeda.it ---------------------------------- Hi, I'm trying to compile your expat 2.0.0 on a sco5.0.5 server but i'm facing with some problems. first: in Makefile.in INSTALL_ROOT ?= $(DESTDIR) or previous ifndef ... sentence don't work . It work (It doesn't give "Must be a separator on rules line 47 (bu39)." message) only with INSTALL_ROOT = $(DESTDIR) Second and hardest problem is: executing make I get an error. with debug mode the message is: ..... + eval cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/ xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.s o -Wl,-R,/usr/local/lib + cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/xmlwf .o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.so -Wl, -R,/usr/local/lib command line: fatal error: illegal value for -R: /usr/local/lib + exit 1 *** Error code 1 (bu21) > -------------- executing cc in debug mode i get cc: 'ld' '-Ra,XPG4PLUS,elf' '-Y' 'P,/usr/ccs/lib:/lib:/usr/lib' '/usr/ccs/lib/c rt1.o' '/usr/ccs/lib/values-Xa.o' '-o' 'xmlwf/.libs/xmlwf' 'xmlwf/xmlwf.o' 'xmlw f/xmlfile.o' 'xmlwf/codepage.o' 'xmlwf/readfilemap.o' './.libs/libexpat.so' '-R' '/usr/local/lib' '-Qy' '-lcrypt' '-lgen' '-lc' '/usr/ccs/lib/crtn.o' cc: process: /usr/ccs/bin/elf/ld command line: fatal error: illegal value for -R: /usr/local/lib So the problem is the -R parameter passed to ld command that does not allow /usr/local/lib as argument as you can see from these part of ld man --------- ....... -Rarg[,arg,...] Set runtime-behavior characteristics. The option accepts a comma-separated list of arguments. Note that there is no space between -R and its arguments. Each argument is one of the accepted values for the -a, -b, or -X flags of cc(CP), and should match the flags used when the objects were compiled. The default is -Rxpg4plus,elf,a for the ELF ld, and -Rxpg4plus,coff,a for the COFF ld. The ELF ld ignores -Rcoff and -Ribcs2; the COFF ld ignores -Relf. Multiple -R arguments may be given; the last argument of each type ( -a, -b, or -X) is the one used. For example, -Ransi,a -Rxpg4,coff is equivalent to -Rxpg4,coff,a. ........ So, I belive some ld parameter must be changed but what? TIA , I hope you can send me the solution ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 13:33 Message: No follow-up. Assume fix is OK. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-11 13:32 Message: Logged In: YES user_id=290026 Originator: NO The latest Makefile.in patch should make this issue go away (see bug #1490371), as it removes the GNU specific conditional directive. With the other error (ld parameter) I am afraid that as a Windows guy I really cannot help you. Hopefully others will jump in. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-05-05 13:29 Message: Logged In: YES user_id=290026 Originator: NO For part of this issue: In an attempt to make Makefile.in more compatible across platforms I have modified the conditional directive above yet again: ifeq ($(INSTALL_ROOT),) INSTALL_ROOT = $(DESTDIR) endif Let's hope this will be more successful. Applied in Makefile.in rev. 1.57. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-19 13:48 Message: Logged In: YES user_id=290026 Originator: NO When I made the Expat 2.0 tarball I used libtool 1.5.22. Is that new enough? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-19 10:43 Message: Logged In: YES user_id=3066 Originator: NO > All our Unix build experts have been unresponsive for a while. Sadly, that's me. I've never used SCO Unix myself. Whether a new libtool fixes this problem, I don't know. If anyone can verify that, we can see about using an updated libtool. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-12-19 10:30 Message: Logged In: YES user_id=290026 Originator: NO All our Unix build experts have been unresponsive for a while. I am not sure I can really help you there. I can only recommend to search Google for problems with ld on SCO. And, in the spirit of support for OpenSource projects, why don't you ditch SCO in favour of Linux? :-) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-12-19 05:26 Message: Logged In: NO Message from mstabile at metsogeda.it ----------------------------------- Command cc -I./lib -I. -g -belf -DHAVE_EXPAT_CONFIG_H -o xmlwf/.libs/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/readfilemap.o ./.libs/libexpat.so -Wl,-L,/usr/local/lib seems to work and create xmlwf/.libs/xmlwf How libtool should be changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1618673&group_id=10127 From noreply at sourceforge.net Sun Jan 18 16:54:51 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 15:54:51 +0000 Subject: [Expat-bugs] [ expat-Bugs-2412451 ] may be undefined behaver on integer overflow Message-ID: Bugs item #2412451, was opened at 2008-12-09 15:38 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2412451&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 Private: No Submitted By: NikeL (gelenberg) Assigned to: Nobody/Anonymous (nobody) Summary: may be undefined behaver on integer overflow Initial Comment: Hi, I think in lib/xmlparse.c Revision 1.162 on line 2572 my occur integer overflow on x86_64 platform, cause int < sizeof(void*). There should be used size_t, i think. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 10:54 Message: In Expat, pointer differences are basically always cast to int. It is extremely unlikely that this would cause an overflow, as Expat breaks the input buffer into chunks according to boundaries it recognizes, like line-breaks, entity references, tag delimiters, etc. Also, the input functions allow only int for specifying text lengths. Technically, it might be possible to construct some input that might cause an overflow, like an element name that is 2^33 characters long. Not sure if it makes sense to do anything about it, as it would probably require us to change all ints to (64bit) longs and maybe also break the interface. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2412451&group_id=10127 From noreply at sourceforge.net Sun Jan 18 21:40:56 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 20:40:56 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517938 ] xmlwf should return non-zero exit status if not well-formed Message-ID: Bugs item #2517938, was opened at 2009-01-18 21:40 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=2517938&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf should return non-zero exit status if not well-formed Initial Comment: In Debian bug #82763 a user requested to stop at the first not well-formed document with a non-zero exit status. The patch is attached. We apply it for Debian atm. [1] http://bugs.debian.org/82763 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517938&group_id=10127 From noreply at sourceforge.net Sun Jan 18 21:46:20 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 20:46:20 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517946 ] Wrong statement about XMLDecl in xmlwf.1 and xmlwf.sgml Message-ID: Bugs item #2517946, was opened at 2009-01-18 21:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517946&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong statement about XMLDecl in xmlwf.1 and xmlwf.sgml Initial Comment: The manual page (and its source xmlwf.sgml) state in the BUGS section, that an XML document without an XML declaration is not considered well-formed. This is wrong. See http://www.w3.org/TR/2006/REC-xml-20060816/#NT-prolog The attached patch should fix this. Please don't forget to recreate the manual page xmlwf.1 as the patch only applies to its source. This has been reported as Debian bug #412786: http://bugs.debian.org/412786 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517946&group_id=10127 From noreply at sourceforge.net Sun Jan 18 21:51:43 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 20:51:43 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517952 ] expat.m4: underquoted definition of AM_WITH_EXPAT Message-ID: Bugs item #2517952, was opened at 2009-01-18 21:51 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=2517952&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: expat.m4: underquoted definition of AM_WITH_EXPAT Initial Comment: aclocal (>= 1.8) will print the following warning about expat.m4: /usr/share/aclocal/expat.m4:10: warning: underquoted definition of AM_WITH_EXPAT /usr/share/aclocal/expat.m4:10: run info '(automake)Extending aclocal' /usr/share/aclocal/expat.m4:10: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal The issue can be easily fixed with the attached patch. It has been reported as Debian bug #485129. http://bugs.debian.org/485129 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517952&group_id=10127 From noreply at sourceforge.net Sun Jan 18 21:54:52 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 20:54:52 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517962 ] Please update libtool scripts to support GNU/k*BSD Message-ID: Bugs item #2517962, was opened at 2009-01-18 21:54 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=2517962&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: Please update libtool scripts to support GNU/k*BSD Initial Comment: In the Debian bug report #342684 [1] it has been pointed out, that expat 2.0.1 shipped too old libtool scripts to support GNU/k*BSD. Please update them with the next release. [1] http://bugs.debian.org/342684 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 From noreply at sourceforge.net Sun Jan 18 22:38:52 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 21:38:52 +0000 Subject: [Expat-bugs] [ expat-Bugs-2518079 ] incorrect pointer adjustments on buffer reallocation Message-ID: Bugs item #2518079, was opened at 2009-01-18 22:38 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=2518079&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect pointer adjustments on buffer reallocation Initial Comment: This bug has been reported as Debian bug #245840: http://bugs.debian.org/245840 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=245840 Some developers thought, that this might be exploitable. I did not yet have the time to take a look at it. Please check yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2518079&group_id=10127 From noreply at sourceforge.net Sun Jan 18 22:39:05 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 21:39:05 +0000 Subject: [Expat-bugs] [ expat-Bugs-2518079 ] incorrect pointer adjustments on buffer reallocation Message-ID: Bugs item #2518079, was opened at 2009-01-18 22:38 Message generated for change (Settings changed) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2518079&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: 7 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect pointer adjustments on buffer reallocation Initial Comment: This bug has been reported as Debian bug #245840: http://bugs.debian.org/245840 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=245840 Some developers thought, that this might be exploitable. I did not yet have the time to take a look at it. Please check yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2518079&group_id=10127 From noreply at sourceforge.net Sun Jan 18 22:41:30 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 21:41:30 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517952 ] expat.m4: underquoted definition of AM_WITH_EXPAT Message-ID: Bugs item #2517952, was opened at 2009-01-18 15:51 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517952&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 Private: No Submitted By: Daniel Leidert (dleidert) >Assigned to: Karl Waclawek (kwaclaw) Summary: expat.m4: underquoted definition of AM_WITH_EXPAT Initial Comment: aclocal (>= 1.8) will print the following warning about expat.m4: /usr/share/aclocal/expat.m4:10: warning: underquoted definition of AM_WITH_EXPAT /usr/share/aclocal/expat.m4:10: run info '(automake)Extending aclocal' /usr/share/aclocal/expat.m4:10: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal The issue can be easily fixed with the attached patch. It has been reported as Debian bug #485129. http://bugs.debian.org/485129 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 16:41 Message: Patch applied in expat.m4 rev. 1.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517952&group_id=10127 From noreply at sourceforge.net Sun Jan 18 22:55:35 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 21:55:35 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517946 ] Wrong statement about XMLDecl in xmlwf.1 and xmlwf.sgml Message-ID: Bugs item #2517946, was opened at 2009-01-18 15:46 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517946&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 Private: No Submitted By: Daniel Leidert (dleidert) >Assigned to: Karl Waclawek (kwaclaw) Summary: Wrong statement about XMLDecl in xmlwf.1 and xmlwf.sgml Initial Comment: The manual page (and its source xmlwf.sgml) state in the BUGS section, that an XML document without an XML declaration is not considered well-formed. This is wrong. See http://www.w3.org/TR/2006/REC-xml-20060816/#NT-prolog The attached patch should fix this. Please don't forget to recreate the manual page xmlwf.1 as the patch only applies to its source. This has been reported as Debian bug #412786: http://bugs.debian.org/412786 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 16:55 Message: Patch applied in xmlwf.sgml rev. 1.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517946&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:21:08 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:21:08 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517962 ] Please update libtool scripts to support GNU/k*BSD Message-ID: Bugs item #2517962, was opened at 2009-01-18 21:54 Message generated for change (Comment added) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: Please update libtool scripts to support GNU/k*BSD Initial Comment: In the Debian bug report #342684 [1] it has been pointed out, that expat 2.0.1 shipped too old libtool scripts to support GNU/k*BSD. Please update them with the next release. [1] http://bugs.debian.org/342684 ---------------------------------------------------------------------- >Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 23:21 Message: This could be a duplicate of item 1983953. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:24:52 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:24:52 +0000 Subject: [Expat-bugs] [ expat-Bugs-1983953 ] outdated config.sub/config.guess Message-ID: Bugs item #1983953, was opened at 2008-06-03 18:39 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&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: Accepted Priority: 5 Private: No Submitted By: Scott McCreary (scottmc) Assigned to: Sebastian Pipping (hartwork) Summary: outdated config.sub/config.guess Initial Comment: Seems to be time to update config.sub and config.guess again. Haiku for one needs this to be updated: http://tools.assembla.com/BePorts/wiki/dev-libs/expat ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 17:24 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:31 Message: Sorry for forgetting about this one - way too busy in the last 6 months. OK, Sebastian, go ahead. To be honest, I have to trust you on this one, I have never been a build expert on Linux. Karl ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 11:57 Message: Logged In: YES user_id=1022691 Originator: NO [2/2] This patch would be needed for Haiku on top of the former. Extracted from the source given by Scott. Do I have green for both? File Added: expat_cvs_head_1983953_2_satisfy_haiku.patch ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 11:54 Message: Logged In: YES user_id=1022691 Originator: NO [1/2] Here's the patch to update our CVS head to config.{guess,sub} of libTool 1.5.26. File Added: expat_cvs_head_1983953_1_update_libtool_1_5_26.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:28:24 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:28:24 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517962 ] Please update libtool scripts to support GNU/k*BSD Message-ID: Bugs item #2517962, was opened at 2009-01-18 15:54 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: Please update libtool scripts to support GNU/k*BSD Initial Comment: In the Debian bug report #342684 [1] it has been pointed out, that expat 2.0.1 shipped too old libtool scripts to support GNU/k*BSD. Please update them with the next release. [1] http://bugs.debian.org/342684 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 17:28 Message: According to the Debian bug report, it might be sufficient to update only config.sub and config.guess. If libtool needs to be updated as well (currently at 1.5.22), it seems there is a big version jump from 1.5.x to 2.2.x necessary if going to the most recent version. Any opinions on that? ---------------------------------------------------------------------- Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 17:21 Message: This could be a duplicate of item 1983953. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:33:39 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:33:39 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517962 ] Please update libtool scripts to support GNU/k*BSD Message-ID: Bugs item #2517962, was opened at 2009-01-18 21:54 Message generated for change (Comment added) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: Please update libtool scripts to support GNU/k*BSD Initial Comment: In the Debian bug report #342684 [1] it has been pointed out, that expat 2.0.1 shipped too old libtool scripts to support GNU/k*BSD. Please update them with the next release. [1] http://bugs.debian.org/342684 ---------------------------------------------------------------------- >Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 23:33 Message: We updated to the latest version of the 1.x release of libtool. The following files have been updated: config.sub, config.guess, conftools/ltmain.sh, conftools/libtool.m4. Then configure has been recreated. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 23:28 Message: According to the Debian bug report, it might be sufficient to update only config.sub and config.guess. If libtool needs to be updated as well (currently at 1.5.22), it seems there is a big version jump from 1.5.x to 2.2.x necessary if going to the most recent version. Any opinions on that? ---------------------------------------------------------------------- Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 23:21 Message: This could be a duplicate of item 1983953. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:44:50 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:44:50 +0000 Subject: [Expat-bugs] [ expat-Bugs-1983953 ] outdated config.sub/config.guess Message-ID: Bugs item #1983953, was opened at 2008-06-03 15:39 Message generated for change (Comment added) made by scottmc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&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: Accepted Priority: 5 Private: No Submitted By: Scott McCreary (scottmc) Assigned to: Sebastian Pipping (hartwork) Summary: outdated config.sub/config.guess Initial Comment: Seems to be time to update config.sub and config.guess again. Haiku for one needs this to be updated: http://tools.assembla.com/BePorts/wiki/dev-libs/expat ---------------------------------------------------------------------- >Comment By: Scott McCreary (scottmc) Date: 2009-01-18 14:44 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD Yes, that would work. Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 14:24 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 08:31 Message: Sorry for forgetting about this one - way too busy in the last 6 months. OK, Sebastian, go ahead. To be honest, I have to trust you on this one, I have never been a build expert on Linux. Karl ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 08:57 Message: Logged In: YES user_id=1022691 Originator: NO [2/2] This patch would be needed for Haiku on top of the former. Extracted from the source given by Scott. Do I have green for both? File Added: expat_cvs_head_1983953_2_satisfy_haiku.patch ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 08:54 Message: Logged In: YES user_id=1022691 Originator: NO [1/2] Here's the patch to update our CVS head to config.{guess,sub} of libTool 1.5.26. File Added: expat_cvs_head_1983953_1_update_libtool_1_5_26.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:47:03 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:47:03 +0000 Subject: [Expat-bugs] [ expat-Bugs-1983953 ] outdated config.sub/config.guess Message-ID: Bugs item #1983953, was opened at 2008-06-04 00:39 Message generated for change (Comment added) made by hartwork You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&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: Accepted Priority: 5 Private: No Submitted By: Scott McCreary (scottmc) Assigned to: Sebastian Pipping (hartwork) Summary: outdated config.sub/config.guess Initial Comment: Seems to be time to update config.sub and config.guess again. Haiku for one needs this to be updated: http://tools.assembla.com/BePorts/wiki/dev-libs/expat ---------------------------------------------------------------------- >Comment By: Sebastian Pipping (hartwork) Date: 2009-01-18 23:47 Message: Karl, yes, please go ahead. A future approach should grab the latest config.{guess,sub} files from GNUlib at packaging/release time. That's where the autogen.sh/buildconf project is heading to. ---------------------------------------------------------------------- Comment By: Scott McCreary (scottmc) Date: 2009-01-18 23:44 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD Yes, that would work. Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 23:24 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 17:31 Message: Sorry for forgetting about this one - way too busy in the last 6 months. OK, Sebastian, go ahead. To be honest, I have to trust you on this one, I have never been a build expert on Linux. Karl ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 17:57 Message: Logged In: YES user_id=1022691 Originator: NO [2/2] This patch would be needed for Haiku on top of the former. Extracted from the source given by Scott. Do I have green for both? File Added: expat_cvs_head_1983953_2_satisfy_haiku.patch ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 17:54 Message: Logged In: YES user_id=1022691 Originator: NO [1/2] Here's the patch to update our CVS head to config.{guess,sub} of libTool 1.5.26. File Added: expat_cvs_head_1983953_1_update_libtool_1_5_26.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&group_id=10127 From noreply at sourceforge.net Sun Jan 18 23:49:30 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 22:49:30 +0000 Subject: [Expat-bugs] [ expat-Bugs-2518079 ] incorrect pointer adjustments on buffer reallocation Message-ID: Bugs item #2518079, was opened at 2009-01-18 16:38 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2518079&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: Out of Date Priority: 7 Private: No Submitted By: Daniel Leidert (dleidert) >Assigned to: Karl Waclawek (kwaclaw) Summary: incorrect pointer adjustments on buffer reallocation Initial Comment: This bug has been reported as Debian bug #245840: http://bugs.debian.org/245840 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=245840 Some developers thought, that this might be exploitable. I did not yet have the time to take a look at it. Please check yourself. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 17:49 Message: This is quite an old report, and the code mentioned has changed since then. It also seems it does not apply anymore - see http://bugs.python.org/issue883495. I am inclined to close this issue, unless given a good reason to revive it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2518079&group_id=10127 From noreply at sourceforge.net Mon Jan 19 00:00:23 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 23:00:23 +0000 Subject: [Expat-bugs] [ expat-Bugs-1983953 ] outdated config.sub/config.guess Message-ID: Bugs item #1983953, was opened at 2008-06-03 18:39 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&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 Private: No Submitted By: Scott McCreary (scottmc) Assigned to: Sebastian Pipping (hartwork) Summary: outdated config.sub/config.guess Initial Comment: Seems to be time to update config.sub and config.guess again. Haiku for one needs this to be updated: http://tools.assembla.com/BePorts/wiki/dev-libs/expat ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2009-01-18 17:47 Message: Karl, yes, please go ahead. A future approach should grab the latest config.{guess,sub} files from GNUlib at packaging/release time. That's where the autogen.sh/buildconf project is heading to. ---------------------------------------------------------------------- Comment By: Scott McCreary (scottmc) Date: 2009-01-18 17:44 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD Yes, that would work. Thanks. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 17:24 Message: Would it be OK if I simply update to the most recent versions available from: http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-17 11:31 Message: Sorry for forgetting about this one - way too busy in the last 6 months. OK, Sebastian, go ahead. To be honest, I have to trust you on this one, I have never been a build expert on Linux. Karl ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 11:57 Message: Logged In: YES user_id=1022691 Originator: NO [2/2] This patch would be needed for Haiku on top of the former. Extracted from the source given by Scott. Do I have green for both? File Added: expat_cvs_head_1983953_2_satisfy_haiku.patch ---------------------------------------------------------------------- Comment By: Sebastian Pipping (hartwork) Date: 2008-08-03 11:54 Message: Logged In: YES user_id=1022691 Originator: NO [1/2] Here's the patch to update our CVS head to config.{guess,sub} of libTool 1.5.26. File Added: expat_cvs_head_1983953_1_update_libtool_1_5_26.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1983953&group_id=10127 From noreply at sourceforge.net Mon Jan 19 00:55:04 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jan 2009 23:55:04 +0000 Subject: [Expat-bugs] [ expat-Bugs-1796740 ] wrong bug description (and fix) for #1690883 Message-ID: Bugs item #1796740, was opened at 2007-09-17 19:52 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1796740&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: Documentation >Group: Not a Bug >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: flow67 (flow67) Assigned to: Karl Waclawek (kwaclaw) Summary: wrong bug description (and fix) for #1690883 Initial Comment: Changes file for release 2.0.1 incorrectly reports - Fixed bug #1690883: Expat failed on EBCDIC systems as it assumed some character constants to be ASCII encoded. Unfortunately bug 1690883 is not related to EBCDIC encoding (as we've just found out on our z/OS system) but , according to the bug database , [ 1690883 ] Expat rejects xml: prefix with "unbound prefix" error 2.0.1 is still not working on EBCDIC systems (initial Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 18:55 Message: I did not notice at first that your issue is actually with Expat not parsing documents encoded in EBCDIC. The original issue was with Expat not properly building on EBCDIC systems, and this was fixed. Parsing EBCDIC encoded documents has never been a goal for Expat, as it is not required by the standard. However, we have a standalone patch (#987903) which you might be able to adapt to your needs. Closing this issue. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-09-18 09:46 Message: Logged In: YES user_id=290026 Originator: NO The original fix was contributed by Scott Klement, and it certainly was a valid fix for Expat, even if it doesn't fix your issue. However if fixed the issue for Scott. Since we don't have access to an EBCDIC platform, we cannot really address this issue from our side, we will have to rely on contributors like Scott. Would yu please contact him (just click on the link by his name on the original bug report) and maybe you two could figure it out together. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1796740&group_id=10127 From noreply at sourceforge.net Mon Jan 19 01:07:17 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 00:07:17 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517962 ] Please update libtool scripts to support GNU/k*BSD Message-ID: Bugs item #2517962, was opened at 2009-01-18 15:54 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&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 Private: No Submitted By: Daniel Leidert (dleidert) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Please update libtool scripts to support GNU/k*BSD Initial Comment: In the Debian bug report #342684 [1] it has been pointed out, that expat 2.0.1 shipped too old libtool scripts to support GNU/k*BSD. Please update them with the next release. [1] http://bugs.debian.org/342684 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 19:07 Message: I have already updated config.sub/guess to the most recent available version. I suggest we then use ltmain.sh and libtool.m4 from libtool 1.5.26 for the next Expat release. ---------------------------------------------------------------------- Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 17:33 Message: We updated to the latest version of the 1.x release of libtool. The following files have been updated: config.sub, config.guess, conftools/ltmain.sh, conftools/libtool.m4. Then configure has been recreated. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 17:28 Message: According to the Debian bug report, it might be sufficient to update only config.sub and config.guess. If libtool needs to be updated as well (currently at 1.5.22), it seems there is a big version jump from 1.5.x to 2.2.x necessary if going to the most recent version. Any opinions on that? ---------------------------------------------------------------------- Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 17:21 Message: This could be a duplicate of item 1983953. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517962&group_id=10127 From noreply at sourceforge.net Mon Jan 19 01:20:19 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 00:20:19 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517938 ] xmlwf should return non-zero exit status if not well-formed Message-ID: Bugs item #2517938, was opened at 2009-01-18 15:40 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517938&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) >Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwf should return non-zero exit status if not well-formed Initial Comment: In Debian bug #82763 a user requested to stop at the first not well-formed document with a non-zero exit status. The patch is attached. We apply it for Debian atm. [1] http://bugs.debian.org/82763 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 19:20 Message: It seems this is indeed a bug. In other error cases (out of memory, file open error), xmlwf returns 1. When incorrect parameters are passed, it returns 2. The Debian patch returns 2 for a parse error. This seems to be in line with existing usage, where 1 indicates an exception (execution error), and 2 indicates an actual execution result. So I applied the patch - see xmlwf.c rev. 1.75. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517938&group_id=10127 From noreply at sourceforge.net Mon Jan 19 01:20:49 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 00:20:49 +0000 Subject: [Expat-bugs] [ expat-Bugs-2517938 ] xmlwf should return non-zero exit status if not well-formed Message-ID: Bugs item #2517938, was opened at 2009-01-18 15:40 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517938&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 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Karl Waclawek (kwaclaw) Summary: xmlwf should return non-zero exit status if not well-formed Initial Comment: In Debian bug #82763 a user requested to stop at the first not well-formed document with a non-zero exit status. The patch is attached. We apply it for Debian atm. [1] http://bugs.debian.org/82763 ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 19:20 Message: It seems this is indeed a bug. In other error cases (out of memory, file open error), xmlwf returns 1. When incorrect parameters are passed, it returns 2. The Debian patch returns 2 for a parse error. This seems to be in line with existing usage, where 1 indicates an exception (execution error), and 2 indicates an actual execution result. So I applied the patch - see xmlwf.c rev. 1.75. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2517938&group_id=10127 From noreply at sourceforge.net Mon Jan 19 02:15:44 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 01:15:44 +0000 Subject: [Expat-bugs] [ expat-Patches-1983369 ] Sometimes expat_config.h seems to be required Message-ID: Patches item #1983369, was opened at 2008-06-03 13:05 Message generated for change (Comment added) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1983369&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: Duplicate Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: Sometimes expat_config.h seems to be required Initial Comment: A Debian user requested, that expat_config.h is installed along with the other header files. It looks like, some software packages rely on this header file. I'm not sure, if it's a bug in the packages relying on this header or if it's a valid user request. I'm therefor simply forwarding this request to you. The Debian package ships the header for 3 years now and it seems to have no disadvantages. The patch is attached. ---------------------------------------------------------------------- >Comment By: Daniel Leidert (dleidert) Date: 2009-01-19 02:15 Message: This has now been reported to the bugs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1983369&group_id=10127 From noreply at sourceforge.net Mon Jan 19 02:15:58 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 01:15:58 +0000 Subject: [Expat-bugs] [ expat-Patches-1983364 ] xmlwf manpage wrong about XML standard and well-formdness Message-ID: Patches item #1983364, was opened at 2008-06-03 12:59 Message generated for change (Comment added) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1983364&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: Duplicate Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf manpage wrong about XML standard and well-formdness Initial Comment: In http://bugs.debian.org/412786 a user reported an content bug in the xmlwf manpage. There it is written, that the XML standard requires an XML declaration at the beginning to be the well-formed. However this is IMO wrong. The XML declaration is AFAIK optional. The attached patch fixes this for the SGML source. It further makes a small fix to not output a point at the beginning of a line in the GROFF file - some tools do not escape the dot here with \& - so removing the line-break will avoid issues with other tools) ---------------------------------------------------------------------- >Comment By: Daniel Leidert (dleidert) Date: 2009-01-19 02:15 Message: This has now been reported to the bugs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1983364&group_id=10127 From noreply at sourceforge.net Mon Jan 19 02:16:12 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 01:16:12 +0000 Subject: [Expat-bugs] [ expat-Patches-1983348 ] xmlwf should return with a non-zero value on error Message-ID: Patches item #1983348, was opened at 2008-06-03 12:48 Message generated for change (Comment added) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1983348&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: Duplicate Priority: 5 Private: No Submitted By: Daniel Leidert (dleidert) Assigned to: Nobody/Anonymous (nobody) Summary: xmlwf should return with a non-zero value on error Initial Comment: In http://bugs.debian.org/82763 it has been requested, that xmlwf returns with a non-zero exit value if there is an issue (e.g. non-wellformed XML). The attached patch, applied for around 7 years to the Debian package, would fulfill the request. ---------------------------------------------------------------------- >Comment By: Daniel Leidert (dleidert) Date: 2009-01-19 02:16 Message: This has now been reported to the bugs tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1983348&group_id=10127 From noreply at sourceforge.net Mon Jan 19 02:18:19 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 01:18:19 +0000 Subject: [Expat-bugs] [ expat-Patches-1749198 ] Add pkg-config file Message-ID: Patches item #1749198, was opened at 2007-07-06 17:41 Message generated for change (Comment added) made by dleidert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1749198&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: Accepted Priority: 5 Private: No Submitted By: Dan Nicholson (dbnichol) Assigned to: Karl Waclawek (kwaclaw) Summary: Add pkg-config file Initial Comment: Patch provides a pkg-config support for easy linking with libexpat. ---------------------------------------------------------------------- Comment By: Daniel Leidert (dleidert) Date: 2009-01-19 02:18 Message: You can add this field too, if you want: URL: http://expat.sourceforge.net ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-09-03 19:27 Message: Logged In: YES user_id=290026 Originator: NO Patch committed on Sep. 3, 2007. Needs testing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1749198&group_id=10127 From noreply at sourceforge.net Mon Jan 19 04:36:25 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 03:36:25 +0000 Subject: [Expat-bugs] [ expat-Patches-1749198 ] Add pkg-config file Message-ID: Patches item #1749198, was opened at 2007-07-06 11:41 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1749198&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: Accepted Priority: 5 Private: No Submitted By: Dan Nicholson (dbnichol) Assigned to: Karl Waclawek (kwaclaw) Summary: Add pkg-config file Initial Comment: Patch provides a pkg-config support for easy linking with libexpat. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-18 22:36 Message: Done - but with http://www.libexpat.org. ---------------------------------------------------------------------- Comment By: Daniel Leidert (dleidert) Date: 2009-01-18 20:18 Message: You can add this field too, if you want: URL: http://expat.sourceforge.net ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2007-09-03 13:27 Message: Logged In: YES user_id=290026 Originator: NO Patch committed on Sep. 3, 2007. Needs testing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=310127&aid=1749198&group_id=10127 From noreply at sourceforge.net Mon Jan 19 13:30:33 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 12:30:33 +0000 Subject: [Expat-bugs] [ expat-Bugs-2519651 ] trailing comma in XML_Status enum Message-ID: Bugs item #2519651, was opened at 2009-01-19 12:30 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=2519651&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joe Orton (jorton) Assigned to: Greg Stein (gstein) Summary: trailing comma in XML_Status enum Initial Comment: The trailing comma in the XML_Status enum will: a) cause warnings if an app builds with gcc -pedantic b) break the build with some older Unix compilers (Tru64, IIRC) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2519651&group_id=10127 From noreply at sourceforge.net Mon Jan 19 18:10:30 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jan 2009 17:10:30 +0000 Subject: [Expat-bugs] [ expat-Bugs-2519651 ] trailing comma in XML_Status enum Message-ID: Bugs item #2519651, was opened at 2009-01-19 07:30 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2519651&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: Not a Bug >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Joe Orton (jorton) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: trailing comma in XML_Status enum Initial Comment: The trailing comma in the XML_Status enum will: a) cause warnings if an app builds with gcc -pedantic b) break the build with some older Unix compilers (Tru64, IIRC) ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2009-01-19 12:10 Message: This was fixed a long time ago: in expat.h, revision 1.72, Fri Sep 24 13:06:29 2004 UTC. Closing the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=2519651&group_id=10127