Date: Fri, 19 Mar 2004 00:04:00 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 318 ************************************************** Thursday 18 March 2004 Number 318 ************************************************** Subjects for today 1 Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) : Knut Stange Osmundsen 2 Re: GCC 3.2.2 Beta 4 : Dave and Natalie" 3 Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) : Stefan Neis 4 Make error : John Poltorak 5 [wxOS2] : Dave Webster 6 RSYNC 2.6.0 : John Poltorak 7 Re: Make error : Andreas Buening 8 Re: Make error : John Poltorak 9 Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) : Knut St. Osmundsen" 10 Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) : Franz Bakan" 11 Re: RSYNC 2.6.0 : Steven Levine" 12 Re: Make error : Andreas Buening 13 Re: Make error : John Poltorak 14 Python & /dev/null : John Poltorak 15 Re: Python & /dev/null : Steve Wendt" 16 Re: Python & /dev/null : Sebastian Wittmeier" 17 Re: Python & /dev/null : John Poltorak **= Email 1 ==========================** Date: Wed, 17 Mar 2004 16:29:08 +0100 From: Knut Stange Osmundsen Subject: Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) Franz Bakan wrote: > Hi, > > Trying to compile gnuplot (the current CVS) with Beta 4: > > The following problems occur: > > 1. PATH_MAX and MAXPATHLEN #defines are not found. > > After adding these defines manually I get gnuplot.exe compiled. MAXPATHLEN is defined in at least three headers. PATH_MAX is defined in sys/syslimits.h which may depending of the mode be included by limits.h. > > 2. but the build-process for gnupmdrv.exe fails with: > > [G:\Dev\gcc\v3.2.2\src\gnuplot\src]make -f ..\config\makefile.os2 > gcc -s -Zmt -Zcrtdll -Zbsd-signals -Zomf -o gnupmdrv.exe > os2\gnupmdrv.obj os2\gclient.obj os2\print.obj os2\dialogs.obj > gpexecute.obj os2\gnupmdrv.res os2\gnupmdrv.def > > gcc: unrecognized option `-Zbsd-signals' At present there is no signal style options (-Zbsd-signals, -Zsysv-signals) because the current LIBC doesn't have such features yet. I'm going reworking the signal code in LIBC soon. > weakld: error: Unresolved symbol (UNDEF) '_fcloseall'. > weakld: info: The symbol is referenced by: > G:\Dev\gcc\v3.2.2\src\gnuplot\src\os2\gnupmdrv.obj > Ignoring unresolved externals reported from weak prelinker. > G:\Dev\gcc\v3.2.2\src\gnuplot\src\os2\gnupmdrv.def(1) : warning > LNK4072: changing application type from WINDOWCOMPAT to WINDOWAPI > G:\Dev\gcc\v3.2.2\src\gnuplot\src\os2\gnupmdrv.def(8) : warning > LNK4087: The obsolete keyword HEAPSIZE is ignored ilink is complaining about your def file. Never seen the first warning before btw. > G:\Dev\gcc\v3.2.2\src\gnuplot\src\os2\gnupmdrv.obj(gnupmdrv.obj) : \\ > error LNK2029: "_fcloseall" : unresolved external fcloseall() is non standard thus we do like IBM VisualAge and only provide the underscored version, _fcloseall(). > How to resolve this? s/fcloseall/_fcloseall/ Kind Regards, knut **= Email 2 ==========================** Date: Wed, 17 Mar 2004 08:01:39 -0800 From: "Dave and Natalie" Subject: Re: GCC 3.2.2 Beta 4 On Wed, 17 Mar 2004 00:35:43 +0100, Knut St. Osmundsen wrote: >Oops. I'll fix that. >Note. That we're actually shipping that sys/ipc.h too :-) > >> I changed the above to >> #ifndef _KEY_T_DECLARED && ifndef _KEY_T >You should change it to: >#if !defined(_KEY_T_DECLARED) && !defined(_KEY_T) >#define _KEY_T This change still left me with the conflict > >> to get around this. Don't know if there is a better solution or > > perhaps its ipc.h that should be changed > >The right solution is that I fix sys/types.h and look very closely >at the ipc implementation you've pointed me to before adding those >APIS to LIBC. Well I merged the shm ipc.h with yours (seemed to be just constants) and rebuilt shm as a static library. Seems like the best solution. Dave **= Email 3 ==========================** Date: Wed, 17 Mar 2004 18:21:37 +0100 (CET) From: Stefan Neis Subject: Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) On Wed, 17 Mar 2004, Knut Stange Osmundsen wrote: > At present there is no signal style options (-Zbsd-signals, > -Zsysv-signals) because the current LIBC doesn't have such features yet. > I'm going reworking the signal code in LIBC soon. Are details available on how signals are handled currently? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Wed, 17 Mar 2004 18:01:53 +0000 From: John Poltorak Subject: Make error I've recently being trying to build the latest version of Zope, which is a Python based web application server - and pretty neat it is too. I did find, after much trial and error, that I could build it, but only by using different versions of Make for different stages. A successful build was achieved using v3.79.1 initially, followed by v3.76.1 when running 'make install'. Could anyone just check that the same occurs for them? The source is available here:- http://zope.org/Products/Zope/2.7.0/Zope-2.7.0.tgz Unfortunately, I found that Make 3.81RC1-R3 was unable to run the whole show either... -- John **= Email 5 ==========================** Date: Wed, 17 Mar 2004 13:59:04 -0600 From: Dave Webster Subject: [wxOS2] I notice the offending thread.cpp has not been fixed? Still cannot compile the OS/2 port. Since I'm not too keen on the new event processing I'm not able to fix this with any confidence right now. **= Email 6 ==========================** Date: Wed, 17 Mar 2004 20:07:56 +0000 From: John Poltorak Subject: RSYNC 2.6.0 RSYNC 2.6.0 has been out for some weeks now. I wonder if anyone has managed to build it... I also wondered if it would be possible to enhance it to able to add EAs so that it could be used to keep OS/2 systems in synch. -- John **= Email 7 ==========================** Date: Wed, 17 Mar 2004 22:33:14 +0100 From: Andreas Buening Subject: Re: Make error John Poltorak wrote: > > I've recently being trying to build the latest version of Zope, which is a > Python based web application server - and pretty neat it is too. > > I did find, after much trial and error, that I could build it, but only by > using different versions of Make for different stages. A successful build > was achieved using v3.79.1 initially, followed by v3.76.1 when running > 'make install'. Strange. What error messages did you get? Bye, Andreas **= Email 8 ==========================** Date: Wed, 17 Mar 2004 21:58:32 +0000 From: John Poltorak Subject: Re: Make error On Wed, Mar 17, 2004 at 10:33:14PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > I've recently being trying to build the latest version of Zope, which is a > > Python based web application server - and pretty neat it is too. > > > > I did find, after much trial and error, that I could build it, but only by > > using different versions of Make for different stages. A successful build > > was achieved using v3.79.1 initially, followed by v3.76.1 when running > > 'make install'. > > Strange. What error messages did you get? Using Make 3.76.1 it failed very early:- Zope-2.7.0 ../configure --with-python=/usr/bin/python --ignore-largefile Using Python interpreter at /usr/bin/python Configuring Zope installation - Zope top-level binary directory will be /opt/Zope-2.7. - Makefile written. Next, run make. make "U:\USR\BIN\PYTHON.EXE" "U:/unixos2/workdir/Zope-2.7.0/setup.py" \ build --build-base="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3" --build-lib="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-lib" --build-scripts="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-scripts" --build-temp="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-temp" make: U:USRBINPYTHON.EXE: Command not found Using Make 3.79.1 it works successfully while building the default target, but fails when building 'install' The previous make succeeds at this point. Here is the point where it fails:- "U:\USR\BIN\PYTHON.EXE" "U:/unixos2/workdir/Zope-2.7.0/setup.py" \ build --build-base="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3" --build-lib="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-lib" --build-scripts="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-scripts" --build-temp="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-temp" running build running build_py running build_ext running build running build_py running build running build_scripts "U:\USR\BIN\PYTHON.EXE" "U:/unixos2/workdir/Zope-2.7.0/setup.py" install \ --home="/opt/Zope-2.7" --build-base="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3" --build-lib="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-lib" --build-scripts="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-scripts" --build-temp="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-temp" invalid command name '' make: *** [install] Error 1 Here is the Makefile:- # Zope2 build and install Makefile. # We do as much as possible in Python in order to avoid needing to # learn autoconf or some other awful thing. ;-) NAME=Zope MAJOR_VERSION=2.7 MINOR_VERSION=0 RELEASE_TAG=b3 PACKAGE_NAME=${NAME}-${MAJOR_VERSION}.${MINOR_VERSION}-${RELEASE_TAG} PYTHON="U:\USR\BIN\PYTHON.EXE" TMPDIR=/tmp PREFIX=/opt/Zope-2.7 BASE_DIR=U:/unixos2/workdir/Zope-2.7.0 BUILD_BASE=U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3 DISTUTILS_OPTS= INSTALL_FLAGS= TESTOPTS=-v BUILD_FLAGS=--build-base="${BUILD_BASE}" \ --build-lib="${BUILD_BASE}/build-lib" \ --build-scripts="${BUILD_BASE}/build-scripts"\ --build-temp="${BUILD_BASE}/build-temp" RM=rm -f RMRF=rm -rf FIND=find XARGS=xargs CD=cd LN=ln -sfn CP=cp TAR=tar MKDIR=mkdir -p ..PHONY : clean install uninstall instance untestinst testinst build unbuild ..PHONY : default # default: The default step (invoked when make is called without a target) default: build at echo at echo Zope built. Next, do \'make install\' \(or \'make instance\' at echo to run a Zope instance directly from the build directory\). at echo # build: Do whatever 'setup.py build' implies build: ${PYTHON} "${BASE_DIR}/setup.py" \ ${DISTUTILS_OPTS} build ${BUILD_FLAGS} # unbuild: Remove the build directory (undo the make build step) unbuild: ${RMRF} ${BUILD_BASE} # install: Install a software home. # # Note: Unless ${PREFIX}/bin already has a 'python', symlink the # "canonical" Python for this Zope into it. install: build ${PYTHON} "${BASE_DIR}/setup.py" ${DISTUTILS_OPTS} install \ --home="${PREFIX}" ${BUILD_FLAGS} ${INSTALL_FLAGS} [ -f ${PREFIX}/bin/python ] || ${LN} ${PYTHON} ${PREFIX}/bin/python at echo at echo Zope binaries installed successfully. at echo Now run \'${PREFIX}/bin/mkzopeinstance.py\' # uninstall: Uninstall a software home. uninstall: ${RMRF} "${PREFIX}" # inplace: Install a software home into to the source directory. # # Note: We used to run 'build_ext -i' for 'inplace', but that was # suboptimal because it had a tendency to try to rebuild all of the # (possibly already-built) extensions that might be built during a # previous 'make' step. built_ext doesn't understand '--build-base' # and friends so we can't stop it from doing this easily. So instead, # we rely on the stock install step and name the prefix as the current # directory. This is a little less efficient than just building the # extensions because it also compiles bytecode, but it's more intuitive and # less expensive in the common case than letting distutils # potentially rebuild the binaries when we've done that already. inplace: PREFIX=${BASE_DIR} inplace: install # instance: Do an inplace build and create an instance home in the resulting # software home. instance: inplace ${PYTHON} "${BASE_DIR}/bin/mkzopeinstance.py" ${MKZ_FLAGS} \ --dir="${BASE_DIR}" # uninstance: Remove the instance files made by make instance (w/ prejudice) uninstance: ${RMRF} "${BASE_DIR}/bin" ${RMRF} "${BASE_DIR}/etc" ${RMRF} "${BASE_DIR}/log" ${RMRF} "${BASE_DIR}/var" ${RMRF} "${BASE_DIR}/Products" # testinst: Perform an inplace build and create an instance home in the # resulting software home without asking questions. Useful when # performing automated testing. testinst: MKZ_FLAGS=--user=admin:admin testinst: instance # test: Do an inplace build and run the Zope test suite. test: inplace ${PYTHON} "${BASE_DIR}/test.py" ${TESTOPTS} # clean: Delete the build files and any binaries/bytecode files in # the source directory for good measure. clean: unbuild ${FIND} "${BASE_DIR}" \ -name '*.py[co]' -o -name '*.so' -o -name '*.o' | ${XARGS} ${RM} # sdist: Create a source distribution file (implies clobber). # sdist: clobber sdist_tgz # sdist_tgz: Create a tgz archive file as a source distribution. # sdist_tgz: echo -n "Zope ${MAJOR_VERSION}.${MINOR_VERSION}-${RELEASE_TAG}" >\ "${BASE_DIR}/lib/python/version.txt" ${MKDIR} ${TMPDIR} ${CD} ${TMPDIR} && ${LN} ${BASE_DIR} ${PACKAGE_NAME} && \ ${TAR} czfh ${BASE_DIR}/${PACKAGE_NAME}.tgz ${PACKAGE_NAME} \ --exclude=${PACKAGE_NAME}.tgz\ --exclude=CVS \ --exclude=.cvsignore \ --exclude=makefile \ --exclude=*~ \ --exclude=.#* ${RM} "${BASE_DIR}/lib/python/version.txt" ${RMRF} ${TMPDIR}/${PACKAGE_NAME} # clobber: Make the source tree 'pristine' again. clobber: clean uninstance > > Bye, > Andreas -- John **= Email 9 ==========================** Date: Wed, 17 Mar 2004 23:11:46 +0100 From: "Knut St. Osmundsen" Subject: Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) Stefan Neis wrote: > On Wed, 17 Mar 2004, Knut Stange Osmundsen wrote: > > >>At present there is no signal style options (-Zbsd-signals, >>-Zsysv-signals) because the current LIBC doesn't have such features yet. >>I'm going reworking the signal code in LIBC soon. > > > Are details available on how signals are handled currently? Only sources. I'm trying to figure them out myself before I embark on a rewrite. Kind Regards, knut **= Email 10 ==========================** Date: Thu, 18 Mar 2004 01:18:08 +0100 (CET) From: "Franz Bakan" Subject: Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) On Wed, 17 Mar 2004 16:29:08 +0100, Knut Stange Osmundsen wrote: >> 1. PATH_MAX and MAXPATHLEN #defines are not found. >> >> After adding these defines manually I get gnuplot.exe compiled. > >MAXPATHLEN is defined in at least three headers. >PATH_MAX is defined in sys/syslimits.h which may depending of the mode >be included by limits.h. Yes, seems that sys/syslimits.h gets not included because __POSIX_VISIBLE is not defined. Not even as '0' > > weakld: error: Unresolved symbol (UNDEF) '_fcloseall'. >> How to resolve this? >s/fcloseall/_fcloseall/ This helped. Now gnupmdrv.exe gets built. The problem now is that gnuplot.exe refuses to spwawn gnupmdrv.exe I get: G N U P L O T Version 3.8k patchlevel 2 .... Terminal type set to 'pm' gnuplot> plot x plot x Cannot spawn gnupmdrv.exe ! Source (pm.trm) is: .... spawnmode = P_SESSION | P_DEFAULT; if (PM_optargs != 0) spawnmode |= P_UNRELATED; pid = spawnl(spawnmode, PM_path, "GnuplotPM", tempname, PM_opts, NULL); if (pid == -1) { fputs("Cannot spawn gnupmdrv.exe !\n", stderr); exit(3); } .... But gnupmdrv.exe starts fine from commandline. and also gnuplot.exe works with other terminals. Regards Franz **= Email 11 ==========================** Date: Wed, 17 Mar 2004 20:10:47 -0800 From: "Steven Levine" Subject: Re: RSYNC 2.6.0 In <20040317200756.S9727 at warpix.org>, on 03/17/04 at 08:07 PM, John Poltorak said: >I also wondered if it would be possible to enhance it to able to add EAs >so that it could be used to keep OS/2 systems in synch. The code to copy EAs is simple enough. The logic to copy only the EAs that will not cause trouble is a bit harder to design. For example, copying .CLASSINFO EAs from on system to another is not always going to work the way one expects. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 12 ==========================** Date: Thu, 18 Mar 2004 10:08:31 +0100 From: Andreas Buening Subject: Re: Make error John Poltorak wrote: > Using Make 3.76.1 it failed very early:- [snip] > make: U:USRBINPYTHON.EXE: Command not found I guess, make 3.76.1 tries to simulate Unix-backslash-handling and obviously fails while 3.79.1 uses plain cmd which accidently works. > Using Make 3.79.1 it works successfully while building the default target, > but fails when building 'install' The previous make succeeds at this > point. Here is the point where it fails:- [snip] > "U:\USR\BIN\PYTHON.EXE" "U:/unixos2/workdir/Zope-2.7.0/setup.py" install \ > --home="/opt/Zope-2.7" --build-base="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3" --build-lib="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-lib" --build-scripts="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-scripts" --build-temp="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-temp" > invalid command name '' > make: *** [install] Error 1 And for the install target it's vice versa: 3.79.1 fails, 3.76.1 succeeds. > Here is the Makefile:- [snip] SHELL = /bin/sh should do the job. Bye, Andreas **= Email 13 ==========================** Date: Thu, 18 Mar 2004 09:46:12 +0000 From: John Poltorak Subject: Re: Make error On Thu, Mar 18, 2004 at 10:08:31AM +0100, Andreas Buening wrote: > > And for the install target it's vice versa: 3.79.1 fails, 3.76.1 > succeeds. That's right. A combination of the two manages a successfull build. > > > Here is the Makefile:- > > [snip] > > SHELL = /bin/sh > > should do the job. Unusually, this does not get set in the Makefile, so I set it up in the environment beforehand but it doesn't seem to make any difference. I wish you would have a look at UX2BS sometime and you would see exactly where it or any other app fails. All I have to do is run 'build zope' and it automatically creates a log file. With such a standard environment it should be possible to easily reproduce any errors. UX2BS is a completely isolated shell and does not replace an existing build environment so there is no danger of it breaking a working system. > Bye, > Andreas -- John **= Email 14 ==========================** Date: Thu, 18 Mar 2004 10:39:19 +0000 From: John Poltorak Subject: Python & /dev/null When running a Python program on OS/2 which attempts to write to /dev/null, it stops with an IOError - No such file: 'nul:'. What can I do about it? -- John **= Email 15 ==========================** Date: Thu, 18 Mar 2004 02:58:22 -0800 (PST) From: "Steve Wendt" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 10:39:19 +0000, John Poltorak wrote: >When running a Python program on OS/2 which attempts to write to >/dev/null, it stops with an IOError - No such file: 'nul:'. > >What can I do about it? Figure out where 'nul:' comes from and replace it with 'nul' probably. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 16 ==========================** Date: Thu, 18 Mar 2004 12:59:53 +0100 (CET) From: "Sebastian Wittmeier" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 02:58:22 -0800 (PST), Steve Wendt wrote: >On Thu, 18 Mar 2004 10:39:19 +0000, John Poltorak wrote: > >>When running a Python program on OS/2 which attempts to write to >>/dev/null, it stops with an IOError - No such file: 'nul:'. >> >>What can I do about it? > >Figure out where 'nul:' comes from and replace it with 'nul' probably. Shouldn't the replacement logic be in the file API? Sebastian **= Email 17 ==========================** Date: Thu, 18 Mar 2004 12:12:01 +0000 From: John Poltorak Subject: Re: Python & /dev/null On Thu, Mar 18, 2004 at 12:59:53PM +0100, Sebastian Wittmeier wrote: > On Thu, 18 Mar 2004 02:58:22 -0800 (PST), Steve Wendt wrote: > > >On Thu, 18 Mar 2004 10:39:19 +0000, John Poltorak wrote: > > > >>When running a Python program on OS/2 which attempts to write to > >>/dev/null, it stops with an IOError - No such file: 'nul:'. > >> > >>What can I do about it? > > > >Figure out where 'nul:' comes from and replace it with 'nul' probably. > > Shouldn't the replacement logic be in the file API? The actual code causing the problem is from Zope:- if not self.cfg.debug_mode: # prevent startup messages from going to stderr if we're not # in debug mode if os.path.exists('/dev/null'): # unix devnull = '/dev/null' else: # win32 devnull = 'nul:' self.startup_handler = StartupHandler(open(devnull, 'w')) After some fiddling it looks as though it would work if devnull was defined as 'dev/null' but no such file exists on OS/2... > Sebastian -- John