From noreply at sourceforge.net Wed Oct 4 18:54:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Oct 2006 09:54:09 -0700 Subject: [Expat-bugs] [ expat-Bugs-1490371 ] additional config for INSTALL_ROOT Message-ID: Bugs item #1490371, was opened at 2006-05-17 09:36 Message generated for change (Comment added) made by nobody 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: None Status: Open Resolution: None Priority: 5 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: Nobody/Anonymous (nobody) Date: 2006-10-04 09: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 12: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 11: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 14: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 13: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 10: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 chikara_taura at digion.com Fri Oct 6 06:42:03 2006 From: chikara_taura at digion.com (Chikara Taura) Date: Fri, 6 Oct 2006 13:42:03 +0900 Subject: [Expat-bugs] parse error including some specific characters of UTF-8 Message-ID: <006b01c6e901$c53790b0$570a030a@digion.com> I am using the Expat-2.0.0 lib. When xml includes some specific characters of UTF-8, expat fails to parse it. I've attached a sample program to reproduce this problem. Any help would be appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_xml_parse.zip Type: application/octet-stream Size: 548 bytes Desc: not available Url : http://mail.libexpat.org/pipermail/expat-bugs/attachments/20061006/02043664/attachment.obj From karl at waclawek.net Fri Oct 6 19:40:55 2006 From: karl at waclawek.net (Karl Waclawek) Date: Fri, 06 Oct 2006 13:40:55 -0400 Subject: [Expat-bugs] parse error including some specific characters of UTF-8 In-Reply-To: <006b01c6e901$c53790b0$570a030a@digion.com> References: <006b01c6e901$c53790b0$570a030a@digion.com> Message-ID: <45269527.7060708@waclawek.net> Chikara Taura wrote: > I am using the Expat-2.0.0 lib. When xml includes some specific > characters of UTF-8, expat fails to parse it. I've attached a sample > program to reproduce this problem. > > Any help would be appreciated. It seems that Unicode character 05 is not a valid XML character - see http://www.w3.org/TR/xml/#charsets. Karl From chikara_taura at digion.com Wed Oct 11 13:00:08 2006 From: chikara_taura at digion.com (Chikara Taura) Date: Wed, 11 Oct 2006 20:00:08 +0900 Subject: [Expat-bugs] parse error including some specific characters of UTF-8 References: <006b01c6e901$c53790b0$570a030a@digion.com> <45269527.7060708@waclawek.net> Message-ID: <015d01c6ed24$6a707bc0$570a030a@digion.com> Thank you for the response. Worked fine for me. ----- Original Message ----- From: "Karl Waclawek" To: "Chikara Taura" Cc: Sent: Saturday, October 07, 2006 2:40 AM Subject: Re: [Expat-bugs] parse error including some specific characters of UTF-8 > Chikara Taura wrote: >> I am using the Expat-2.0.0 lib. When xml includes some specific >> characters of UTF-8, expat fails to parse it. I've attached a sample >> program to reproduce this problem. >> >> Any help would be appreciated. > It seems that Unicode character 05 is not a valid XML character - see > http://www.w3.org/TR/xml/#charsets. > > Karl > From noreply at sourceforge.net Wed Oct 11 20:11:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Oct 2006 11:11:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-1513208 ] memory leak Message-ID: Bugs item #1513208, was opened at 2006-06-27 09:21 Message generated for change (Comment added) made by stratalight You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak Initial Comment: version: 1.95.8 two bufferes, one is "GL-002- 0012", another is "GL- 002-0012", the latter leak 80 bytes every time. the difference of both bufferes is whether the PROLOG exists. the tested function: XML_Parse. ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 18:11 Message: Logged In: YES user_id=1618736 I am using scew on top of expat and valgrind also reports a leak ==23265== 112 (20 direct, 92 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 7 ==23265== at 0x4018B0F: calloc (m_replacemalloc/vg_replace_malloc.c:279) ==23265== by 0x80499A7: scew_tree_create (in /home/tracy/test/x) ==23265== by 0x8049041: xmldecl_handler (in /home/tracy/test/x) ==23265== by 0x40E5BC4: processXmlDecl (lib/xmlparse.c:3349) ==23265== by 0x40E62FC: doProlog (lib/xmlparse.c:3713) ==23265== by 0x40E623D: prologProcessor (lib/xmlparse.c:3616) ==23265== by 0x40E33B8: XML_ParseBuffer (lib/xmlparse.c:1567) ==23265== by 0x40E3328: XML_Parse (lib/xmlparse.c:1538) ==23265== by 0x8048F58: scew_parser_load_buffer (in /home/tracy/test/x) ==23265== by 0x8048C3A: main (x.cpp:16) the code looks like this int main(int argc, char *argv[]) { char * data = { "xx"}; scew_parser* parser = scew_parser_create(); if (!parser) { return -1; } scew_parser_ignore_whitespaces(parser, 1); if (scew_parser_load_buffer(parser, data, strlen(data))){ std::cout << "OK\n"; } else { std::cout << "Bad\n"; } scew_parser_free(parser); } under the covers scew_parser does a XML_ParserCreate and scew_parser_free does an XML_ParserFree. scew_load_buffer does a XML_Parse. I found that there was no difference between adding a prolog and not - 20 bytes were always lost. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 13:18 Message: Logged In: YES user_id=290026 Have you tested with CVS version? How are you determining the leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 From noreply at sourceforge.net Wed Oct 11 20:11:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Oct 2006 11:11:43 -0700 Subject: [Expat-bugs] [ expat-Bugs-1513208 ] memory leak Message-ID: Bugs item #1513208, was opened at 2006-06-27 09:21 Message generated for change (Comment added) made by stratalight You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak Initial Comment: version: 1.95.8 two bufferes, one is "GL-002- 0012", another is "GL- 002-0012", the latter leak 80 bytes every time. the difference of both bufferes is whether the PROLOG exists. the tested function: XML_Parse. ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 18:11 Message: Logged In: YES user_id=1618736 also - i was using expat 2.0 with scew 0.4.0 ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 18:11 Message: Logged In: YES user_id=1618736 I am using scew on top of expat and valgrind also reports a leak ==23265== 112 (20 direct, 92 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 7 ==23265== at 0x4018B0F: calloc (m_replacemalloc/vg_replace_malloc.c:279) ==23265== by 0x80499A7: scew_tree_create (in /home/tracy/test/x) ==23265== by 0x8049041: xmldecl_handler (in /home/tracy/test/x) ==23265== by 0x40E5BC4: processXmlDecl (lib/xmlparse.c:3349) ==23265== by 0x40E62FC: doProlog (lib/xmlparse.c:3713) ==23265== by 0x40E623D: prologProcessor (lib/xmlparse.c:3616) ==23265== by 0x40E33B8: XML_ParseBuffer (lib/xmlparse.c:1567) ==23265== by 0x40E3328: XML_Parse (lib/xmlparse.c:1538) ==23265== by 0x8048F58: scew_parser_load_buffer (in /home/tracy/test/x) ==23265== by 0x8048C3A: main (x.cpp:16) the code looks like this int main(int argc, char *argv[]) { char * data = { "xx"}; scew_parser* parser = scew_parser_create(); if (!parser) { return -1; } scew_parser_ignore_whitespaces(parser, 1); if (scew_parser_load_buffer(parser, data, strlen(data))){ std::cout << "OK\n"; } else { std::cout << "Bad\n"; } scew_parser_free(parser); } under the covers scew_parser does a XML_ParserCreate and scew_parser_free does an XML_ParserFree. scew_load_buffer does a XML_Parse. I found that there was no difference between adding a prolog and not - 20 bytes were always lost. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 13:18 Message: Logged In: YES user_id=290026 Have you tested with CVS version? How are you determining the leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 From noreply at sourceforge.net Wed Oct 11 20:25:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Oct 2006 11:25:04 -0700 Subject: [Expat-bugs] [ expat-Bugs-1513208 ] memory leak Message-ID: Bugs item #1513208, was opened at 2006-06-27 05:21 Message generated for change (Settings changed) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory leak Initial Comment: version: 1.95.8 two bufferes, one is "GL-002- 0012", another is "GL- 002-0012", the latter leak 80 bytes every time. the difference of both bufferes is whether the PROLOG exists. the tested function: XML_Parse. ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 14:11 Message: Logged In: YES user_id=1618736 also - i was using expat 2.0 with scew 0.4.0 ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 14:11 Message: Logged In: YES user_id=1618736 I am using scew on top of expat and valgrind also reports a leak ==23265== 112 (20 direct, 92 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 7 ==23265== at 0x4018B0F: calloc (m_replacemalloc/vg_replace_malloc.c:279) ==23265== by 0x80499A7: scew_tree_create (in /home/tracy/test/x) ==23265== by 0x8049041: xmldecl_handler (in /home/tracy/test/x) ==23265== by 0x40E5BC4: processXmlDecl (lib/xmlparse.c:3349) ==23265== by 0x40E62FC: doProlog (lib/xmlparse.c:3713) ==23265== by 0x40E623D: prologProcessor (lib/xmlparse.c:3616) ==23265== by 0x40E33B8: XML_ParseBuffer (lib/xmlparse.c:1567) ==23265== by 0x40E3328: XML_Parse (lib/xmlparse.c:1538) ==23265== by 0x8048F58: scew_parser_load_buffer (in /home/tracy/test/x) ==23265== by 0x8048C3A: main (x.cpp:16) the code looks like this int main(int argc, char *argv[]) { char * data = { "xx"}; scew_parser* parser = scew_parser_create(); if (!parser) { return -1; } scew_parser_ignore_whitespaces(parser, 1); if (scew_parser_load_buffer(parser, data, strlen(data))){ std::cout << "OK\n"; } else { std::cout << "Bad\n"; } scew_parser_free(parser); } under the covers scew_parser does a XML_ParserCreate and scew_parser_free does an XML_ParserFree. scew_load_buffer does a XML_Parse. I found that there was no difference between adding a prolog and not - 20 bytes were always lost. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 09:18 Message: Logged In: YES user_id=290026 Have you tested with CVS version? How are you determining the leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 From noreply at sourceforge.net Wed Oct 11 22:17:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Oct 2006 13:17:58 -0700 Subject: [Expat-bugs] [ expat-Bugs-1513208 ] memory leak Message-ID: Bugs item #1513208, was opened at 2006-06-27 09:21 Message generated for change (Comment added) made by stratalight You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory leak Initial Comment: version: 1.95.8 two bufferes, one is "GL-002- 0012", another is "GL- 002-0012", the latter leak 80 bytes every time. the difference of both bufferes is whether the PROLOG exists. the tested function: XML_Parse. ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 20:17 Message: Logged In: YES user_id=1618736 I think that the issue was with scew, not expat. The tree was not being deleted. ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 18:11 Message: Logged In: YES user_id=1618736 also - i was using expat 2.0 with scew 0.4.0 ---------------------------------------------------------------------- Comment By: tracy (stratalight) Date: 2006-10-11 18:11 Message: Logged In: YES user_id=1618736 I am using scew on top of expat and valgrind also reports a leak ==23265== 112 (20 direct, 92 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 7 ==23265== at 0x4018B0F: calloc (m_replacemalloc/vg_replace_malloc.c:279) ==23265== by 0x80499A7: scew_tree_create (in /home/tracy/test/x) ==23265== by 0x8049041: xmldecl_handler (in /home/tracy/test/x) ==23265== by 0x40E5BC4: processXmlDecl (lib/xmlparse.c:3349) ==23265== by 0x40E62FC: doProlog (lib/xmlparse.c:3713) ==23265== by 0x40E623D: prologProcessor (lib/xmlparse.c:3616) ==23265== by 0x40E33B8: XML_ParseBuffer (lib/xmlparse.c:1567) ==23265== by 0x40E3328: XML_Parse (lib/xmlparse.c:1538) ==23265== by 0x8048F58: scew_parser_load_buffer (in /home/tracy/test/x) ==23265== by 0x8048C3A: main (x.cpp:16) the code looks like this int main(int argc, char *argv[]) { char * data = { "xx"}; scew_parser* parser = scew_parser_create(); if (!parser) { return -1; } scew_parser_ignore_whitespaces(parser, 1); if (scew_parser_load_buffer(parser, data, strlen(data))){ std::cout << "OK\n"; } else { std::cout << "Bad\n"; } scew_parser_free(parser); } under the covers scew_parser does a XML_ParserCreate and scew_parser_free does an XML_ParserFree. scew_load_buffer does a XML_Parse. I found that there was no difference between adding a prolog and not - 20 bytes were always lost. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-07-05 13:18 Message: Logged In: YES user_id=290026 Have you tested with CVS version? How are you determining the leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1513208&group_id=10127 From wendy.osborn at uleth.ca Thu Oct 19 16:10:58 2006 From: wendy.osborn at uleth.ca (Wendy Osborn) Date: Thu, 19 Oct 2006 08:10:58 -0600 (MDT) Subject: [Expat-bugs] Expat 2.0.0 link failure on FC5 Message-ID: <49224.137.186.156.39.1161267058.squirrel@webmail.uleth.ca> Hello, I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 From karl at waclawek.net Thu Oct 19 16:45:59 2006 From: karl at waclawek.net (Karl Waclawek) Date: Thu, 19 Oct 2006 10:45:59 -0400 Subject: [Expat-bugs] Expat 2.0.0 link failure on FC5 In-Reply-To: <49224.137.186.156.39.1161267058.squirrel@webmail.uleth.ca> References: <49224.137.186.156.39.1161267058.squirrel@webmail.uleth.ca> Message-ID: <45378FA7.2020108@waclawek.net> Wendy Osborn wrote: > Hello, > > I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I > obtained 2.0.0 from CVS to try that) and it fails at the linking stage. > Below is the output from make and configure. Please help. > > Have you tried the CVS version of Expat? It might be fixed there. Karl From wendy.osborn at uleth.ca Thu Oct 19 18:51:27 2006 From: wendy.osborn at uleth.ca (Wendy Osborn) Date: Thu, 19 Oct 2006 10:51:27 -0600 (MDT) Subject: [Expat-bugs] Expat 2.0.0 link failure on FC5 In-Reply-To: <45378FA7.2020108@waclawek.net> References: <49224.137.186.156.39.1161267058.squirrel@webmail.uleth.ca> <45378FA7.2020108@waclawek.net> Message-ID: <35225.142.66.56.237.1161276687.squirrel@webmail.uleth.ca> Hello, Yes, I did obtain version 2.0.0 from CVS. I had tried this too with the source distribution and had the same problem. Thanks, W. On Thu, October 19, 2006 8:45 am, Karl Waclawek wrote: > Wendy Osborn wrote: >> Hello, >> >> I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I >> obtained 2.0.0 from CVS to try that) and it fails at the linking stage. >> Below is the output from make and configure. Please help. >> >> > Have you tried the CVS version of Expat? It might be fixed there. > > Karl > -- "Masquerading as a normal person day after day is exhausting" - Anonymous Wendy Osborn Assistant Professor of Computer Science Research Associate, Southern Alberta Digital Library Department of Mathematics and Computer Science University of Lethbridge, Alberta, Canada phone: +1 403 329 2294 email: osborn at cs.uleth.ca www: http://www.cs.uleth.ca/~osborn From karl at waclawek.net Thu Oct 19 20:57:49 2006 From: karl at waclawek.net (Karl Waclawek) Date: Thu, 19 Oct 2006 14:57:49 -0400 Subject: [Expat-bugs] Expat 2.0.0 link failure on FC5 In-Reply-To: <35225.142.66.56.237.1161276687.squirrel@webmail.uleth.ca> References: <49224.137.186.156.39.1161267058.squirrel@webmail.uleth.ca> <45378FA7.2020108@waclawek.net> <35225.142.66.56.237.1161276687.squirrel@webmail.uleth.ca> Message-ID: <4537CAAD.5090205@waclawek.net> Wendy Osborn wrote: > Hello, > > Yes, I did obtain version 2.0.0 from CVS. I had tried this too with the > source distribution and had the same problem. > > Well, I am not the Linux guy here, I just know that I could build it under Fedora Core 4. Do you have any suggestions for a fix? If not, please submit a bug report. Karl From noreply at sourceforge.net Thu Oct 19 21:17:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 12:17:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 12:17 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=1580748&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Thu Oct 19 22:13:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 13:13:11 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 15:17 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-19 16:13 Message: Logged In: YES user_id=290026 This one seems important to fix before the next release. Greg or Fred, please assist! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Sun Oct 22 19:25:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 10:25:53 -0700 Subject: [Expat-bugs] [ expat-Bugs-224954 ] CPAN archive missing expat.h file or not being built Message-ID: Bugs item #224954, was opened at 2000-12-07 17:52 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=224954&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: Invalid Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Clark Cooper (coopercc) Summary: CPAN archive missing expat.h file or not being built Initial Comment: Upon downloading the currently available CPAN archive for XML::Parser, the module could not be installed using 'make' under RedHat Linux Mandrake 7.0. Running the Makefile.PL complains that Expat is not installed. When moving to the Expat dir and attempting to run the 'Makefile' created by Makefile.PL, the compiler errors on a missing expat.h file. Without installing Expat, XML::Parser cannot be installed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-22 10:25 Message: Logged In: NO The trick that I found was to first install the development version of expat (for me that means apt-get install libexpat1-dev). Once I did this, and did a clean XML::Parser, then make XML::Parser, everything went smoothly. ymmv Joe Bussell ---------------------------------------------------------------------- Comment By: Clark Cooper (coopercc) Date: 2000-12-21 07:24 Message: expat has to be installed for XML::Parser to find expat.h (which comes with the expat (i.e. this) distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=224954&group_id=10127 From noreply at sourceforge.net Wed Oct 25 21:44:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Oct 2006 12:44:24 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 13:17 Message generated for change (Comment added) made by wkosborn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&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: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 13:44 Message: Logged In: YES user_id=1625052 Hi again, I was able to access another machine with Fedora Core 4, so I thought I would try to make expat 2.0.0 on there (CVS distribution). I ran buildconf.sh, then ./configure, then make. I got the same error as above. I was told that Expat did link with no problems under FC4. So maybe i'm doing something wrong? Please let me know . Thanks, Wendy ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-19 14:13 Message: Logged In: YES user_id=290026 This one seems important to fix before the next release. Greg or Fred, please assist! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Wed Oct 25 22:13:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Oct 2006 13:13:30 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 13:17 Message generated for change (Comment added) made by wkosborn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&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: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 14:13 Message: Logged In: YES user_id=1625052 Hi again, I just noticed something that may be causing the problem - although I admit I don't know what to do about it. In the configure output above I noticed this: checking for ranlib... - at true isn't this supposed to be: checking for ranlib... ranlib ? Thanks, Wendy (wkosborn at sourceforge) ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 13:44 Message: Logged In: YES user_id=1625052 Hi again, I was able to access another machine with Fedora Core 4, so I thought I would try to make expat 2.0.0 on there (CVS distribution). I ran buildconf.sh, then ./configure, then make. I got the same error as above. I was told that Expat did link with no problems under FC4. So maybe i'm doing something wrong? Please let me know . Thanks, Wendy ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-19 14:13 Message: Logged In: YES user_id=290026 This one seems important to fix before the next release. Greg or Fred, please assist! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Thu Oct 26 02:00:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Oct 2006 17:00:22 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 15:17 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&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: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-25 20:00 Message: Logged In: YES user_id=290026 I tried again with FC4, no problem. Here is what I am using: - autoconf version 2.59 - libtool version 1.5.16 - gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) and yes, my configure output is: checking for ranlib... ranlib I don't know what ranlib refers to, however. Looks like this should be the focus of attention. ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 16:13 Message: Logged In: YES user_id=1625052 Hi again, I just noticed something that may be causing the problem - although I admit I don't know what to do about it. In the configure output above I noticed this: checking for ranlib... - at true isn't this supposed to be: checking for ranlib... ranlib ? Thanks, Wendy (wkosborn at sourceforge) ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 15:44 Message: Logged In: YES user_id=1625052 Hi again, I was able to access another machine with Fedora Core 4, so I thought I would try to make expat 2.0.0 on there (CVS distribution). I ran buildconf.sh, then ./configure, then make. I got the same error as above. I was told that Expat did link with no problems under FC4. So maybe i'm doing something wrong? Please let me know . Thanks, Wendy ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-19 16:13 Message: Logged In: YES user_id=290026 This one seems important to fix before the next release. Greg or Fred, please assist! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Thu Oct 26 09:08:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 00:08:26 -0700 Subject: [Expat-bugs] [ expat-Bugs-1584898 ] (freed) memory access Message-ID: Bugs item #1584898, was opened at 2006-10-26 00:08 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=1584898&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (freed) memory access Initial Comment: There is a bug in latest and previous versions of expat. Following procedure may be accessing already freed memory under some cicrumstances (depending on malloc implementation and/or block size being re-allocated) I marked the offending lines with "### BUG -->" prefix /* Initially tag->rawName always points into the parse buffer; for those TAG instances opened while the current parse buffer was processed, and not yet closed, we need to store tag->rawName in a more permanent location, since the parse buffer is about to be discarded. */ static XML_Bool storeRawNames(XML_Parser parser) { TAG *tag = tagStack; while (tag) { int bufSize; int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1); char *rawNameBuf = tag->buf + nameLen; /* Stop if already stored. Since tagStack is a stack, we can stop at the first entry that has already been copied; everything below it in the stack is already been accounted for in a previous call to this function. */ if (tag->rawName == rawNameBuf) break; /* For re-use purposes we need to ensure that the size of tag->buf is a multiple of sizeof(XML_Char). */ bufSize = nameLen + ROUND_UP(tag->rawNameLength, sizeof (XML_Char)); if (bufSize > tag->bufEnd - tag->buf) { char *temp = (char *)REALLOC(tag->buf, bufSize); if (temp == NULL) return XML_FALSE; /* if tag->name.str points to tag->buf (only when namespace processing is off) then we have to update it */ ### ABOVE REALLOC may return different memory block so following tag->buf access may become invalid "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) tag->name.str = (XML_Char *)temp; /* if tag->name.localPart is set (when namespace processing is on) then update it as well, since it will always point into tag->buf */ if (tag->name.localPart) tag->name.localPart = (XML_Char *)temp + (tag->name.localPart - (XML_Char *)tag->buf); Following statement should have been performed just after REALLOC "### BUG -->" tag->buf = temp; tag->bufEnd = temp + bufSize; rawNameBuf = temp + nameLen; } memcpy(rawNameBuf, tag->rawName, tag->rawNameLength); tag->rawName = rawNameBuf; tag = tag->parent; } return XML_TRUE; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&group_id=10127 From noreply at sourceforge.net Thu Oct 26 15:07:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 06:07:42 -0700 Subject: [Expat-bugs] [ expat-Bugs-1584898 ] (freed) memory access Message-ID: Bugs item #1584898, was opened at 2006-10-26 03:08 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (freed) memory access Initial Comment: There is a bug in latest and previous versions of expat. Following procedure may be accessing already freed memory under some cicrumstances (depending on malloc implementation and/or block size being re-allocated) I marked the offending lines with "### BUG -->" prefix /* Initially tag->rawName always points into the parse buffer; for those TAG instances opened while the current parse buffer was processed, and not yet closed, we need to store tag->rawName in a more permanent location, since the parse buffer is about to be discarded. */ static XML_Bool storeRawNames(XML_Parser parser) { TAG *tag = tagStack; while (tag) { int bufSize; int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1); char *rawNameBuf = tag->buf + nameLen; /* Stop if already stored. Since tagStack is a stack, we can stop at the first entry that has already been copied; everything below it in the stack is already been accounted for in a previous call to this function. */ if (tag->rawName == rawNameBuf) break; /* For re-use purposes we need to ensure that the size of tag->buf is a multiple of sizeof(XML_Char). */ bufSize = nameLen + ROUND_UP(tag->rawNameLength, sizeof (XML_Char)); if (bufSize > tag->bufEnd - tag->buf) { char *temp = (char *)REALLOC(tag->buf, bufSize); if (temp == NULL) return XML_FALSE; /* if tag->name.str points to tag->buf (only when namespace processing is off) then we have to update it */ ### ABOVE REALLOC may return different memory block so following tag->buf access may become invalid "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) tag->name.str = (XML_Char *)temp; /* if tag->name.localPart is set (when namespace processing is on) then update it as well, since it will always point into tag->buf */ if (tag->name.localPart) tag->name.localPart = (XML_Char *)temp + (tag->name.localPart - (XML_Char *)tag->buf); Following statement should have been performed just after REALLOC "### BUG -->" tag->buf = temp; tag->bufEnd = temp + bufSize; rawNameBuf = temp + nameLen; } memcpy(rawNameBuf, tag->rawName, tag->rawNameLength); tag->rawName = rawNameBuf; tag = tag->parent; } return XML_TRUE; } ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-26 09:07 Message: Logged In: YES user_id=290026 > ### ABOVE REALLOC may return different memory block so > following tag->buf access may become invalid > "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) > tag->name.str = (XML_Char *)temp; There is no dereferencing of the tag->buf pointer, just a pointer comparison, which can be done on any pointer, valid or invalid. Do you actually have a test case where you can reproduce an invalid memory access at this point int the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&group_id=10127 From noreply at sourceforge.net Thu Oct 26 15:08:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 06:08:45 -0700 Subject: [Expat-bugs] [ expat-Bugs-1566826 ] More "Frees" than "Allocs" Message-ID: Bugs item #1566826, was opened at 2006-09-28 03:07 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&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: Nobody/Anonymous (nobody) Summary: More "Frees" than "Allocs" Initial Comment: I used the Expat 2.0 in our project and it seems to work fine. I did a kind of component test using the parser including testing the expat sources. As i wrote own memory allocation functions (called ONLY by expat sources) i saw that the free function is called more often than the alloc function. Nevertheless all memory areas allocated with alloc will be freed again. Email: chris_1270 at web.de ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-26 09:08 Message: Logged In: YES user_id=290026 Does not seem to be a bug. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-29 09:13 Message: Logged In: YES user_id=290026 As far as I remember, the memory consumption does not increase a lot for larger files, but there is a certain amount of memory allocated initially. Short of re-designing Expat this cannot ve avoided. However, you can probably reduce it by re-building Expat with some symbols undefined, like XML_CONTEXT_BYTES or XML_DTD (if not needed). There is also XML_MIN_SIZE to try. Just search expat-discuss - there have been such discussions in the past. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-09-29 03:57 Message: Logged In: NO Sorry it was an error on my side in the functions which realized the counting of free and allocs. SO it seems to work fine. Sorry for your effort. But i have got another question regarding the memory demand. So it seems that also for small XML documents a lot of heap is needed (e.g. for a document with 1000 Bytes about 4000 Bytes memory is allocated). Because i want to use the parser in an embedded device its a lot of memory for my project (perhaps too much!). Perhaps you have an idea that the parser needs less memory!?? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-09-28 09:17 Message: Logged In: YES user_id=290026 Should that not trigger some sort of error? Any ideas which free calls are superfluous? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1566826&group_id=10127 From noreply at sourceforge.net Fri Oct 27 04:03:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 19:03:15 -0700 Subject: [Expat-bugs] [ expat-Bugs-1584898 ] (freed) memory access Message-ID: Bugs item #1584898, was opened at 2006-10-26 00:08 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (freed) memory access Initial Comment: There is a bug in latest and previous versions of expat. Following procedure may be accessing already freed memory under some cicrumstances (depending on malloc implementation and/or block size being re-allocated) I marked the offending lines with "### BUG -->" prefix /* Initially tag->rawName always points into the parse buffer; for those TAG instances opened while the current parse buffer was processed, and not yet closed, we need to store tag->rawName in a more permanent location, since the parse buffer is about to be discarded. */ static XML_Bool storeRawNames(XML_Parser parser) { TAG *tag = tagStack; while (tag) { int bufSize; int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1); char *rawNameBuf = tag->buf + nameLen; /* Stop if already stored. Since tagStack is a stack, we can stop at the first entry that has already been copied; everything below it in the stack is already been accounted for in a previous call to this function. */ if (tag->rawName == rawNameBuf) break; /* For re-use purposes we need to ensure that the size of tag->buf is a multiple of sizeof(XML_Char). */ bufSize = nameLen + ROUND_UP(tag->rawNameLength, sizeof (XML_Char)); if (bufSize > tag->bufEnd - tag->buf) { char *temp = (char *)REALLOC(tag->buf, bufSize); if (temp == NULL) return XML_FALSE; /* if tag->name.str points to tag->buf (only when namespace processing is off) then we have to update it */ ### ABOVE REALLOC may return different memory block so following tag->buf access may become invalid "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) tag->name.str = (XML_Char *)temp; /* if tag->name.localPart is set (when namespace processing is on) then update it as well, since it will always point into tag->buf */ if (tag->name.localPart) tag->name.localPart = (XML_Char *)temp + (tag->name.localPart - (XML_Char *)tag->buf); Following statement should have been performed just after REALLOC "### BUG -->" tag->buf = temp; tag->bufEnd = temp + bufSize; rawNameBuf = temp + nameLen; } memcpy(rawNameBuf, tag->rawName, tag->rawNameLength); tag->rawName = rawNameBuf; tag = tag->parent; } return XML_TRUE; } ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-26 19:03 Message: Logged In: NO hi, you are right the program will never crash, but the verification tools will complain about it as the pointer being accessed is no longer valid. Anyhow it would be better if the same procedure is written in the followiing way, so that it is not "flaged" as problematic by subsequent tools (e.g. Bounds Checker, Purify, etc...) /* Initially tag->rawName always points into the parse buffer; for those TAG instances opened while the current parse buffer was processed, and not yet closed, we need to store tag->rawName in a more permanent location, since the parse buffer is about to be discarded. */ static XML_Bool storeRawNames(XML_Parser parser) { TAG *tag = tagStack; while (tag) { int bufSize; int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1); char *rawNameBuf = tag->buf + nameLen; /* Stop if already stored. Since tagStack is a stack, we can stop at the first entry that has already been copied; everything below it in the stack is already been accounted for in a previous call to this function. */ if (tag->rawName == rawNameBuf) break; /* For re-use purposes we need to ensure that the size of tag->buf is a multiple of sizeof(XML_Char). */ bufSize = nameLen + ROUND_UP(tag->rawNameLength, sizeof(XML_Char)); if (bufSize > tag->bufEnd - tag->buf) { /* mj [27-10-2006] */ XML_Bool updateTagName = tag->name.str == (XML_Char *)tag->buf; char *temp = (char *)REALLOC(tag->buf, bufSize); if (temp == NULL) return XML_FALSE; /* mj [26-10-2006] - due to REALLOC statement tag->buf may become invalid, therefore i * update the pointer before subsequent accesses occur to it */ tag->buf = temp; /* if tag->name.str points to tag->buf (only when namespace processing is off) then we have to update it */ if (updateTagName /* mj [27-10-2006] tag->name.str == (XML_Char *)tag->buf */ ) tag->name.str = (XML_Char *)temp; /* if tag->name.localPart is set (when namespace processing is on) then update it as well, since it will always point into tag->buf */ if (tag->name.localPart) tag->name.localPart = (XML_Char *)temp + (tag->name.localPart - (XML_Char *)tag->buf); /* mj [26-10-2006] - removed (see above) following statement */ /* tag->buf = temp; */ tag->bufEnd = temp + bufSize; rawNameBuf = temp + nameLen; } memcpy(rawNameBuf, tag->rawName, tag->rawNameLength); tag->rawName = rawNameBuf; tag = tag->parent; } return XML_TRUE; } Best Regards, mj ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-26 06:07 Message: Logged In: YES user_id=290026 > ### ABOVE REALLOC may return different memory block so > following tag->buf access may become invalid > "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) > tag->name.str = (XML_Char *)temp; There is no dereferencing of the tag->buf pointer, just a pointer comparison, which can be done on any pointer, valid or invalid. Do you actually have a test case where you can reproduce an invalid memory access at this point int the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&group_id=10127 From noreply at sourceforge.net Fri Oct 27 16:43:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 07:43:56 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 13:17 Message generated for change (Comment added) made by wkosborn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&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: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-27 08:43 Message: Logged In: YES user_id=1625052 Hi again, I figured out the problem. The reason for: checking for ranlib... - at true Is because I had an environment variable RANLIB that was set to - at true (assuming that this variable is supposed to contain the location of the executable program ranlib, this obviously isn't it). The configure script reads this value in and uses it. Removing the environment variable seem to work - I did that with: unset RANLIB and now it's compiling. Thanks, and sorry about all of this! Wendy (wkosborn at sourceforge) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-25 18:00 Message: Logged In: YES user_id=290026 I tried again with FC4, no problem. Here is what I am using: - autoconf version 2.59 - libtool version 1.5.16 - gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) and yes, my configure output is: checking for ranlib... ranlib I don't know what ranlib refers to, however. Looks like this should be the focus of attention. ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 14:13 Message: Logged In: YES user_id=1625052 Hi again, I just noticed something that may be causing the problem - although I admit I don't know what to do about it. In the configure output above I noticed this: checking for ranlib... - at true isn't this supposed to be: checking for ranlib... ranlib ? Thanks, Wendy (wkosborn at sourceforge) ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 13:44 Message: Logged In: YES user_id=1625052 Hi again, I was able to access another machine with Fedora Core 4, so I thought I would try to make expat 2.0.0 on there (CVS distribution). I ran buildconf.sh, then ./configure, then make. I got the same error as above. I was told that Expat did link with no problems under FC4. So maybe i'm doing something wrong? Please let me know . Thanks, Wendy ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-19 14:13 Message: Logged In: YES user_id=290026 This one seems important to fix before the next release. Greg or Fred, please assist! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Fri Oct 27 17:26:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 08:26:01 -0700 Subject: [Expat-bugs] [ expat-Bugs-1580748 ] Not linking under Fedora Core 5 Message-ID: Bugs item #1580748, was opened at 2006-10-19 15:17 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&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: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Not linking under Fedora Core 5 Initial Comment: I'm trying to compile Expat on Fedora Core 5 (first 1.95.8, then I obtained 2.0.0 from CVS to try that) and it fails at the linking stage. Below is the output from make and configure. Please help. What we have: gcc 4.1.0 libool 1.5.22 If you need any other information please let me know. Thanks! Wendy -----------output from make--------------- /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c /bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c /bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:0:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo ./libtool: line 5906: eval: -@: invalid option eval: usage: eval [arg ...] make: *** [libexpat.la] Error 2 -------output from configure----------- checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu 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... /bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B 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... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... - at true 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... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes 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/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/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... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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 g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux 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... /usr/bin/install -c checking whether gcc accepts -fexceptions... yes checking for ANSI C header files... (cached) yes checking whether byte ordering is bigendian... no 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 ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-27 11:26 Message: Logged In: YES user_id=290026 One more problem solved. :-) Closing this issue. ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-27 10:43 Message: Logged In: YES user_id=1625052 Hi again, I figured out the problem. The reason for: checking for ranlib... - at true Is because I had an environment variable RANLIB that was set to - at true (assuming that this variable is supposed to contain the location of the executable program ranlib, this obviously isn't it). The configure script reads this value in and uses it. Removing the environment variable seem to work - I did that with: unset RANLIB and now it's compiling. Thanks, and sorry about all of this! Wendy (wkosborn at sourceforge) ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-25 20:00 Message: Logged In: YES user_id=290026 I tried again with FC4, no problem. Here is what I am using: - autoconf version 2.59 - libtool version 1.5.16 - gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) and yes, my configure output is: checking for ranlib... ranlib I don't know what ranlib refers to, however. Looks like this should be the focus of attention. ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 16:13 Message: Logged In: YES user_id=1625052 Hi again, I just noticed something that may be causing the problem - although I admit I don't know what to do about it. In the configure output above I noticed this: checking for ranlib... - at true isn't this supposed to be: checking for ranlib... ranlib ? Thanks, Wendy (wkosborn at sourceforge) ---------------------------------------------------------------------- Comment By: wko (wkosborn) Date: 2006-10-25 15:44 Message: Logged In: YES user_id=1625052 Hi again, I was able to access another machine with Fedora Core 4, so I thought I would try to make expat 2.0.0 on there (CVS distribution). I ran buildconf.sh, then ./configure, then make. I got the same error as above. I was told that Expat did link with no problems under FC4. So maybe i'm doing something wrong? Please let me know . Thanks, Wendy ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-19 16:13 Message: Logged In: YES user_id=290026 This one seems important to fix before the next release. Greg or Fred, please assist! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1580748&group_id=10127 From noreply at sourceforge.net Fri Oct 27 17:43:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 08:43:41 -0700 Subject: [Expat-bugs] [ expat-Bugs-1584898 ] (freed) memory access Message-ID: Bugs item #1584898, was opened at 2006-10-26 03:08 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: (freed) memory access Initial Comment: There is a bug in latest and previous versions of expat. Following procedure may be accessing already freed memory under some cicrumstances (depending on malloc implementation and/or block size being re-allocated) I marked the offending lines with "### BUG -->" prefix /* Initially tag->rawName always points into the parse buffer; for those TAG instances opened while the current parse buffer was processed, and not yet closed, we need to store tag->rawName in a more permanent location, since the parse buffer is about to be discarded. */ static XML_Bool storeRawNames(XML_Parser parser) { TAG *tag = tagStack; while (tag) { int bufSize; int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1); char *rawNameBuf = tag->buf + nameLen; /* Stop if already stored. Since tagStack is a stack, we can stop at the first entry that has already been copied; everything below it in the stack is already been accounted for in a previous call to this function. */ if (tag->rawName == rawNameBuf) break; /* For re-use purposes we need to ensure that the size of tag->buf is a multiple of sizeof(XML_Char). */ bufSize = nameLen + ROUND_UP(tag->rawNameLength, sizeof (XML_Char)); if (bufSize > tag->bufEnd - tag->buf) { char *temp = (char *)REALLOC(tag->buf, bufSize); if (temp == NULL) return XML_FALSE; /* if tag->name.str points to tag->buf (only when namespace processing is off) then we have to update it */ ### ABOVE REALLOC may return different memory block so following tag->buf access may become invalid "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) tag->name.str = (XML_Char *)temp; /* if tag->name.localPart is set (when namespace processing is on) then update it as well, since it will always point into tag->buf */ if (tag->name.localPart) tag->name.localPart = (XML_Char *)temp + (tag->name.localPart - (XML_Char *)tag->buf); Following statement should have been performed just after REALLOC "### BUG -->" tag->buf = temp; tag->bufEnd = temp + bufSize; rawNameBuf = temp + nameLen; } memcpy(rawNameBuf, tag->rawName, tag->rawNameLength); tag->rawName = rawNameBuf; tag = tag->parent; } return XML_TRUE; } ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-27 11:43 Message: Logged In: YES user_id=290026 Your code introduces a bug in the line after if "(tag->name.localPart)", as it uses the new and not the old value of tag->buf. Apart from that, I do not see why we should rewrite the Expat code to compensate for the deficiencies of some debugging tools. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-26 22:03 Message: Logged In: NO hi, you are right the program will never crash, but the verification tools will complain about it as the pointer being accessed is no longer valid. Anyhow it would be better if the same procedure is written in the followiing way, so that it is not "flaged" as problematic by subsequent tools (e.g. Bounds Checker, Purify, etc...) /* Initially tag->rawName always points into the parse buffer; for those TAG instances opened while the current parse buffer was processed, and not yet closed, we need to store tag->rawName in a more permanent location, since the parse buffer is about to be discarded. */ static XML_Bool storeRawNames(XML_Parser parser) { TAG *tag = tagStack; while (tag) { int bufSize; int nameLen = sizeof(XML_Char) * (tag->name.strLen + 1); char *rawNameBuf = tag->buf + nameLen; /* Stop if already stored. Since tagStack is a stack, we can stop at the first entry that has already been copied; everything below it in the stack is already been accounted for in a previous call to this function. */ if (tag->rawName == rawNameBuf) break; /* For re-use purposes we need to ensure that the size of tag->buf is a multiple of sizeof(XML_Char). */ bufSize = nameLen + ROUND_UP(tag->rawNameLength, sizeof(XML_Char)); if (bufSize > tag->bufEnd - tag->buf) { /* mj [27-10-2006] */ XML_Bool updateTagName = tag->name.str == (XML_Char *)tag->buf; char *temp = (char *)REALLOC(tag->buf, bufSize); if (temp == NULL) return XML_FALSE; /* mj [26-10-2006] - due to REALLOC statement tag->buf may become invalid, therefore i * update the pointer before subsequent accesses occur to it */ tag->buf = temp; /* if tag->name.str points to tag->buf (only when namespace processing is off) then we have to update it */ if (updateTagName /* mj [27-10-2006] tag->name.str == (XML_Char *)tag->buf */ ) tag->name.str = (XML_Char *)temp; /* if tag->name.localPart is set (when namespace processing is on) then update it as well, since it will always point into tag->buf */ if (tag->name.localPart) tag->name.localPart = (XML_Char *)temp + (tag->name.localPart - (XML_Char *)tag->buf); /* mj [26-10-2006] - removed (see above) following statement */ /* tag->buf = temp; */ tag->bufEnd = temp + bufSize; rawNameBuf = temp + nameLen; } memcpy(rawNameBuf, tag->rawName, tag->rawNameLength); tag->rawName = rawNameBuf; tag = tag->parent; } return XML_TRUE; } Best Regards, mj ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2006-10-26 09:07 Message: Logged In: YES user_id=290026 > ### ABOVE REALLOC may return different memory block so > following tag->buf access may become invalid > "### BUG -->" if (tag->name.str == (XML_Char *)tag->buf) > tag->name.str = (XML_Char *)temp; There is no dereferencing of the tag->buf pointer, just a pointer comparison, which can be done on any pointer, valid or invalid. Do you actually have a test case where you can reproduce an invalid memory access at this point int the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=1584898&group_id=10127