Date: Thu, 2 Dec 2004 00:04:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 464 ************************************************** Wednesday 01 December 2004 Number 464 ************************************************** Subjects for today 1 Re: Ugly problems with chdrive and mkdir in gcc 3.3.5 : lsunley at mb.sympatico.ca 2 Re: No sys/sysctl.h in GCC 3.3.5 : Knut St. Osmundsen" 3 Re: No sys/sysctl.h in GCC 3.3.5 : John Poltorak 4 Producing a diary from CAL : John Poltorak 5 Re: Ugly problems with chdrive and mkdir in gcc 3.3.5 : Knut St. Osmundsen" 6 Re: More on mkdir : Knut St. Osmundsen" 7 Re: GCC question : Knut St. Osmundsen" 8 Re: Does link do anything : Knut St. Osmundsen" 9 Re: More on mkdir : lsunley at mb.sympatico.ca 10 Re: GCC question : Stefan.Neis at t-online.de 11 Re: No sys/sysctl.h in GCC 3.3.5 : Stefan.Neis at t-online.de 12 Re: No sys/sysctl.h in GCC 3.3.5 : John Poltorak **= Email 1 ==========================** Date: Tue, 30 Nov 2004 07:34:35 -0500 From: lsunley at mb.sympatico.ca Subject: Re: Ugly problems with chdrive and mkdir in gcc 3.3.5 In <200411300724.HAA401.85 at mail.warpix.org>, on 11/30/04 at 08:24 AM, "Yuri Dario" said: >Hi, >>I have discovered that if I use the number value of the drive letter (76 >>for drive L) the chdrive routine in 3.3.5 will change drives. When I use >>the drive number (starting with A = 1) the chdrive 3.3.5 will not work. >are you using libc06b1? chdir2/getdrive were broken in alpha releases. >BTW you can use chdir2 instead of chdir, this will change also current >drive, without adding more code. Yes, I am using libc06b1 I'll try out chdir2 and see how it works. The biggest hit is mkdir not working. Lorne -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 2 ==========================** Date: Tue, 30 Nov 2004 18:28:00 +0100 From: "Knut St. Osmundsen" Subject: Re: No sys/sysctl.h in GCC 3.3.5 John Poltorak wrote: > On Sun, Nov 28, 2004 at 09:23:45PM +0100, Stefan.Neis at t-online.de wrote: > >> Hi, >> >>Sounds like might be trying to access the network adapter on a very low >>level for maximum efficiency. If that's true, you probably can just forget >>about porting that version, even if you use e.g. Posix/2 (which has a >>sys/sysctl.h but at most very limited support for the methods declared in >>there). On that level, OS/2 really is quite different from BSD ... > > > The addition of that header was quite recent - it only happened last year. > v1.77 did not have it. When compiling that version, I get :- > > [S:\]gcc ping.c -lsocket > ping.c: In function `main': > ping.c:625: error: `NOKERNINFO' undeclared (first use in this function) > ping.c:625: error: (Each undeclared identifier is reported only once > ping.c:625: error: for each function it appears in.) > ping.c: In function `finish': > ping.c:1166: error: `NOKERNINFO' undeclared (first use in this function) > ping.c: In function `pr_icmph': > ping.c:1227: error: `ICMP_UNREACH_FILTER_PROHIB' undeclared (first use in > this f > unction) > None of these errors are related to sys/sysctl.h. NOKERNINFO is termios.h. ICMP_UNREACH_FILTER_PROHIB is already there, but since the OS/2 tcpip doesn't support/return it you'll have to make an effort to enable it, i.e. define __USE_LIBC_TCPIP. As for the original question, sys/sysctl.h. Yes, I will make an attempt at merging the latest FreeBSD with the OS/2 tcpip one and implement a few selected operations to make coreutils happier. Since this is a bit of work (getting it all correct and such) and I will be very busy at work for the next months I will not make any promise when this will be done if I have to do it. Kind Regards, knut **= Email 3 ==========================** Date: Tue, 30 Nov 2004 20:00:13 +0000 From: John Poltorak Subject: Re: No sys/sysctl.h in GCC 3.3.5 On Tue, Nov 30, 2004 at 06:28:00PM +0100, Knut St. Osmundsen wrote: > John Poltorak wrote: > > On Sun, Nov 28, 2004 at 09:23:45PM +0100, Stefan.Neis at t-online.de wrote: > None of these errors are related to sys/sysctl.h. > NOKERNINFO is termios.h. ICMP_UNREACH_FILTER_PROHIB is already there, > but since the OS/2 tcpip doesn't support/return it you'll have to make > an effort to enable it, i.e. define __USE_LIBC_TCPIP. > > As for the original question, sys/sysctl.h. Yes, I will make an attempt > at merging the latest FreeBSD with the OS/2 tcpip one and implement a > few selected operations to make coreutils happier. Since this is a bit > of work (getting it all correct and such) and I will be very busy at > work for the next months I will not make any promise when this will be > done if I have to do it. Since I've only come across one program which uses sys/sysctl.h so far then it can go on the back burner and more important issues can be addressed. It is heartening that a relatively recent version of BSD PING can be built straight out of the box using the latest gcc. It will be interesting to see how much more of IBM's TCP/IP stack can be replaced with open source code. What are considered to be the most important programs within MPTN? arp, ifconfig, ping, tracerte, host, hostid, hostname?... Could they all be built directly from *BSD code? > Kind Regards, > knut -- John **= Email 4 ==========================** Date: Tue, 30 Nov 2004 20:05:51 +0000 From: John Poltorak Subject: Producing a diary from CAL I have been think about the possibility of creating a diary for myself but am not sure how to go about it. My initial thinking is to create some raw data files which can be subsequently formatted and printed via something like Groff or TeX but how do I get the data files in the first place? Assuming I want to create a page per week, can I use something like GCAL to create data for each week? If so how? -- John **= Email 5 ==========================** Date: Wed, 01 Dec 2004 02:33:56 +0100 From: "Knut St. Osmundsen" Subject: Re: Ugly problems with chdrive and mkdir in gcc 3.3.5 lsunley at mb.sympatico.ca wrote: > I have discovered that if I use the number value of the drive letter (76 > for drive L) the chdrive routine in 3.3.5 will change drives. When I use > the drive number (starting with A = 1) the chdrive 3.3.5 will not work. > > getdrive in 3.2.2 returns the number value of the drive letter L = 76 > whereas getdrive in 3.3.5 returns the drive number L = 12 > Yes, this is indeed the problem. _getdrive() returned number not letter. In addition, _chdrive() would for some reason try hide any errors and always return 0. I've fixed both the mentioned problems. Thanks for the testcases. Kind Regards, knut **= Email 6 ==========================** Date: Wed, 01 Dec 2004 02:31:07 +0100 From: "Knut St. Osmundsen" Subject: Re: More on mkdir Hi, thanks for making me a testcase for this problem. The problem is fixed. Kind Regards, knut lsunley at mb.sympatico.ca wrote: > This will not work either > > NOTE leading "/" on directory to make the directory in the root directory > of the current drive. The program below that does work creates > subdirectories in the current directory. > > #include > #include > > main (argc, argv) > { > > char currloc[256]; > char setloc [256]; > int currdrive; > int chgdrive; > int newdrive; > > _getcwd(setloc, 255); > fprintf(stderr, "Set directory %s\n", setloc); > mkdir("/pug_test", 777); > fprintf(stderr, "errno for pug_test %d\n", errno); > mkdir("/pug_test/lowerone", 777); > fprintf(stderr, "errno for pug_test lowerone %d\n", errno); > > } > > > In <0I7Z00D9D90YNF at l-daemon>, on 11/29/04 > at 11:37 PM, lsunley at mb.sympatico.ca said: > > >>This program will not work... > > >>#include >>#include > > >>main (argc, argv) >>{ > > >>char currloc[256]; >>char setloc [256]; >>int currdrive; >>int chgdrive; >>int newdrive; > > > >> chdir("\\"); >> fprintf(stderr, "errno for chdir %d\n", errno); > > >> _getcwd(setloc, 255); >> fprintf(stderr, "Set directory %s\n", setloc); >> mkdir("pug_test", 777); >> fprintf(stderr, "errno for pug_test %d\n", errno); >> mkdir("pug_test/lowerone", 777); >> fprintf(stderr, "errno for pug_test lowerone %d\n", errno); } > > > >>This one will > > >>#include >>#include > > >>main (argc, argv) >>{ > > >>char currloc[256]; >>char setloc [256]; >>int currdrive; >>int chgdrive; >>int newdrive; > > >>/* >> chdir("\\"); >> fprintf(stderr, "errno for chdir %d\n", errno); >>*/ >> _getcwd(setloc, 255); >> fprintf(stderr, "Set directory %s\n", setloc); >> mkdir("pug_test", 777); >> fprintf(stderr, "errno for pug_test %d\n", errno); >> mkdir("pug_test/lowerone", 777); >> fprintf(stderr, "errno for pug_test lowerone %d\n", errno); > > > >> > > >>} > > > >>The chdir routine screws something up... > > >>Lorne > > > > **= Email 7 ==========================** Date: Wed, 01 Dec 2004 02:39:03 +0100 From: "Knut St. Osmundsen" Subject: Re: GCC question Stefan.Neis at t-online.de wrote: > Hi, > > While trying to build wxWindows with Innotek's gcc-3.2.2 with and without STL, > I noticed an odd problem with a couple of symbols. With STL support enabled, > I get unresolved references to > > >>nm core*colr*o | grep GLOBAL > > U __GLOBAL__D__ZN21wxGenericColourDialog14wxCreateObjectEv > U __GLOBAL__I__ZN21wxGenericColourDialog14wxCreateObjectEv > > Strangely, the demangler (i.e. when using "nm -C" or piping this stuff through c++filt) > doesn't know anything about those symbols. Any idea what those symbols are? > In case it's helpful, __ZN21wxGenericColourDialog14wxCreateObjectEv is successfully > demangled to wxGenericColourDialog::wxCreateObject(). > > Even more strangely, in non STL enabled builds, I get > > >>nm core*colr*o | grep GLOBAL > > 000037c8 t __GLOBAL__D__ZN21wxGenericColourDialog14wxCreateObjectEv > 000037b0 t __GLOBAL__I__ZN21wxGenericColourDialog14wxCreateObjectEv > > Thus, no problems when actually trying to link things together. > > Apparently, there are no similar problems on other platforms... :-o > > Does anybody have any idea, what those symbols actually are or why inclusion > of a couple of STL headers apparently converts them from locally defined symbols > to references to global symbols that never get defined anywhere? > My guess (too late to consult the code/docs) is that these symbols are global initializers and destructors. Exactly why they end up being undefined in one case beats me. Kind Regards, knut **= Email 8 ==========================** Date: Wed, 01 Dec 2004 02:46:21 +0100 From: "Knut St. Osmundsen" Subject: Re: Does link do anything Hi Yuri, thanks for finding that bugger. I apparently hadn't finished symlink loop checking - ELOOP was missing. The problem have been fixed. (I.e. the 3rd realpath() call will return NULL and errno=ELOOP.) Kind Regards, knut Yuri Dario wrote: > Hi Knut, > > >>Can you explain how to reproduce this and I'll fix it. > > > :-) > > this is a simple testcase: > > #include > #include > > > void main(void) > { > int rc; > char buff[260]; > > FILE* d = fopen( "dummy.txt", "w"); > fprintf( d, "some text\n"); > fclose(d); > > unlink( "test\\dummy.txt"); > rc = symlink( "dummy.txt", "test\\dummy.txt"); > printf( "symlink rc=%d\n", rc); > > rc = realpath("dummy.txt",buff); > printf( "realpath rc=%d\n", rc); > > rc = realpath("test\\dummy.txt",buff); > printf( "realpath rc=%d\n", rc); > > } > > the problem is in the SYMLINK EA: > > E:\rd\MySQL\test\symlink>eatool -l test\dummy.txt > test\dummy.txt: > SYMLINK: "dummy.txt" > > the linked file points to a relative path: since the current directory can change, I suggest to use > full paths in symlinked files. > > > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.os2power.com/yuri > * http://www.teamos2.it > */ > > > **= Email 9 ==========================** Date: Tue, 30 Nov 2004 22:41:35 -0500 From: lsunley at mb.sympatico.ca Subject: Re: More on mkdir Thanks Knut Your work is much appreciated Lorne BTW - I'm finally at the point of testing my sys V sempaphore routines for postgreSQL. I have an almost running server (once I get the semaphores and signals working correctly). Lorne In <41AD1EDB.50200 at anduin.net>, on 12/01/04 at 02:31 AM, "Knut St. Osmundsen" said: >Hi, >thanks for making me a testcase for this problem. >The problem is fixed. >Kind Regards, > knut >lsunley at mb.sympatico.ca wrote: >> This will not work either >> >> NOTE leading "/" on directory to make the directory in the root directory >> of the current drive. The program below that does work creates >> subdirectories in the current directory. >> >> #include >> #include >> >> main (argc, argv) >> { >> >> char currloc[256]; >> char setloc [256]; >> int currdrive; >> int chgdrive; >> int newdrive; >> >> _getcwd(setloc, 255); >> fprintf(stderr, "Set directory %s\n", setloc); >> mkdir("/pug_test", 777); >> fprintf(stderr, "errno for pug_test %d\n", errno); >> mkdir("/pug_test/lowerone", 777); >> fprintf(stderr, "errno for pug_test lowerone %d\n", errno); >> >> } >> >> >> In <0I7Z00D9D90YNF at l-daemon>, on 11/29/04 >> at 11:37 PM, lsunley at mb.sympatico.ca said: >> >> >>>This program will not work... >> >> >>>#include >>>#include >> >> >>>main (argc, argv) >>>{ >> >> >>>char currloc[256]; >>>char setloc [256]; >>>int currdrive; >>>int chgdrive; >>>int newdrive; >> >> >> >>> chdir("\\"); >>> fprintf(stderr, "errno for chdir %d\n", errno); >> >> >>> _getcwd(setloc, 255); >>> fprintf(stderr, "Set directory %s\n", setloc); >>> mkdir("pug_test", 777); >>> fprintf(stderr, "errno for pug_test %d\n", errno); >>> mkdir("pug_test/lowerone", 777); >>> fprintf(stderr, "errno for pug_test lowerone %d\n", errno); } >> >> >> >>>This one will >> >> >>>#include >>>#include >> >> >>>main (argc, argv) >>>{ >> >> >>>char currloc[256]; >>>char setloc [256]; >>>int currdrive; >>>int chgdrive; >>>int newdrive; >> >> >>>/* >>> chdir("\\"); >>> fprintf(stderr, "errno for chdir %d\n", errno); >>>*/ >>> _getcwd(setloc, 255); >>> fprintf(stderr, "Set directory %s\n", setloc); >>> mkdir("pug_test", 777); >>> fprintf(stderr, "errno for pug_test %d\n", errno); >>> mkdir("pug_test/lowerone", 777); >>> fprintf(stderr, "errno for pug_test lowerone %d\n", errno); >> >> >> >>> >> >> >>>} >> >> >> >>>The chdir routine screws something up... >> >> >>>Lorne >> >> >> >> -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 10 ==========================** Date: Wed, 1 Dec 2004 11:42:43 +0100 From: Stefan.Neis at t-online.de Subject: Re: GCC question Hi, > My guess (too late to consult the code/docs) is that these symbols are > global initializers and destructors. Yes, exactly. > Exactly why they end up being undefined in one case beats me. Meanwhile, somebody remembered the problem with such symbols being undefined under specific circumstances exists in MinGW as well - when combining #pragma interface/implementation with template classes or with exception handling or with RTTI, there are the same kind of problems in MinGW. Though this doesn't seem to exactly match the problem I encountered (AFAIK exception handling and RTTI are _not_ a problem with "our" gcc version - or it shouldn't work without STL support either - and the symbols I'm missing are not directly related to template classes either), the workaround for MinGW (omitting pragma interface/implementation) fixes my problem as well. Regards, Stefan P.S.: Just for completeness: the MinGW problems are rumoured to be fixed in gcc-3.4.1 and newer. **= Email 11 ==========================** Date: Wed, 1 Dec 2004 12:35:34 +0100 From: Stefan.Neis at t-online.de Subject: Re: No sys/sysctl.h in GCC 3.3.5 Hi, > addressed. It is heartening that a relatively recent version of BSD PING > can be built straight out of the box using the latest gcc. It will be > interesting to see how much more of IBM's TCP/IP stack can be replaced > with open source code. I wouldn't really call this "TCP/IP stack", but rather simple TCP/IP applications (I think the real "stack" is what is implemented in the various mptn/protocol/*.sys files) > arp, ifconfig, ping, tracerte, host, hostid, hostname?... > > Could they all be built directly from *BSD code? ping and tracerte shouldn't be much of a problem, arp is probably going to be interesting (IIRC you need access to the ethernet package level as opposed to the TCP/IP packet wrapped in it), hostname is either going to be death simple or quite problematic, depending on how it is done exactly (hostname could be implemented by a simple "wrapper" around the C function 'hostname' or it could try to access kernel functionality for maximum performance - see "old ping" vs. "newest ping"), ifconfig might be similar, but I'm not really sure (at least no standard C function implementing it immediately comes to my mind). What are host and hostid? Is that standard functionality or just an OS/2 add-on? Regards, Stefan **= Email 12 ==========================** Date: Wed, 1 Dec 2004 11:44:38 +0000 From: John Poltorak Subject: Re: No sys/sysctl.h in GCC 3.3.5 On Wed, Dec 01, 2004 at 12:35:34PM +0100, Stefan.Neis at t-online.de wrote: > What are host and hostid? Is that standard > functionality or just an OS/2 add-on? I don't know - they are in \mptn\bin. I assumed they were standard apps. I can't imagine IBM adding new utilities... > Regards, > Stefan > > -- John