Date: Sun, 23 Jan 2005 00:04:19 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 510 ************************************************** Saturday 22 January 2005 Number 510 ************************************************** Subjects for today 1 Re: Building PDKSH using latest gcc 3.3.5 : Knut St. Osmundsen" 2 Re: coreutils with gcc 3.3.5 b4 : Knut St. Osmundsen" 3 Re: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 4 Re: Building PDKSH using latest gcc 3.3.5 : John Poltorak 5 Re: coreutils with gcc 3.3.5 b4 : Dave Yeo" 6 Re: coreutils with gcc 3.3.5 b4 : Dave Yeo" 7 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 8 Re: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 9 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Yuri Dario" 10 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Dave Yeo" 11 Re: Xfree86 with libc (was Re: Perl with GCC 3.3.5 B4) : Dave Yeo" 12 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Steve Wendt 13 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Fri, 21 Jan 2005 14:08:41 +0100 From: "Knut St. Osmundsen" Subject: Re: Building PDKSH using latest gcc 3.3.5 Hi John, do you have an url for the sources you use when building it? I will try it out when I have time... Kind Regards, knut John Poltorak wrote: > > Has anyone tried building PDKSH using the latest release of gcc 3.3.5? > > **= Email 2 ==========================** Date: Fri, 21 Jan 2005 14:22:17 +0100 From: "Knut St. Osmundsen" Subject: Re: coreutils with gcc 3.3.5 b4 Dave Yeo wrote: > On Thu, 20 Jan 2005 14:58:09 -0700, Andy Willis wrote: > > >> I ran configure and edited the makefile in src to add -Zomf to >> cflags and -lsocket to hostname ldadd. I also had to add for 5.3.0 >> #include in lib\chdir-long.c or you could >> define PATH_MAX to 260 which it is in syslimits.h. > > I wonder where PATH_MAX is usually defined, I've had to add > a few times now. That's a bit weird. We're defining PATH_MAX in sys/syslimits.h like BSD. We have the same limits.h as BSD, which at the end includes sys/syslimits.h if the sources aren't strict ANSI or C99. Are coreutils now built with -ansi perhaps? > Easier way to add -lsocket is to set LIBS=-lsocket before running > configure. Seems that really hostname() should be in libc not > libsocket since its in unistd.h. OS/2 is pretty much alone in having a libsocket. In version 0.7 or 0.8 it will be attemted moved into libc, but that does require a bit of work. There are two reasons why it's difficult to move it into LIBC, 1) there are two interface versions (BSD43 and BSD44, or tcpip v4.0 and v4.1+), 2) some people doesn't have tcpip installed at all. Kind Regards, knut **= Email 3 ==========================** Date: Fri, 21 Jan 2005 16:08:09 +0100 (CET) From: Stefan.Neis at t-online.de Subject: Re: coreutils with gcc 3.3.5 b4 Knut St. Osmundsen schrieb: > > Easier way to add -lsocket is to set LIBS=-lsocket > > before running configure. Seems that really > > hostname() should be in libc not > > libsocket since its in unistd.h. I assume, that function should be gethostname? > OS/2 is pretty much alone in having a libsocket. The other one that comes to my mind is Solaris (and probably older BSD version/SunOS versions, that would be a good explanation how it got into Solaris ...). And it seems to totally agree with you, in fact, where OS/2 requires "-lsocket", Solaris even requires "-lsocket -lnsl" and gethostname is even in the latter (even more obscure one) of those libs. It's surprising to see GNU software which does not actively test for the need of "-lsocket"... Maybe it's testing for "-lnsl" only, though that would still be the first one I've ever seen to do that ... Regards, Stefan **= Email 4 ==========================** Date: Fri, 21 Jan 2005 15:57:55 +0000 From: John Poltorak Subject: Re: Building PDKSH using latest gcc 3.3.5 On Fri, Jan 21, 2005 at 02:08:41PM +0100, Knut St. Osmundsen wrote: > Hi John, > > do you have an url for the sources you use when building it? I will try > it out when I have time... The original source is here:- ftp://ftp.cs.mun.ca/pub/pdksh/pdksh-5.2.14.tar.gz I think it is what IBM called 'stabilised' which I don't mind at all as long as it does the job it was intended to. It actually includes an OS/2 Makefile in the os2 directory. You also need to apply three patches which are included in IlyaZ's latest port:- http://math.berkeley.edu/~ilya/software/os2/pdksh-5.2.14-bin-2.zip To build it, I normally run something like:- patch Kind Regards, > knut > > John Poltorak wrote: > > > > Has anyone tried building PDKSH using the latest release of gcc 3.3.5? > > > > -- John **= Email 5 ==========================** Date: Fri, 21 Jan 2005 09:09:09 -0800 From: "Dave Yeo" Subject: Re: coreutils with gcc 3.3.5 b4 On Fri, 21 Jan 2005 14:22:17 +0100, Knut St. Osmundsen wrote: >> I wonder where PATH_MAX is usually defined, I've had to add >> a few times now. > >That's a bit weird. We're defining PATH_MAX in sys/syslimits.h like BSD. >We have the same limits.h as BSD, which at the end includes >sys/syslimits.h if the sources aren't strict ANSI or C99. Are coreutils >now built with -ansi perhaps? Hmm, one of the programs I had to add sys/syslimits.h to was bsd_tar (actually libarchive) which is sopposed to be the next generation of tar for the bsds. (__FBSDID FreeBSD in the source) No -ansi and it does include Dave **= Email 6 ==========================** Date: Fri, 21 Jan 2005 09:09:56 -0800 From: "Dave Yeo" Subject: Re: coreutils with gcc 3.3.5 b4 On Fri, 21 Jan 2005 16:08:09 +0100 (CET), Stefan.Neis at t-online.de wrote: >Knut St. Osmundsen schrieb: > >> > Easier way to add -lsocket is to set LIBS=-lsocket >> > before running configure. Seems that really >> > hostname() should be in libc not >> > libsocket since its in unistd.h. > >I assume, that function should be gethostname? Actually gethostid. Memory is going > >> OS/2 is pretty much alone in having a libsocket. > >The other one that comes to my mind is Solaris >(and probably older BSD version/SunOS versions, > that would be a good explanation how it got into > Solaris ...). >And it seems to totally agree with you, in fact, where >OS/2 requires "-lsocket", Solaris even requires >"-lsocket -lnsl" and gethostname is even in the >latter (even more obscure one) of those libs. > It's surprising to see GNU software which does >not actively test for the need of "-lsocket"... >Maybe it's testing for "-lnsl" only, though that >would still be the first one I've ever seen to >do that ... This came up in an email exchange with Jorg Schilling (cdwriter, star, etc) where I mentioned needing to add -lsocket to build star. His answer was quote Loosk like a bug (inconsistency) in this suite. Things that are in unistd.h should be also implemented in libc. /quote Interestingly looking at his readmes solaris seems to be his favorite platform. Dave **= Email 7 ==========================** Date: Fri, 21 Jan 2005 18:26:19 +0100 (CET) From: Stefan.Neis at t-online.de Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 Hi, While talking about all those programs that expect the shell to expand the arguments.... Does anyone know if Innotek's library provides something like EMX' _wildcard function? And if so, would it be a possible/reasonable to add another startup stub (similar to crt0.o or whatever it's name in the current port) which automatically calls it prior to passing control to user's main? And link that in with a specific flag? That way, another one of the more time consuming porting problems could be handled "automatically", i.e. if you're compiling some "Unix" software simply pass that special flag that selects the wildcard- expanding version of the startup module to configure and be done with it, no need to submit ugly source changes. Regards, Stefan **= Email 8 ==========================** Date: Fri, 21 Jan 2005 18:32:00 +0100 (CET) From: Stefan.Neis at t-online.de Subject: Re: coreutils with gcc 3.3.5 b4 Dave Yeo schrieb: > quote > Things that are in unistd.h should be also implemented in > libc. > /quote Hm, I keep learning new things ... ;-) > Interestingly looking at his readmes solaris seems to be > his favorite platform. Apparently gethostid _is_ defined in libc on Solaris - and gethostname seems to be defined both in libc (don't know why I missed that one earlier) _and_ in libnsl - which doesn't seem to be a really good idea... Regards, Stefan **= Email 9 ==========================** Date: Fri, 21 Jan 2005 18:56:52 +0100 (CET) From: "Yuri Dario" Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 Hi, >Does anyone know if Innotek's library provides >something like EMX' _wildcard function? yes it does; also _response is supported. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 10 ==========================** Date: Fri, 21 Jan 2005 10:05:28 -0800 From: "Dave Yeo" Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 On Fri, 21 Jan 2005 18:26:19 +0100 (CET), Stefan.Neis at t-online.de wrote: > Hi, > >While talking about all those programs that expect >the shell to expand the arguments.... >Does anyone know if Innotek's library provides >something like EMX' _wildcard function? Yes it does >And if so, would it be a possible/reasonable to >add another startup stub (similar to crt0.o or >whatever it's name in the current port) which >automatically calls it prior to passing control >to user's main? And link that in with a specific >flag? This is how KUR did it with his fileutils port. I had problems with this and ended up moving the code from the startup stub to the C files. Can't remember what the problem was offhand, will look it up. >That way, another one of the more time consuming >porting problems could be handled "automatically", >i.e. if you're compiling some "Unix" software simply >pass that special flag that selects the wildcard- >expanding version of the startup module to configure >and be done with it, no need to submit ugly source >changes. Of course problems can arise when using a shell that also expands wildcards. Dave **= Email 11 ==========================** Date: Fri, 21 Jan 2005 10:57:47 -0800 From: "Dave Yeo" Subject: Re: Xfree86 with libc (was Re: Perl with GCC 3.3.5 B4) On Fri, 21 Jan 2005 01:30:41 -0500, Henry Sobotka wrote: >Dave Yeo wrote: >> >> I wonder if it would better to go with _foo=foo or foo=_foo or just plain old foo. > >As I recall, the grammar is externalname=internalname so it has to be >_foo=foo if the program you're linking from wants _foo. Here it is actually LD that wants _foo instead of foo. Anyways I changed makedef.cmd to output foo=_foo and LD seems happy. Maybe this gothru will actually produce a working XFree86. Unluckily it takes about 12 hrs for the build to happen here. Dave **= Email 12 ==========================** Date: Fri, 21 Jan 2005 11:49:06 -0800 (PST) From: Steve Wendt Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 On Fri, 21 Jan 2005, Dave Yeo wrote: > Of course problems can arise when using a shell that also expands wildcards. If the shell has already done it, then the function would just do nothing. **= Email 13 ==========================** Date: Sat, 22 Jan 2005 13:20:59 +0100 From: Stefan.Neis at t-online.de Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 Hi, > > Of course problems can arise when using a shell that also expands wildcards. > > If the shell has already done it, then the function would just do nothing