From noreply@sourceforge.net Sat Dec 1 04:51:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Dec 1 04:51:02 2001 Subject: [ expat-Bugs-466885 ] Install Fails on FreeBSD 4.0 Message-ID: Bugs item #466885, was opened at 2001-10-01 09:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=466885&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Install Fails on FreeBSD 4.0 Initial Comment: make install failed on FreeBSD 4.0 returns the following... /usr/bin/install -c -m 644 expat.h /usr/local/include /bin/csh ../conftools/mkinstalldirs /usr/local/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/home/matt/dev/mods/expat-1.95.2/xmlwf. *** Error code 1 Stop in /usr/home/matt/dev/mods/expat-1.95.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-01 04:50 Message: Logged In: NO Try installing gmake and run "gmake install" instead of the FreeBSD make. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=466885&group_id=10127 From noreply@sourceforge.net Sat Dec 1 06:54:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Dec 1 06:54:11 2001 Subject: [ expat-Bugs-487840 ] xmlwf needs a man page Message-ID: Bugs item #487840, was opened at 2001-12-01 06:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487840&group_id=10127 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf needs a man page Initial Comment: The xmlwf utility is not documented at all; there needs to be some mention in the current documentation, and a man page should be installed on Unix systems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487840&group_id=10127 From noreply@sourceforge.net Sun Dec 2 14:11:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 2 14:11:03 2001 Subject: [ expat-Bugs-487840 ] xmlwf needs a man page Message-ID: Bugs item #487840, was opened at 2001-12-01 06:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487840&group_id=10127 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlwf needs a man page Initial Comment: The xmlwf utility is not documented at all; there needs to be some mention in the current documentation, and a man page should be installed on Unix systems. ---------------------------------------------------------------------- Comment By: Scott Bronson (bronson) Date: 2001-12-02 14:10 Message: Logged In: YES user_id=30977 I've posted a first draft of an xmlwf man page to the expat-discuss mailing list. I'm not quite sure how to attach the files to this incident, or I would include them here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487840&group_id=10127 From noreply@sourceforge.net Sun Dec 2 14:27:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 2 14:27:02 2001 Subject: [ expat-Patches-488187 ] wfcheckmessage.c is unused Message-ID: Patches item #488187, was opened at 2001-12-02 14:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488187&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Bronson (bronson) Assigned to: Nobody/Anonymous (nobody) Summary: wfcheckmessage.c is unused Initial Comment: It appears xmlwf/wfcheckmessage.c is antiqutated. You can remove it without trouble. Of course, you must also update the MANIFEST: diff -u -r1.8 MANIFEST --- MANIFEST 2001/08/23 13:12:17 1.8 +++ MANIFEST 2001/12/02 22:25:38 @@ -45,7 +45,6 @@ xmlwf/unixfilemap.c xmlwf/wfcheck.c xmlwf/wfcheck.h -xmlwf/wfcheckmessage.c xmlwf/win32filemap.c xmlwf/xmlfile.c xmlwf/xmlfile.h ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488187&group_id=10127 From noreply@sourceforge.net Sun Dec 2 14:46:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun Dec 2 14:46:02 2001 Subject: [ expat-Patches-488196 ] Make xmlwf support reading from stdin Message-ID: Patches item #488196, was opened at 2001-12-02 14:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488196&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Bronson (bronson) Assigned to: Nobody/Anonymous (nobody) Summary: Make xmlwf support reading from stdin Initial Comment: With this patch, xmlwf works exactly as it used to except that, if you don't specify any files on the command line, xmlwf takes its input from stdin. If you use -d to output to a directory, the output file will be named "STDIN". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=488196&group_id=10127 From noreply@sourceforge.net Tue Dec 4 06:30:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Dec 4 06:30:07 2001 Subject: [ expat-Bugs-488899 ] Bad pointer from characterData handler Message-ID: Bugs item #488899, was opened at 2001-12-04 06:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Plummer (plummpj) Assigned to: Nobody/Anonymous (nobody) Summary: Bad pointer from characterData handler Initial Comment: Expat frequently returns bad data pointers to my handler for XML_SetCharacterDataHandler. I have expat V 1.95.2 installed on a SUN w Solaris 2.5.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127 From noreply@sourceforge.net Wed Dec 5 19:47:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 5 19:47:04 2001 Subject: [ expat-Bugs-445955 ] Make of 1.95.2 fails on MacOS X 10.0.4 Message-ID: Bugs item #445955, was opened at 2001-07-30 07:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make of 1.95.2 fails on MacOS X 10.0.4 Initial Comment: expat 1.95.2.tar.gz distribution On MacOS X 10.0.4 (Darwin 1.3.7) make issues an error and halts: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt 0.o make[1]: *** [xmlwf] Error 1 ma ke: *** [xmlwf] Error 2 This does not happen with the older version 1.95.1 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-05 19:46 Message: Logged In: NO I made the fix Zenzen suggested and it failed again. If this happens check xmlwf/Makefile also for the -static flag in LDFLAGS. ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:47 Message: Logged In: YES user_id=12935 I can only agree with zenzen, this should be easy enough to fix with a check in configure.in ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2001-09-23 00:03 Message: Logged In: YES user_id=46639 xmlwf/Makefile.in seems to want to add the -static option to LDFLAGS. This breaks OSX. Removing the -static flag from LDFLAGS fixes the problem and everything appears to build happily. The configure script correctly detects that this option doesn't work under OSX. ---------------------------------------------------------------------- Comment By: Nat Irons (bumppo) Date: 2001-08-22 13:23 Message: Logged In: YES user_id=8138 I also see make breaking on xmlwf with 1.95.2 on Mac OS X 10.0.4, but my symptoms are slightly different: gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: xmlwf.o incompatible, file contains unsupported type of section 5 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: xmlfile.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: unixfilemap.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 If you'd like to follow up with someone having the first problem, it was also reported on the perl-macosx list. Like the original poster, 1.95.1 installs smoothly for me here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 From noreply@sourceforge.net Thu Dec 6 00:14:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 6 00:14:04 2001 Subject: [ expat-Bugs-438876 ] Configure for expat seems to require gcc Message-ID: Bugs item #438876, was opened at 2001-07-05 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438876&group_id=10127 Category: Build control Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Configure for expat seems to require gcc Initial Comment: I was told that expat was a portable, ligthweight XML parser, but I am having portability issues. If one uses the GNU gcc compilers on every platform, then expat seems quite portable. However, I was surprised to find that the configure script has no option for selecting a compiler other than gcc. As an alternative, I configured without providing any configure options, and then went to hacking at the Makefiles and the libtool script. This seems a bad alternative to having an option to select other compilers in the configure script. As many other bug reports have mentioned, the individual trying to install expat using a non-GNU C compiler is left to manually change the compile and link options, without a clue as to what must be changed. I have been trying to port to the WorkShop5.0 comilers for Solaris 2.7. After hacking compiler options for dependencies, shared object libraries, optimization, etc., I gave up when 'make' returned the following: cd lib; gmake gmake[1]: Entering directory `/home/netlj/Software/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -xO2 -c xmlparse.c mkdir .libs cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -xO2 -c xmlparse.c -KPIC -DPIC -o .libs/xmlparse.lo cc: illegal suffix of output filename gmake[1]: *** [xmlparse.lo] Error 1 gmake[1]: Leaving directory `/home/netlj/Software/expat-1.95.1/lib' gmake: *** [lib] Error 2 Since I don't understand what the .lo file is for, I'm not sure how to proceed to resolve this problem. I'd like to request that you generalize your configure script to allow the user to specify a C compiler other than gcc. If the user is restricted to gcc or a fair amount of hacking, they may look elsewhere for a XML parser. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-06 00:13 Message: Logged In: NO I am building expat 1.95.2 on Solaris 7 with Sun WorkShop 5.0. I do have a small problem that I'll document in another bug report, but there's no such issue with expat 1.95.2 anymore, if there ever was one with expat 1.95.1. That said, maybe the README file could have a sentence like "to build with a compiler other than the default (GCC) use CC=cc and CFLAGS=." ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 20:22 Message: Logged In: YES user_id=3066 Looking at this again, I suspect this is still a possible problem. This probably represents some non-portability in the libtool tool. Can anyone confirm this, or offer a fix? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 20:54 Message: Logged In: YES user_id=3066 I think all the gcc dependencies have been removed from the current development version in CVS. Can anyone with this compiler and not GCC check this to see if the problem persists? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438876&group_id=10127 From noreply@sourceforge.net Thu Dec 6 00:23:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 6 00:23:06 2001 Subject: [ expat-Bugs-489757 ] expat 1.95.2 / Sun WorkShop 5.0 Message-ID: Bugs item #489757, was opened at 2001-12-06 00:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=489757&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Greg Stein (gstein) Summary: expat 1.95.2 / Sun WorkShop 5.0 Initial Comment: Hi, I'm building expat 1.95.2 on Solaris 7 with Sun WorkShop 5.0. I configure using: setenv CC cc ./configure --prefix=/usr/local/expat-1.95.2 While installing I get this error: gmake[1]: Entering directory `/tmp/expat-1.95.2/xmlwf' cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. gmake[1]: *** [xmlwf] Error 1 gmake[1]: Leaving directory `/tmp/expat-1.95.2/xmlwf' gmake: *** [install] Error 2 This is because the Sun compiler needs a "-Bstatic" option to link statically, not "-static". The problem is that this is hard-coded in xmlwf/Makefile.in: LDFLAGS= @LDFLAGS@ -static I'm sure libtool or autoconf can handle this - although I don't know how... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=489757&group_id=10127 From noreply@sourceforge.net Thu Dec 6 00:26:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 6 00:26:04 2001 Subject: [ expat-Bugs-489757 ] expat 1.95.2 / Sun WorkShop 5.0 Message-ID: Bugs item #489757, was opened at 2001-12-06 00:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=489757&group_id=10127 Category: Build control Group: Platform Specific Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Greg Stein (gstein) Summary: expat 1.95.2 / Sun WorkShop 5.0 Initial Comment: Hi, I'm building expat 1.95.2 on Solaris 7 with Sun WorkShop 5.0. I configure using: setenv CC cc ./configure --prefix=/usr/local/expat-1.95.2 While installing I get this error: gmake[1]: Entering directory `/tmp/expat-1.95.2/xmlwf' cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. gmake[1]: *** [xmlwf] Error 1 gmake[1]: Leaving directory `/tmp/expat-1.95.2/xmlwf' gmake: *** [install] Error 2 This is because the Sun compiler needs a "-Bstatic" option to link statically, not "-static". The problem is that this is hard-coded in xmlwf/Makefile.in: LDFLAGS= @LDFLAGS@ -static I'm sure libtool or autoconf can handle this - although I don't know how... ---------------------------------------------------------------------- >Comment By: Dimitri Papadopoulos (papadopo) Date: 2001-12-06 00:25 Message: Logged In: YES user_id=52414 It just occurred to me this is a duplicate of #469226. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=489757&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:28:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:28:03 2001 Subject: [ expat-Bugs-230172 ] examples and xmlwf Makefile.in don't support builddir Message-ID: Bugs item #230172, was opened at 2001-01-26 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=230172&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Axel Hecht (axelhecht) Assigned to: Greg Stein (gstein) Summary: examples and xmlwf Makefile.in don't support builddir Initial Comment: The Makefile.in's for xmlwf and examples don't cope with a build dir != srcdir. Please add srcdir = @srcdir@ top_srcdir = @top_srcdir@ VPATH = @srcdir@ and add -I$(srcdir)/../lib to CFLAGS. Should LDFLAGS do -L../lib, or -L../lib/.libs? Axel ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:27 Message: Logged In: YES user_id=6501 We're now using libtool to do the linking (against libexpat.la), and full VPATH support is completed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-01 14:24 Message: Logged In: YES user_id=3066 Greg, isn't this done already? Please review the open bugs assigned to you. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2001-08-26 03:40 Message: Logged In: YES user_id=6501 We should be linking using libtool, and link against libexpat.la. We won't have to know anything about the .libs directory in that case. The vpath stuff has been handled, yes. It will be even simpler when we complete the move to a single makefile. Leaving open until we make the final switch to libtool- based linking. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 14:50 Message: Logged In: YES user_id=3066 I'm not sure what the deal should be with the LDFLAGS setting; I'll leave that with Greg for a little longer, at least until I can read up some more on libtool. The other changes appear to have already been made in CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=230172&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:29:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:29:02 2001 Subject: [ expat-Bugs-481899 ] make install -- xmlwf fails on FreeBSD Message-ID: Bugs item #481899, was opened at 2001-11-14 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481899&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: make install -- xmlwf fails on FreeBSD Initial Comment: during make -- cd xmlwf && make gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c xmlwf.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c xmlfile.c xmlfile.c: In function `processStream': xmlfile.c:149: warning: implicit declaration of function `close' xmlfile.c:153: warning: implicit declaration of function `read' gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c codepage.c gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions -I../lib -c unixfilemap.c gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat britney# make install for dir in lib xmlwf; do (cd $dir && make install); done /bin/sh ../conftools/mkinstalldirs /usr/lib /usr/includ e /bin/sh ../libtool --mode=install /usr/bin/install -c libexpat.la /usr/lib/libexpat.la /usr/bin/install - c .libs/libexpat.so.1 /usr/lib/libexpat.so.1 (cd /usr/lib && rm -f libexpat.so && ln -s libexpat.so.1 libexpat.so) (cd /usr/lib && rm -f libexpat.so && ln -s libexpat.so.1 libexpat.so) /usr/bin/install - c .libs/libexpat.lai /usr/lib/libexpat.la /usr/bin/install - c .libs/libexpat.a /usr/lib/libexpat.a ranlib /usr/lib/libexpat.a chmod 644 /usr/lib/libexpat.a ------------------------------------------------------- --------------- Libraries have been installed in: /usr/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `- LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ------------------------------------------------------- --------------- /usr/bin/install -c -m 644 expat.h /usr/include /bin/csh ../conftools/mkinstalldirs /usr/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/local/build/expat-1.95.2/xmlwf. *** Error code 1 Stop in /usr/local/build/expat-1.95.2. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:28 Message: Logged In: YES user_id=6501 This has been fixed, now that we're using a single, top-level Makefile (with a correct SHELL variable). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-14 15:26 Message: Logged In: NO its trying to use csh to run a sh script .. easy fix ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=481899&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:31:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:31:02 2001 Subject: [ expat-Bugs-224390 ] File system filling when running configure on HP-UX 11.00 Message-ID: Bugs item #224390, was opened at 2000-12-04 07:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=224390&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Roger Spotts (rtspotts) Assigned to: Greg Stein (gstein) Summary: File system filling when running configure on HP-UX 11.00 Initial Comment: When trying to run the configure script on a HP-UX 11.00 system /tmp is being filled with a pxdbXXXXXXX file. The last check it runs is: checking for executable suffix I've increased the amount of available space up to 500Meg+ and the file keeps growing. Any help would be appreciated. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:30 Message: Logged In: YES user_id=6501 This is a local problem on the system; we don't do anything with the pxdb files, nor have I ever heard of such a thing. Closing the bug as "works for me" ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-25 13:32 Message: Logged In: YES user_id=3066 OK, I have no idea what's going on. Is it normal to build as root on HP-UX systems? Try building as a normal user. The build control has changed a fair bit, you may want to try the CVS version of Expat, or wait for the upcoming 1.95.2 release. ---------------------------------------------------------------------- Comment By: Roger Spotts (rtspotts) Date: 2000-12-26 08:03 Message: I guessing, but from the looks of it ltconfig is what's running at the time of the file system filling. It creates a group of PXDB files, but one is always huge. Here's a list of /tmp after it fills: -rw-rw-rw- 1 root sys 132 Dec 26 09:50 pxdbb05197 -rw-rw-rw- 1 root sys 0 Dec 26 09:50 pxdbc05197 -rw-rw-rw- 1 root sys 0 Dec 26 09:50 pxdbd05197 -rw-rw-rw- 1 root sys 0 Dec 26 09:50 pxdbe05197 -rw-rw-rw- 1 root sys 0 Dec 26 09:50 pxdbf05197 -rw-rw-rw- 1 root sys 532953088 Dec 26 09:51 pxdbg05197 -rw-rw-rw- 1 root sys 0 Dec 26 09:50 pxdbh05197 Here's a tail of the config.log file. If you need more I'll email the whole file. configure:1012: checking if the linker (/usr/bin/ld) is GNU ld configure:1028: checking for BSD-compatible nm configure:1064: checking whether ln -s works ltconfig:581: checking whether we are using GNU C ltconfig:589: cc -E conftest.c ltconfig:603: checking for object suffix ltconfig:604: cc -c -g conftest.c 1>&5 ltconfig:629: checking for executable suffix ltconfig:630: cc -o conftest -g conftest.c 1>&5 /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (conftest.o) was detected. The linked output may not run on a PA 1.x system I am running as root when I run the configure script, unless I change alot of system permissions I can't run it any other way. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-12-18 21:43 Message: This is *really* strange! Do you know what program configure is running when it creates the pxdb* file? Can you send the config.log file configure generates? Thanks! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-12-05 08:17 Message: This is a userid specific thing. I have the same problem (didn't get the reason for now). If i run configure as root, it works! Maybe you've installed a OS Patch that kill's the system. BUT i didn't got it running yet ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=224390&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:37:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:37:01 2001 Subject: [ expat-Bugs-225689 ] expat compile fails in ld on HPUX B.10.20 Message-ID: Bugs item #225689, was opened at 2000-12-13 09:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=225689&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: expat compile fails in ld on HPUX B.10.20 Initial Comment: I may be missing something here, but I can't figure out what % configure loading cache ./config.cache checking host system type... hppa2.0-hp-hpux10.20 checking build system type... hppa2.0-hp-hpux10.20 checking for ranlib... (cached) ranlib checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for ld used by GCC... (cached) /usr/intel/97r1/lib/gcc-lib/hppa1.1-hp-hpux10.20/cygnus-2.7-96q4/ld checking if the linker (/usr/intel/97r1/lib/gcc-lib/hppa1.1-hp-hpux10.20/cygnus-2.7-96q4/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /usr/ucb/nm -p checking whether ln -s works... (cached) yes loading cache ./config.cache within ltconfig checking for object suffix... o checking for executable suffix... (cached) no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions ... yes checking if gcc static flag -static works... -static checking if the linker (/usr/intel/97r1/lib/gcc-lib/hppa1.1-hp-hpux10.20/cygnus-2.7-96q4/ld) is GNU ld... no checking whether the linker (/usr/intel/97r1/lib/gcc-lib/hppa1.1-hp-hpux10.20/cygnus-2.7-96q4/ld) supports shared libraries... yes checking command to parse /usr/ucb/nm -p output... ok checking how to hardcode library paths into programs... relink checking for /usr/intel/97r1/lib/gcc-lib/hppa1.1-hp-hpux10.20/cygnus-2.7-96q4/ld option to reload object files... -r checking dynamic linker characteristics... hpux10.20 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /usr/intel/bin/ginstall -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) yes checking for working const... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) no checking for memmove... (cached) yes checking for bcopy... (cached) yes creating ./config.status creating Makefile creating lib/Makefile creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged fhc2269[19]% make autoconf Make: Cannot load autoconf. Stop. *** Error exit code 1 Stop. % make install /bin/sh ../libtool --mode=link gcc -version-info 0:1:0 -g -O2 -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* /usr/intel/97r1/lib/gcc-lib/hppa1.1-hp-hpux10.20/cygnus-2.7-96q4/ld -b +h libexpat.sl.0 +b /usr/local/lib -o .libs/libexpat.sl.0.1 xmlparse.lo xmltok.lo xmlrole.lo -lc collect2: unable to open dynamic dependency ' static branch' *** Error exit code 1 Stop. *** Error exit code 1 Stop. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:36 Message: Logged In: YES user_id=6501 The use of "autoconf" at Make time signals that this is 1.95.1 (maybe .2?). The latest system won't try and do that. (woah: maybe prerelease? the -version-info is wonky looking) Regarding the link failure: that would appear to be a local problem, but I can't be sure. Since this bug was filed anonymously, we can't even get more information on this. I hope this has been fixed by recent changes, so am simply closing this bug. Marking as "fixed" since we at least fixed the autoconf thing (which may have rippled into the other problem; one can always hope) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=225689&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:38:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:38:03 2001 Subject: [ expat-Bugs-409729 ] Make Fails Digital Unix 4.0d Message-ID: Bugs item #409729, was opened at 2001-03-19 05:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=409729&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make Fails Digital Unix 4.0d Initial Comment: ./configure works fine. But when I run >make I get nothing it just exits quietly without doing anything if I run >make install i get /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=1.95.0 -I. -I.. -g -c libtool: compile: cannot determine name of library object from '-c' *** Exit 1 Stop. *** Exit 1 Stop. Any help with this bug would be greatly appreciated. Thanks Bill ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:37 Message: Logged In: YES user_id=6501 Okay... we have a nice, single, top-level Make now, and clean usage of libtool throughout. Closing this issue. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2001-08-26 04:05 Message: Logged In: YES user_id=6501 The build system is being revamped further for the 1.95.3 release. It should not have a problem. I will close this bug when the build revamp is completed (i.e. when I believe we've truly nailed this issue). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-04 18:37 Message: Logged In: YES user_id=3066 Can anyone experiancing this problem reproduce it with the current CVS version? There have been a fair number of cleanups in the build control (thanks, Greg!). Assigned to Greg for monitoring. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-19 09:08 Message: Logged In: NO I could not get this to compile however, from following another lead in the bug reports I managed to get expat-1.95.1 in setld format for DU4.0d from ftp.thewrittenword.com. Problem Solved (sort of) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-19 07:28 Message: Logged In: NO I installed the latest gnu make and got cd lib; /usr/local/bin/make make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c rm -f .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -DPIC -o .libs/xmlparse.lo cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make: *** [lib] Error 2 so I looked through the old bug fixes and attempted to fix things by altering lib/Makefile.in according to other fixes: first I tried this: commenting out the following rules @echo '$(COMPILE) -c $<'; \ # $(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $< # @-cp .deps/$(*F).pp .deps/$(*F).P; \ # tr ' ' '\012' < .deps/$(*F).pp \ # | sed -e 's/^\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \ # >> .deps/$(*F).P; \ # rm .deps/$(*F).pp .c.lo: @echo '$(LTCOMPILE) -c $<'; \ # test -d .deps || mkdir .deps ; \ # $(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $< # @-sed -e 's/^\([^:]*\)\.o[ ]*:/\1.lo \1.o :/' \ # < .deps/$(*F).pp > .deps/$(*F).P; \ # tr ' ' '\012' < .deps/$(*F).pp \ # | sed -e 's/^\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \ # >> .deps/$(*F).P; \ # rm -f .deps/$(*F).pp and got this make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' cd .. \ && CONFIG_FILES=lib/Makefile CONFIG_HEADERS= /bin/sh ./config.status creating lib/Makefile make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmltok.c /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlrole.c /bin/sh ../libtool --mode=link cc -version-info 0:1:0 -g -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm -fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* (cd . && ln -s xmlparse.lo xmlparse.o) (cd . && ln -s xmltok.lo xmltok.o) ln: xmltok.o exists, specify -f to remove. make[1]: *** [libexpat.la] Error 1 make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make: *** [lib] Error 2 then i tried changing lines with -Wp,-MD,. to -Wp,-M. and got : make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' cd .. \ && CONFIG_FILES=lib/Makefile CONFIG_HEADERS= /bin/sh ./config.status creating lib/Makefile make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make[1]: Entering directory `/disk3/install/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -c xmlparse.c rm -f .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -Wp,-M.deps/xmlparse.pp -c xmlparse.c -DPIC -o .libs/xmlparse.lo cc: Error: Extraneous text follows Boolean option name in "-M.deps/xmlparse.pp" make[1]: *** [xmlparse.lo] Error 1 make[1]: Leaving directory `/disk3/install/expat-1.95.1/lib' make: *** [lib] Error 2 Still looking for a solution. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=409729&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:44:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:44:02 2001 Subject: [ expat-Bugs-438876 ] Configure for expat seems to require gcc Message-ID: Bugs item #438876, was opened at 2001-07-05 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438876&group_id=10127 Category: Build control Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Configure for expat seems to require gcc Initial Comment: I was told that expat was a portable, ligthweight XML parser, but I am having portability issues. If one uses the GNU gcc compilers on every platform, then expat seems quite portable. However, I was surprised to find that the configure script has no option for selecting a compiler other than gcc. As an alternative, I configured without providing any configure options, and then went to hacking at the Makefiles and the libtool script. This seems a bad alternative to having an option to select other compilers in the configure script. As many other bug reports have mentioned, the individual trying to install expat using a non-GNU C compiler is left to manually change the compile and link options, without a clue as to what must be changed. I have been trying to port to the WorkShop5.0 comilers for Solaris 2.7. After hacking compiler options for dependencies, shared object libraries, optimization, etc., I gave up when 'make' returned the following: cd lib; gmake gmake[1]: Entering directory `/home/netlj/Software/expat-1.95.1/lib' /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.1 -I. -I.. -g -xO2 -c xmlparse.c mkdir .libs cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.1\ -I. -I.. -g -xO2 -c xmlparse.c -KPIC -DPIC -o .libs/xmlparse.lo cc: illegal suffix of output filename gmake[1]: *** [xmlparse.lo] Error 1 gmake[1]: Leaving directory `/home/netlj/Software/expat-1.95.1/lib' gmake: *** [lib] Error 2 Since I don't understand what the .lo file is for, I'm not sure how to proceed to resolve this problem. I'd like to request that you generalize your configure script to allow the user to specify a C compiler other than gcc. If the user is restricted to gcc or a fair amount of hacking, they may look elsewhere for a XML parser. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:43 Message: Logged In: YES user_id=6501 Selection of a compiler, flags, etc, are all part of the GNU configure process. In fact, with recent versions of autoconf (and the resulting configure script), just entering "./configure --help" will present help information about setting the compiler and CFLAGS. I'm closing this bug as fixed by virtue of our config/build cleanup. I would also recommend that the packager (fdrake currently) upgrade to autoconf 2.5x and libtool 1.4 for their improvements. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-06 00:13 Message: Logged In: NO I am building expat 1.95.2 on Solaris 7 with Sun WorkShop 5.0. I do have a small problem that I'll document in another bug report, but there's no such issue with expat 1.95.2 anymore, if there ever was one with expat 1.95.1. That said, maybe the README file could have a sentence like "to build with a compiler other than the default (GCC) use CC=cc and CFLAGS=." ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 20:22 Message: Logged In: YES user_id=3066 Looking at this again, I suspect this is still a possible problem. This probably represents some non-portability in the libtool tool. Can anyone confirm this, or offer a fix? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 20:54 Message: Logged In: YES user_id=3066 I think all the gcc dependencies have been removed from the current development version in CVS. Can anyone with this compiler and not GCC check this to see if the problem persists? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=438876&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:46:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:46:02 2001 Subject: [ expat-Bugs-461380 ] xmlwf/Makefile uses $SHELL uninitialized Message-ID: Bugs item #461380, was opened at 2001-09-13 16:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=461380&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: xmlwf/Makefile uses $SHELL uninitialized Initial Comment: In 1.95.2, 'make install' tries to use your login shell to run mkinstalldirs. This fails if your login shell isn't related to sh. xmlwf/Makefile.in needs "SHELL= @SHELL@" or some such. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:45 Message: Logged In: YES user_id=6501 Fixed in the latest release. We now have a single, top-level Makefile with a proper SHELL variable. xmlwf/Makefile is gone. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=461380&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:47:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:47:05 2001 Subject: [ expat-Bugs-489757 ] expat 1.95.2 / Sun WorkShop 5.0 Message-ID: Bugs item #489757, was opened at 2001-12-06 00:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=489757&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Greg Stein (gstein) Summary: expat 1.95.2 / Sun WorkShop 5.0 Initial Comment: Hi, I'm building expat 1.95.2 on Solaris 7 with Sun WorkShop 5.0. I configure using: setenv CC cc ./configure --prefix=/usr/local/expat-1.95.2 While installing I get this error: gmake[1]: Entering directory `/tmp/expat-1.95.2/xmlwf' cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. gmake[1]: *** [xmlwf] Error 1 gmake[1]: Leaving directory `/tmp/expat-1.95.2/xmlwf' gmake: *** [install] Error 2 This is because the Sun compiler needs a "-Bstatic" option to link statically, not "-static". The problem is that this is hard-coded in xmlwf/Makefile.in: LDFLAGS= @LDFLAGS@ -static I'm sure libtool or autoconf can handle this - although I don't know how... ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:46 Message: Logged In: YES user_id=6501 Closing. Duplicate of #469226. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2001-12-06 00:25 Message: Logged In: YES user_id=52414 It just occurred to me this is a duplicate of #469226. Sorry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=489757&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:49:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:49:02 2001 Subject: [ expat-Bugs-469226 ] -static is invalid for Sun's compiler Message-ID: Bugs item #469226, was opened at 2001-10-08 11:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=469226&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Reed (dtreed) Assigned to: Greg Stein (gstein) Summary: -static is invalid for Sun's compiler Initial Comment: The -static lines for LDFLAGS in the Makefiles for xmlwf and examples causes build problems when using Sun's purchased compiler (Forte) on a Sun box running Solaris 7. The error really isn't visable but it gives the following during a build: cc -g -I../lib -c -o unixfilemap.o unixfilemap.c cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat cc: -a conflicts with -dy. make[1]: *** [xmlwf] Error 1 make[1]: Leaving directory '/export/home/verity/src/Other/expat- 1.95.2/xmlwf' make: *** [xmlwf] Error 2 When "-static" is changed to "-B static" everything works just fine. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:48 Message: Logged In: YES user_id=6501 We're now using libtool to perform this link. No more -static flag, as we assume libtool will figure it out for us. The libtool configure-time flags such as --disable-shared can control whether static or shared stuff is built. Closing as fixed in the upcoming release. ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:50 Message: Logged In: YES user_id=12935 For OS X, -static has to be dropped, too, see http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 This should be fixed by a check in configure.in I'd say. ---------------------------------------------------------------------- Comment By: A.J.Smith (ajs_rdg) Date: 2001-10-31 08:57 Message: Logged In: YES user_id=362931 Oh - I see it now: expat-1.95.2/xmlwf/Makefile ---------------------------------------------------------------------- Comment By: A.J.Smith (ajs_rdg) Date: 2001-10-31 08:52 Message: Logged In: YES user_id=362931 This looks like just the problem I have. Please, can you clarify: WHERE do I have to change '-static' to '-B static'? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=469226&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:51:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:51:05 2001 Subject: [ expat-Bugs-470642 ] Configure with cross-compiler + endian Message-ID: Bugs item #470642, was opened at 2001-10-12 10:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=470642&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Configure with cross-compiler + endian Initial Comment: When "configure" discovers that the compiler (say "gcc") is a cross-compiler, it is more difficult for it to deduce the correct endian-ness of the target system. The script, however, has already figured out how to run the C pre-processor, which we can take advantage of. I modified "configure" as follows. (This also adds a few more variants on the BIG_ENDIAN and LITTLE_ENDIAN compiler predefined symbols.) After the "guessing bigendian ..." echo statement, comment out (or eliminate) the "echo" following it about 3 lines later. Add the following code, after the "fi" immediately following the "echo": if test $ac_cv_c_bigendian = unknown; then cat >conftest.c <&5; (eval $ac_try) 2>&5; } ac_err="`grep '^short[ ]*bytes[ ]*=[ ]*[0-4][0-4][0-4][0-4];' conftest.out 2>/d ev/null | sed -e 's|^[^=]*=[ ]*||' -e 's|;||'`" if test -z "$ac_err"; then ac_cv_c_bigendian=unknown elif test "X$ac_err" = "X4321"; then ac_cv_c_bigendian=yes elif test "X$ac_err" = "X1234"; then ac_cv_c_bigendian=no else ac_cv_c_bigendian=unknown fi rm -rf conftest* echo "$ac_t""$ac_cv_c_bigendian" 1>&6 fi ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:50 Message: Logged In: YES user_id=6501 We're now using a similar technique through the conftools/ac_c_bigendian_cross.m4 script. Closing as fixed in the upcoming release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=470642&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:55:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:55:02 2001 Subject: [ expat-Bugs-460604 ] Make fails for 1.95.2 on DecUnix 4.0F Message-ID: Bugs item #460604, was opened at 2001-09-11 00:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=460604&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Henrik Tougaard (htoug) Assigned to: Greg Stein (gstein) Summary: Make fails for 1.95.2 on DecUnix 4.0F Initial Comment: Make for 1.95.2 still fails on Digital Unix 4.0F using DEC make and Dec C-compiler. Would any further output would help in the analysis? Or is there something I can do to attempt to narrow donw where the bug is? Unfortunately I don't have the neccessary tuits to try to understand the complete build system. Output of configure, make and make install follows: $ ob$ configure creating cache ./config.cache checking host system type... alphaev56-dec-osf4.0f checking build system type... alphaev56-dec-osf4.0f checking for ranlib... ranlib checking for gcc... no checking for cc... cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/bin/nm checking whether ln -s works... yes updating cache ./config.cache checking whether we are using GNU C... no checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... none checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc static flag -non_shared works... - non_shared checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm output... failed checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... osf4.0f ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g ) works... yes checking whether the C compiler (cc -g ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD compatible install... conftools/install-sh -c checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for fcntl.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for working const... yes checking for off_t... yes checking for size_t... yes checking for 8-bit clean memcmp... yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for memmove... yes checking for bcopy... yes updating cache ./config.cache creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h $ ob$ make $ ob$ make install for dir in lib xmlwf; do (cd $dir && make install); done /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSI ON='"expat_1.95.2"' -I. -I. -I.. -g -c xmlparse.c mkdir .libs cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. - g -c xmlparse.c -DPIC -o .libs/xmlparse.lo cc: Warning: xmlparse.c, line 4485: In this statement, & before array "((BLOCK . ..)0)->s" is ignored. (addrarray) pool->blocks = pool->mem->realloc_fcn(pool- >blocks, offsetof(BLOCK, s) + blo ckSize * sizeof(XML_Char)); ------------------------------------------------------- -^ cc: Warning: xmlparse.c, line 4500: In this statement, & before array "((BLOCK . ..)0)->s" is ignored. (addrarray) tem = pool->mem->malloc_fcn(offsetof(BLOCK, s) + blockSize * sizeof(XML_Char )); --------------------------------^ mv -f .libs/xmlparse.lo xmlparse.o (cd . && ln -s xmlparse.o xmlparse.lo) /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSI ON='"expat_1.95.2"' -I. -I. -I.. -g -c xmltok.c rm -f .libs/xmltok.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. - g -c xmltok.c -DPIC -o .libs/xmltok.lo mv -f .libs/xmltok.lo xmltok.o (cd . && ln -s xmltok.o xmltok.lo) /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H - DPACKAGE='"expat"' -DVERSI ON='"expat_1.95.2"' -I. -I. -I.. -g -c xmlrole.c rm -f .libs/xmlrole.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. - g -c xmlrole.c -DPIC -o .libs/xmlrole.lo mv -f .libs/xmlrole.lo xmlrole.o (cd . && ln -s xmlrole.o xmlrole.lo) /bin/sh ../libtool --mode=link cc -version-info 1:0:1 -g -o libexpat.la -rpath /usr/local/lib xmlparse.lo xmltok.lo xmlrole.lo rm - fr .libs/libexpat.la .libs/libexpat.* .libs/libexpat.* /usr/bin/ld -shared -expect_unresolved \* xmlparse.o xmltok.o xmlrole.o -lc -msym -soname libexpat.so `test -n "1.1.0:0.0:1.0" && echo -set_version 1.1.0:0. 0:1.0` -update_registry .libs/so_locations - o .libs/libexpat.so.1.1.0 (cd .libs && rm -f libexpat.so && ln -s libexpat.so.1.1.0 libexpat.so) (cd .libs && rm -f libexpat.so && ln -s libexpat.so.1.1.0 libexpat.so) ar cru .libs/libexpat.a xmlparse.o xmltok.o xmlrole.o ranlib .libs/libexpat.a creating libexpat.la (cd .libs && rm -f libexpat.la && ln -s ../libexpat.la libexpat.la) /bin/sh ../conftools/mkinstalldirs /usr/local/lib /usr/ local/include /bin/sh ../libtool --mode=install ../conftools/install- sh -c libexpat.la /usr/lo cal/lib/libexpat.la ../conftools/install-sh - c .libs/libexpat.so.1.1.0 /usr/local/lib/libexpat.so.1. 1.0 cp: /usr/local/lib/#inst.4974#: Permission denied *** Exit 1 Stop. *** Exit 1 Stop. $ ob$ uname - a OSF1 luzia.foa.dk V4.0 1229 alpha ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:53 Message: Logged In: YES user_id=6501 The make operates just fine. The install fails because the user doesn't have permission to write to /usr/local/lib. Closing as invalid (user error). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=460604&group_id=10127 From noreply@sourceforge.net Fri Dec 7 02:57:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 02:57:03 2001 Subject: [ expat-Bugs-479909 ] make install fails on IRIX 6.3 (IP32) Message-ID: Bugs item #479909, was opened at 2001-11-08 23:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=479909&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: make install fails on IRIX 6.3 (IP32) Initial Comment: barley ~/BUILD/expat-1.95.2 # uname -a IRIX barley 6.3 12161207 IP32 barley ~/BUILD/expat-1.95.2 # which gcc /usr/freeware/bin/gcc barley ~/BUILD/expat-1.95.2 # which make /usr/bin/make barley ~/BUILD/expat-1.95.2 # make install [stuff snipped] for dir in lib xmlwf; do \ (cd $dir && make install); \ done /bin/sh ../conftools/mkinstalldirs /usr/local/l ib /usr/local/include /bin/sh ../libtool -- mode=install /usr/freeware/bin/ginstall -c libexpat.la /usr/local/lib/libexpat.la /usr/freeware/bin/ginstall - c .libs/libexpat.so.1.0 /usr/local/lib/libexpat.so.1.0 (cd /usr/local/lib && rm -f libexpat.so.1 && ln -s libexpat.so.1.0 libexpat.so.1) (cd /usr/local/lib && rm -f libexpat.so && ln -s libexpat.so.1.0 libexpat.so) (cd /usr/local/lib && rm -f libexpat.so && ln -s libexpat.so.1.0 libexpat.so) /usr/freeware/bin/ginstall - c .libs/libexpat.lai /usr/local/lib/libexpat.la /usr/freeware/bin/ginstall - c .libs/libexpat.a /usr/local/lib/libexpat.a : /usr/local/lib/libexpat.a chmod 644 /usr/local/lib/libexpat.a ------------------------------------------------------- --------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use `- LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARYN32_PATH' environment variable during execution - use the `-Wl,-rpath -Wl,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ------------------------------------------------------- --------------- /usr/freeware/bin/ginstall -c -m 644 expat.h /usr/local/include gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat ld32: FATAL 9: I/O error (/usr/lib32/mips3/nonshared/crt1.o): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) *** Error code 1 (bu21) ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 02:56 Message: Logged In: YES user_id=6501 We're now linking via libtool, so that may have fixed this error. Otherwise, it looks like some kind of local problem (missing crt?!). Please retry with the upcoming Expat release (or CVS). Closing as fixed (hoping the libtool switch will clean this up). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=479909&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:01:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:01:11 2001 Subject: [ expat-Bugs-487387 ] Link Error while in Expat. Message-ID: Bugs item #487387, was opened at 2001-11-29 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487387&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: Link Error while in Expat. Initial Comment: I am trying to install XML::Parser which uses Expat. I installes expat using expat_win32bin_1_95_2.exe. When I try to build XML::Parser, I get a few errors(Error message given Below). I am using Microsoft VC++ Version 6.0 to compile. Perl was built from Source(Version 5.6.1) and is not activestate perl. What could be wrong?? Error Message: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -c -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_MSVCRT_READFIX -O1 -MD -DNDEBUG -DVERSION=\2.30\ -DXS_VERSION=\2.30\ -ID:\perl\5.6.1\lib\MSWin32-x86\ Expat.c "Running Mkbootstrap for XML::Parser::Expat ()" D:\perl\5.6.1\bin\MSWin32-x86\perl.exe -Id:\perl\5.6.1\lib\MSWin32-x86 -Id:\perl\5.6.1\lib -MExtUtils::Command -e chmod 644 Expat.bs link -out:..\blib\arch\auto\XML\Parser\Expat\Expat.dll -dll -nologo -nodefaultlib -release -libpath:"d:\perl\5.6.1\lib\MSWin32-x86\CORE" -machine:x86 Expat.obj D:\perl\5.6.1\li ~1\MICROS~3\VC98\lib\advapi32.lib C:\PROGRA~1\MICROS~3\VC98\lib\shell32.lib C:\PROGRA~1\MICROS~3\VC98\lib\ole32.lib C:\PROGRA~1\MICROS~3\VC98\lib\oleaut32.lib C:\PROGRA~1\MICROS~3\VC98\lib 32.lib C:\PROGRA~1\MICROS~3\VC98\lib\msvcrt.lib -def:Expat.def Creating library ..\blib\arch\auto\XML\Parser\Expat\Expat.lib and object ..\blib\arch\auto\XML\Parser\Expat\Expat.exp Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetParamEntityParsing Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnknownEncodingHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUserData Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNamespaceDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate_MM Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetExternalEntityRefHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNotationDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnparsedEntityDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCdataSectionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCommentHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetProcessingInstructionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCharacterDataHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserFree Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ExternalEntityParserCreate Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentColumnNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentByteIndex Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode Expat.obj : error LNK2001: unresolved external symbol __imp__XML_Parse Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParseBuffer Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBuffer ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487387&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:01:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:01:11 2001 Subject: [ expat-Bugs-487385 ] Expat.obj : error LNK2001: Message-ID: Bugs item #487385, was opened at 2001-11-29 21:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487385&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: Expat.obj : error LNK2001: Initial Comment: I am trying to install XML::Parser which uses Expat. I installes expat using expat_win32bin_1_95_2.exe. When I try to build XML::Parser, I get a few errors(Error message given Below). I am using Microsoft VC++ Version 6.0 to compile. Perl was built from Source(Version 5.6.1) and is not activestte perl. What could be wrong?? Error Message: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -c -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_MSVCRT_READFIX -O1 -MD -DNDEBUG -DVERSION=\2.30\ -DXS_VERSION=\2.30\ -ID:\perl\5.6.1\lib\MSWin32-x86\ Expat.c "Running Mkbootstrap for XML::Parser::Expat ()" D:\perl\5.6.1\bin\MSWin32-x86\perl.exe -Id:\perl\5.6.1\lib\MSWin32-x86 -Id:\perl\5.6.1\lib -MExtUtils::Command -e chmod 644 Expat.bs link -out:..\blib\arch\auto\XML\Parser\Expat\Expat.dll -dll -nologo -nodefaultlib -release -libpath:"d:\perl\5.6.1\lib\MSWin32-x86\CORE" -machine:x86 Expat.obj D:\perl\5.6.1\li ~1\MICROS~3\VC98\lib\advapi32.lib C:\PROGRA~1\MICROS~3\VC98\lib\shell32.lib C:\PROGRA~1\MICROS~3\VC98\lib\ole32.lib C:\PROGRA~1\MICROS~3\VC98\lib\oleaut32.lib C:\PROGRA~1\MICROS~3\VC98\lib 32.lib C:\PROGRA~1\MICROS~3\VC98\lib\msvcrt.lib -def:Expat.def Creating library ..\blib\arch\auto\XML\Parser\Expat\Expat.lib and object ..\blib\arch\auto\XML\Parser\Expat\Expat.exp Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetParamEntityParsing Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnknownEncodingHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetElementHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUserData Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNamespaceDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserCreate_MM Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetExternalEntityRefHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetNotationDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetUnparsedEntityDeclHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCdataSectionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCommentHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetProcessingInstructionHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetCharacterDataHandler Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParserFree Expat.obj : error LNK2001: unresolved external symbol __imp__XML_SetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBase Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ExternalEntityParserCreate Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentLineNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentColumnNumber Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetCurrentByteIndex Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ErrorString Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetErrorCode Expat.obj : error LNK2001: unresolved external symbol __imp__XML_Parse Expat.obj : error LNK2001: unresolved external symbol __imp__XML_ParseBuffer Expat.obj : error LNK2001: unresolved external symbol __imp__XML_GetBuffer ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=487385&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:02:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:02:06 2001 Subject: [ expat-Bugs-477039 ] Compile Error on HP-UX 10_20 Message-ID: Bugs item #477039, was opened at 2001-10-31 17:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477039&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: Compile Error on HP-UX 10_20 Initial Comment: Not sure if this is a bug or just my lack of understanding. Does anyone have any idea why this refuses to compile ? $ ./configure --prefix=/opt/psfm/batch/scripts/expat loading cache ./config.cache checking host system type... hppa2.0-hp-hpux10.20 checking build system type... hppa2.0-hp-hpux10.20 checking for ranlib... (cached) ranlib checking for gcc... (cached) cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for non-GNU ld... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) no checking for BSD-compatible nm... (cached) /usr/bin/nm -p checking whether ln -s works... (cached) yes checking whether we are using GNU C... no checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... +Z checking if cc PIC flag +Z works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc static flag -Wl,-a -Wl,archive works... -Wl,-a -Wl,archive checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -p output... ok checking how to hardcode library paths into programs... relink checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... hpux10.20 dld.sl checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool loading cache ./config.cache checking for gcc... (cached) cc checking whether the C compiler (cc -g ) works... yes checking whether the C compiler (cc -g ) is a cross- compiler... no checking whether we are using GNU C... (cached) no checking whether cc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /opt/imake/bin/install -c checking how to run the C preprocessor... (cached) cc - E checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking whether byte ordering is bigendian... (cached) yes checking for working const... (cached) no checking for off_t... (cached) yes checking for size_t... (cached) yes checking for 8-bit clean memcmp... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) no checking for memmove... (cached) yes checking for bcopy... (cached) yes creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating xmlwf/Makefile creating examples/Makefile creating config.h config.h is unchanged $ make $ make install for dir in lib xmlwf; do \ (cd $dir && make install); \ done /bin/sh ../libtool --mode=compile cc - DHAVE_CONFIG_H -DPACKAGE='"expat"' -DVERSION='"expat_1.95.2"' -I. -I. -I.. -g -c xmlparse.c rm -f .libs/xmlparse.lo cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. - g -c xmlparse.c +Z -DPIC -o .libs/xmlparse.lo cc: "expat.h", line 80: error 1000: Unexpected symbol: "XML_Char". cc: "expat.h", line 81: error 1000: Unexpected symbol: "*". cc: error 2017: Cannot recover from earlier errors, terminating. *** Error exit code 1 Stop. cc -g -I../lib -c xmlwf.c cpp: "xmltchar.h", line 3: warning 2013: Unknown preprocessing directive. cc: "../lib/expat.h", line 80: warning 5: "const" will become a keyword. cc: "../lib/expat.h", line 80: error 1000: Unexpected symbol: "const". cc: "../lib/expat.h", line 81: error 1000: Unexpected symbol: "*". cc: error 2017: Cannot recover from earlier errors, terminating. *** Error exit code 1 Stop. *** Error exit code 1 Stop. $ Regards, Paul __________________________________________________ Technical Designer Peoplesoft Operations IT@AMP Level 3, 151 Clarence St, Sydney 2000 Ph: +61-2-82962621 Email: paul_rashleigh@amp.com.au ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=477039&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:05:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:05:02 2001 Subject: [ expat-Bugs-484419 ] -fexceptions not supported in older gcc Message-ID: Bugs item #484419, was opened at 2001-11-21 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484419&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: -fexceptions not supported in older gcc Initial Comment: At least gcc 2.7.x does not support -fexceptions. The following patch to configure.in disables -fexceptions from CFLAGS for version of gcc prior to 2.8. --- configure.in.orig Thu Nov 22 00:23:32 2001 +++ configure.in @@ -63,7 +63,14 @@ AC_PROG_INSTALL if test "$GCC" = yes ; then - CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions " + CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -Wstrict-prototypes" + ${CC-cc} -v >conftest.c 2>&1 + gcc_pre_fexceptions=` + awk '/gcc version/{sub("^[^0-9]*","",$3);if ($3<2.8){print "true"} }' \ + conftest.c` + if [ -z "$gcc_pre_fexceptions" ]; then + CFLAGS="$CFLAGS -fexceptions" + fi fi dnl Checks for libraries. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 03:04 Message: Logged In: YES user_id=6501 Fred integrated something like this into configure.in. Closed as fixed in the upcoming release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=484419&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:07:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:07:02 2001 Subject: [ expat-Bugs-466141 ] install problems Message-ID: Bugs item #466141, was opened at 2001-09-28 10:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=466141&group_id=10127 Category: Build control Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: install problems Initial Comment: configure is missing from CVS. -Chris ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 03:06 Message: Logged In: YES user_id=6501 That is by design. We keep no generated files in CVS. Use "buildconf.sh" to create a configure script. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=466141&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:11:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:11:03 2001 Subject: [ expat-Bugs-466885 ] Install Fails on FreeBSD 4.0 Message-ID: Bugs item #466885, was opened at 2001-10-01 09:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=466885&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Install Fails on FreeBSD 4.0 Initial Comment: make install failed on FreeBSD 4.0 returns the following... /usr/bin/install -c -m 644 expat.h /usr/local/include /bin/csh ../conftools/mkinstalldirs /usr/local/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/home/matt/dev/mods/expat-1.95.2/xmlwf. *** Error code 1 Stop in /usr/home/matt/dev/mods/expat-1.95.2. ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 03:10 Message: Logged In: YES user_id=6501 That is a problem with an uninitialized SHELL variable in xmlwf/Makefile. However, we have since moved to a single, top-level Makefile, and that contains a proper SHELL. All should be fine in the upcoming release. Closing as fixed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-01 04:50 Message: Logged In: NO Try installing gmake and run "gmake install" instead of the FreeBSD make. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=466885&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:13:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:13:03 2001 Subject: [ expat-Bugs-470416 ] compile fails on UnixWare 7.1.1 with cc Message-ID: Bugs item #470416, was opened at 2001-10-11 15:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=470416&group_id=10127 Category: Build control Group: Platform Specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: compile fails on UnixWare 7.1.1 with cc Initial Comment: Using UnixWare's cc and gmake, compiling 1.95.1 fails; the offending lines are the .c.o and .c.lo dependencies in lib/Makefile.in which try to pass "-Wp,-MD,.deps/$(*F).pp" to the compiler, which is (of course) unrecognised. The library appears to build successfully when the dependency code is removed; is it necessary? ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 03:12 Message: Logged In: YES user_id=6501 We've tossed that stuff in the recent Expat. That was an old, lame thing to create dependencies. We simply maintain the deps by hand now. Closing as fixed in the upcoming release (and CVS). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=470416&group_id=10127 From noreply@sourceforge.net Fri Dec 7 03:17:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 7 03:17:04 2001 Subject: [ expat-Patches-451440 ] Build xmlwf with libtool Message-ID: Patches item #451440, was opened at 2001-08-15 20:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 Category: Build Control Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Greg Stein (gstein) Summary: Build xmlwf with libtool Initial Comment: A patch to build xmlwf with libtool can be found at: ftp://ftp.thewrittenword.com/outgoing/pub/expat-1.95.2.patch ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-12-07 03:16 Message: Logged In: YES user_id=6501 All done. We now link with libtool via a single, top-level Makefile. ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2001-08-26 03:30 Message: Logged In: YES user_id=6501 The xmlwf Makefile is going away, in favor of all compilation and linking from the top-level Makefile. At that point, everything will use libtool properly. I'll close this bug once that occurs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=310127&aid=451440&group_id=10127 From noreply@sourceforge.net Sat Dec 8 10:27:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat Dec 8 10:27:03 2001 Subject: [ expat-Bugs-445954 ] Make of 1.95.2 fails on MacOS X Server Message-ID: Bugs item #445954, was opened at 2001-07-30 07:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445954&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make of 1.95.2 fails on MacOS X Server Initial Comment: expat 1.95.2.tar.gz distribution On MacOS X Server 1.2 (Rhapsody 5.6) make issues an error and halts: cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ - DVERSION=\expat_1.95.2\ -I. -I. -I.. -g -O2 -Wall - Wmissing-prototypes -Wstrict-prototypes - fexceptions -c xmlparse.c -fPIC -DPIC -o .libs/ xmlparse.lo /System/Library/Frameworks/System.framework/ Headers/bsd/sys/cdefs.h:87: warning: redefinition of macro const ../config.h:5: warning: this is the location of the previous definition xmlparse.c:1178: illegal statement, missing `;' after `punting' make[1]: *** [xmlparse.lo] Error 1 make: *** [lib] Error 2 This does not happen with the older version 1.95.1 ---------------------------------------------------------------------- Comment By: Thomas Engelmeier (tom_e) Date: 2001-12-08 10:20 Message: Logged In: YES user_id=88916 MacOS X doesn't support the -static option for building commandline tools - as licrt0.o is not installed. Solution: in the Makefile in the xmlwf directory, remove the -static from the LDFLAGS line. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445954&group_id=10127 From noreply@sourceforge.net Wed Dec 12 04:49:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 12 04:49:04 2001 Subject: [ expat-Bugs-491986 ] Charset decoding error Message-ID: Bugs item #491986, was opened at 2001-12-12 04:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bent Jensen (bentjensen) Assigned to: Nobody/Anonymous (nobody) Summary: Charset decoding error Initial Comment: When parsing xml with Danish letters (æøåÆØÅ) with eight bit set and declaring the encoding as (where the danish letters is placed as eight bit chars - the parser goes wrong. If the input is: Worker Five Jørgen five@foo.com Jørgen five@foo.com (Remark the danish letters in two forms) The output is: START: email CD: (null) - 'J' - 1 CD: (null) - 'rgen five@foo.com' - 17 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 START: email CD: (null) - 'JÃ؟rgen five@foo.com' - 20 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 What am i doing wrong ? If I embedd the string 'æøåÆØÅ' in the xml file - it goes all rigth ?!?! I have modifyed the 'outline' example program for the above test. Sincerly Bent Jensen, Senior consultant. bent@kiya.dk ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply@sourceforge.net Wed Dec 12 04:57:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 12 04:57:01 2001 Subject: [ expat-Bugs-491986 ] Charset decoding error Message-ID: Bugs item #491986, was opened at 2001-12-12 04:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bent Jensen (bentjensen) Assigned to: Nobody/Anonymous (nobody) Summary: Charset decoding error Initial Comment: When parsing xml with Danish letters (æøåÆØÅ) with eight bit set and declaring the encoding as (where the danish letters is placed as eight bit chars - the parser goes wrong. If the input is: Worker Five Jørgen five@foo.com Jørgen five@foo.com (Remark the danish letters in two forms) The output is: START: email CD: (null) - 'J' - 1 CD: (null) - 'rgen five@foo.com' - 17 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 START: email CD: (null) - 'JÃ؟rgen five@foo.com' - 20 END: email CD: (null) - ' ' - 1 CD: (null) - ' ' - 4 What am i doing wrong ? If I embedd the string 'æøåÆØÅ' in the xml file - it goes all rigth ?!?! I have modifyed the 'outline' example program for the above test. Sincerly Bent Jensen, Senior consultant. bent@kiya.dk ---------------------------------------------------------------------- >Comment By: Bent Jensen (bentjensen) Date: 2001-12-12 04:56 Message: Logged In: YES user_id=392963 Info: The expat package (version 1.95.2) was build on alpha/axp OSF1 4.0D with gcc version 2.95.3. The test was run on the same machine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=491986&group_id=10127 From noreply@sourceforge.net Wed Dec 12 18:49:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 12 18:49:02 2001 Subject: [ expat-Bugs-492321 ] Corruption of parse data when chunked Message-ID: Bugs item #492321, was opened at 2001-12-12 18:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=492321&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thorsten Lockert (tholo) Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of parse data when chunked Initial Comment: If you use expat to parse-as-you-go on data received in varying size blocks (and not neccecarily equal- sized blocks), there appears to be somewhat random corruption of the parse state. This is most noticeable if you call XML_Parse on blocks of data as you receive them on a socket, but can also be emulated by calling XML_Parse on randomly sized chunks of an XML text. I have not yet tried to track it down to whether it only happens with certain block sizes... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=492321&group_id=10127 From noreply@sourceforge.net Wed Dec 12 18:50:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 12 18:50:01 2001 Subject: [ expat-Bugs-492321 ] Corruption of parse data when chunked Message-ID: Bugs item #492321, was opened at 2001-12-12 18:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=492321&group_id=10127 Category: None Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Thorsten Lockert (tholo) Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of parse data when chunked Initial Comment: If you use expat to parse-as-you-go on data received in varying size blocks (and not neccecarily equal- sized blocks), there appears to be somewhat random corruption of the parse state. This is most noticeable if you call XML_Parse on blocks of data as you receive them on a socket, but can also be emulated by calling XML_Parse on randomly sized chunks of an XML text. I have not yet tried to track it down to whether it only happens with certain block sizes... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=492321&group_id=10127 From noreply@sourceforge.net Thu Dec 13 17:25:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 13 17:25:02 2001 Subject: [ expat-Bugs-492321 ] Corruption of parse data when chunked Message-ID: Bugs item #492321, was opened at 2001-12-12 18:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=492321&group_id=10127 Category: None Group: None >Status: Closed Resolution: None Priority: 8 Submitted By: Thorsten Lockert (tholo) Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of parse data when chunked Initial Comment: If you use expat to parse-as-you-go on data received in varying size blocks (and not neccecarily equal- sized blocks), there appears to be somewhat random corruption of the parse state. This is most noticeable if you call XML_Parse on blocks of data as you receive them on a socket, but can also be emulated by calling XML_Parse on randomly sized chunks of an XML text. I have not yet tried to track it down to whether it only happens with certain block sizes... ---------------------------------------------------------------------- >Comment By: Thorsten Lockert (tholo) Date: 2001-12-13 17:24 Message: Logged In: YES user_id=153389 Pilot error -- the character handler was not set up to handle multiple calls per section of data... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=492321&group_id=10127 From noreply@sourceforge.net Fri Dec 14 13:46:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri Dec 14 13:46:02 2001 Subject: [ expat-Bugs-493466 ] install of 1.95.2 failes : FreeBSD 4.4-R Message-ID: Bugs item #493466, was opened at 2001-12-14 13:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=493466&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: install of 1.95.2 failes : FreeBSD 4.4-R Initial Comment: While tring to make && make install on FreeBSD 4.4-R (i386) I got the following error /bin/csh ../conftools/mkinstalldirs /usr/local/expat/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/local/src/expat-1.95.2/xmlwf. *** Error code 1 Stop in /usr/local/src/expat-1.95.2 but when I try to install 1.95.1 it installs fine. So I assume it's a bug in 1.95.2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=493466&group_id=10127 From noreply@sourceforge.net Tue Dec 18 05:34:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Dec 18 05:34:02 2001 Subject: [ expat-Bugs-445955 ] Make of 1.95.2 fails on MacOS X 10.0.4 Message-ID: Bugs item #445955, was opened at 2001-07-30 07:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Make of 1.95.2 fails on MacOS X 10.0.4 Initial Comment: expat 1.95.2.tar.gz distribution On MacOS X 10.0.4 (Darwin 1.3.7) make issues an error and halts: cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt 0.o make[1]: *** [xmlwf] Error 1 ma ke: *** [xmlwf] Error 2 This does not happen with the older version 1.95.1 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-18 05:32 Message: Logged In: NO When not done ./configure, change xmlwf/Makefile.in as follows. ( If configure has done, change xmlwf/Makefile ) #LDFLAGS= -static LDFLAGS= -dynamic I can build successfull and works well. -- Ran Hamada ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-05 19:46 Message: Logged In: NO I made the fix Zenzen suggested and it failed again. If this happens check xmlwf/Makefile also for the -static flag in LDFLAGS. ---------------------------------------------------------------------- Comment By: Max Horn (fingolfin) Date: 2001-10-31 13:47 Message: Logged In: YES user_id=12935 I can only agree with zenzen, this should be easy enough to fix with a check in configure.in ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2001-09-23 00:03 Message: Logged In: YES user_id=46639 xmlwf/Makefile.in seems to want to add the -static option to LDFLAGS. This breaks OSX. Removing the -static flag from LDFLAGS fixes the problem and everything appears to build happily. The configure script correctly detects that this option doesn't work under OSX. ---------------------------------------------------------------------- Comment By: Nat Irons (bumppo) Date: 2001-08-22 13:23 Message: Logged In: YES user_id=8138 I also see make breaking on xmlwf with 1.95.2 on Mac OS X 10.0.4, but my symptoms are slightly different: gcc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: xmlwf.o incompatible, file contains unsupported type of section 5 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: xmlfile.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) /usr/bin/ld: unixfilemap.o incompatible, file contains unsupported type of section 4 (__TEXT,__picsymbol_stub) in load command 0 (must specify "-dynamic" to be used) make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 If you'd like to follow up with someone having the first problem, it was also reported on the perl-macosx list. Like the original poster, 1.95.1 installs smoothly for me here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=445955&group_id=10127 From noreply@sourceforge.net Tue Dec 18 12:29:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue Dec 18 12:29:22 2001 Subject: [ expat-Bugs-494749 ] Missing .DSP file for MSVC users! Message-ID: Bugs item #494749, was opened at 2001-12-18 12:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=494749&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Missing .DSP file for MSVC users! Initial Comment: The documentation states that to build the software for Windows under MSVC, to just open the "expat.dsp" file in the lib/ directory. However, in the version I downloaded, 1.95.2, this file does not exist. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=494749&group_id=10127 From noreply@sourceforge.net Wed Dec 19 09:27:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed Dec 19 09:27:05 2001 Subject: [ expat-Bugs-495115 ] expat 1.95.2 fails to build on OS X Message-ID: Bugs item #495115, was opened at 2001-12-19 09:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=495115&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: expat 1.95.2 fails to build on OS X Initial Comment: Fails on Mac OS X 10.1.1 (Darwin) output: cd xmlwf && make cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o xmlwf.o xmlwf.c cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o xmlfile.o xmlfile.c xmlfile.c: In function `processStream': xmlfile.c:149: warning: implicit declaration of function `close' xmlfile.c:153: warning: implicit declaration of function `read' cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o codepage.o codepage.c cc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -I../lib -c -o unixfilemap.o unixfilemap.c cc -o xmlwf -static xmlwf.o xmlfile.o codepage.o unixfilemap.o -L../lib/.libs -lexpat /usr/bin/ld: can't locate file for: -lcrt0.o make[1]: *** [xmlwf] Error 1 make: *** [xmlwf] Error 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=495115&group_id=10127 From noreply@sourceforge.net Mon Dec 24 08:38:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon Dec 24 08:38:02 2001 Subject: [ expat-Bugs-496505 ] checking for malloc failures Message-ID: Bugs item #496505, was opened at 2001-12-24 08:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=496505&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric C. Newton (ericnewton) Assigned to: Nobody/Anonymous (nobody) Summary: checking for malloc failures Initial Comment: expat 1.95.2 (under RedHat linux 2.4) The following code (xmlparse.c:578) will crash, should the malloc() call fail: XML_Memory_Handling_Suite *mtemp; parser = malloc(sizeof(Parser)); mtemp = &(((Parser *) parser)->m_mem); mtemp->malloc_fcn = malloc; Likewise (xmlparse.c:1139) XML_GetBuffer() returns NULL when malloc() fails, and the result is not checked: memcpy(XML_GetBuffer(parser, len), s, len); Other than that, expat works quite well. Very nice library. -Eric ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=496505&group_id=10127 From noreply@sourceforge.net Thu Dec 27 13:40:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 27 13:40:02 2001 Subject: [ expat-Bugs-493466 ] install of 1.95.2 failes : FreeBSD 4.4-R Message-ID: Bugs item #493466, was opened at 2001-12-14 13:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=493466&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: install of 1.95.2 failes : FreeBSD 4.4-R Initial Comment: While tring to make && make install on FreeBSD 4.4-R (i386) I got the following error /bin/csh ../conftools/mkinstalldirs /usr/local/expat/bin errstatus=0: Command not found. for: Command not found. do: Command not found. set: Variable name must begin with a letter. *** Error code 1 Stop in /usr/local/src/expat-1.95.2/xmlwf. *** Error code 1 Stop in /usr/local/src/expat-1.95.2 but when I try to install 1.95.1 it installs fine. So I assume it's a bug in 1.95.2 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-27 13:39 Message: Logged In: NO I got a same error! But after I used gmake and it is done! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=493466&group_id=10127 From noreply@sourceforge.net Thu Dec 27 16:21:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 27 16:21:02 2001 Subject: [ expat-Bugs-497193 ] xmlparse.c compile failure on Windows Message-ID: Bugs item #497193, was opened at 2001-12-27 16:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=497193&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Greg Stein (gstein) Summary: xmlparse.c compile failure on Windows Initial Comment: I encountered the following error while trying to build PyXML-0.7.0 from source on Windows 2000, with Python 2.1.1 installed. I didn't get this error when trying to build under Python 2.2. I am using Visual C 98. building '_xmlplus.parsers.pyexpat' extension creating build\temp.win32-2.1 creating build\temp.win32-2.1\Release C:\_Apps\VisualC\VC98 \Bin\cl.exe /c /nologo /Ox /MD /W3 /GX -DHAVE_EXPAT_H - DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 - Iextensions/expat/lib -IC:\Python21 \Include /Tcextensions/pyexpat.c /Fobuild\temp.win32- 2.1\Release\pyexpat.obj pyexpat.c C:\_Apps\VisualC\VC98 \Bin\cl.exe /c /nologo /Ox /MD /W3 /GX -DHAVE_EXPAT_H - DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 - Iextensions/expat/lib -IC:\Python21 \Include /Tcextensions/expat/lib/xmlparse.c /Fobuild\te mp.win32-2.1\Release\xmlparse.obj xmlparse.c extensions/expat/lib/xmlparse.c(1329) : error C2143: syntax error : missing ';' before 'constant' extensions/expat/lib/xmlparse.c(1329) : error C2115: 'return' : incompatible types error: command 'cl.exe' failed with exit status 2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=497193&group_id=10127 From noreply@sourceforge.net Thu Dec 27 16:23:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu Dec 27 16:23:13 2001 Subject: [ expat-Bugs-497193 ] xmlparse.c compile failure on Windows Message-ID: Bugs item #497193, was opened at 2001-12-27 16:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=497193&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Greg Stein (gstein) Summary: xmlparse.c compile failure on Windows Initial Comment: I encountered the following error while trying to build PyXML-0.7.0 from source on Windows 2000, with Python 2.1.1 installed. I didn't get this error when trying to build under Python 2.2. I am using Visual C 98. building '_xmlplus.parsers.pyexpat' extension creating build\temp.win32-2.1 creating build\temp.win32-2.1\Release C:\_Apps\VisualC\VC98 \Bin\cl.exe /c /nologo /Ox /MD /W3 /GX -DHAVE_EXPAT_H - DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 - Iextensions/expat/lib -IC:\Python21 \Include /Tcextensions/pyexpat.c /Fobuild\temp.win32- 2.1\Release\pyexpat.obj pyexpat.c C:\_Apps\VisualC\VC98 \Bin\cl.exe /c /nologo /Ox /MD /W3 /GX -DHAVE_EXPAT_H - DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 - Iextensions/expat/lib -IC:\Python21 \Include /Tcextensions/expat/lib/xmlparse.c /Fobuild\te mp.win32-2.1\Release\xmlparse.obj xmlparse.c extensions/expat/lib/xmlparse.c(1329) : error C2143: syntax error : missing ';' before 'constant' extensions/expat/lib/xmlparse.c(1329) : error C2115: 'return' : incompatible types error: command 'cl.exe' failed with exit status 2 ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2001-12-27 16:22 Message: Logged In: YES user_id=371366 Sorry; I meant to post this to the PyXML project. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110127&aid=497193&group_id=10127