From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 28 Mar 2003 05:00:41 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 84 ************************************************** Thursday 27 March 2003 Number 84 ************************************************** Subjects for today 1 Re: ulsemx.zip : Henry Sobotka 2 conflicting types for `_getcwd2' : John Poltorak 3 Re: ld which supports lib prefix : Pete Milne 4 Making PKGs : John Poltorak 5 ulsemx.zip : John Poltorak 6 Re: Building Python : Dave and Natalie" **= Email 1 ==========================** Date: Fri, 28 Mar 2003 09:31:47 -0500 From: Henry Sobotka Subject: Re: ulsemx.zip John Poltorak wrote: > > I have come across several references to ulsemx.zip over the last few > days, but have never heard of this archive before. > > Can anyone tell me what it is? Is it based on some Unix app? It's headers and import libraries for accessing the OS/2 Unicode API with EMX that John Fairhurst put together about five years ago because we needed them for building Mozilla. Between Andy adding the same functionality to the gcc 3.x packages and distribution of the Warp toolkit with current versions of OS/2, its usefulness is more limited nowadays. h~ **= Email 2 ==========================** Date: Fri, 28 Mar 2003 10:45:12 +0000 From: John Poltorak Subject: conflicting types for `_getcwd2' I've been trying to build the latest Sendmail on OS/2 and get these errors:- cp ../../include/sm/os/sm_os_os2.h sm_os.h gcc -O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s -I. -I../../include -Zomf -Zmt -D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -D_EMX_CRT_REV_=64 -c -o assert.o assert.c In file included from assert.c:20: u:\unixos2\emx\include\stdlib.h:229: conflicting types for `_getcwd2' u:\unixos2\emx\include\stdlib.h:163: previous declaration of `_getcwd2' In file included from assert.c:21: u:\unixos2\emx\include\unistd.h:99: conflicting types for `_getcwd2' u:\unixos2\emx\include\stdlib.h:229: previous declaration of `_getcwd2' make[1]: *** [assert.o] Error 1 make[1]: Leaving directory `U:/unixos2/workdir/sendmail-8.12.8/obj.OS-2.2.i386/libsm' make: *** [/unixos2/workdir/sendmail-8.12.8/obj.OS-2.2.i386/libsm/libsm.a] Error 2 Is there anything I can do about this? -- John **= Email 3 ==========================** Date: Fri, 28 Mar 2003 11:09:55 +0000 From: Pete Milne Subject: Re: ld which supports lib prefix John Poltorak wrote: > > If so, how do I grab it? I just can't get CVS set up properly and need > some help setting it up. Can it work through a proxy server? > > > John Have you tried NOSA client from Netlabs? Although it's designed for accessing the netlabs cvs repository, I believe it's possible to use it for any host. (that's what it says in the inf file, anyway.) I found it a painless way to set up CVS and access the Xworkplace source, but can't claim much experience as I haven't needed/had time to download any other source either from netlabs or elsewhere since then. Pete **= Email 4 ==========================** Date: Fri, 28 Mar 2003 12:07:43 +0000 From: John Poltorak Subject: Making PKGs The UnixOS/2 Build System seems to be working pretty well now for quite a number of apps. What I would like to do in the future is to create PKGs for installation via PKGTOOL. What I would like to have is some program which build PKGs. Does anyone knoe if such a program exists? -- John **= Email 5 ==========================** Date: Fri, 28 Mar 2003 12:23:12 +0000 From: John Poltorak Subject: ulsemx.zip I have come across several references to ulsemx.zip over the last few days, but have never heard of this archive before. Can anyone tell me what it is? Is it based on some Unix app? -- John **= Email 6 ==========================** Date: Fri, 28 Mar 2003 19:28:22 -0800 From: "Dave and Natalie" Subject: Re: Building Python On Sat, 29 Mar 2003 09:55:49 +1000 (est), Andrew MacIntyre wrote: >> On my Debian partition it is installed \usr\lib eg >> Directory of L:\usr\lib > >Debian is an exception. > >The vast majority, and Python's default, install in /usr/local/... So your saying that most Linux (& BSD?) distributations install Python in /usr/local? I've got 3 different Linux dists here and they all have Python installed in /usr/lib, at that /usr/local is basically empty on a new install. Exception being Debian which has Directory of L:\usr\local\lib 1-03-03 1:40a 0 . 9-07-02 7:20p 0 .. 1-03-03 1:40a 0 python1.5 7-28-02 6:55a 0 python2.1 Each of which contains an empty site-packages subdir. I always understood that /usr/local was for packages that did not come with the dist. so that if I wanted to build and install python from a tarball then it would go into /usr/local and /usr/local/bin comes before /usr/bin in the $PATH so that my install would override the distributations install. Remember the object of UnixOS2 is to make a distributation, not to add files to an existing distributation. From fhs-2.2 Filesystem HierarchyStandard March 12, 2001 4.9.1 Purpose The /usr/local hierarchy is for use by the system administrator when installing software locally.It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. 25 4.9.2 Requirements The following directories, or symbolic links to directories, must be in /usr/local /usr/local ---Local hierarchy bin Local binaries games Local game binaries include Local C header files lib Local libraries man Local online manuals sbin Local system binaries share Local architecture-independent hierarchy src Local source code No other directories, expect those listed below, may be in /usr/local after first installing a FHS-compliant system. 25. Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.