Date: Wed, 26 Jan 2005 00:04:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 513 ************************************************** Tuesday 25 January 2005 Number 513 ************************************************** Subjects for today 1 Re: Perl help : Andy Willis 2 Re: Re: Xfree86 with libc : Dave Yeo" 3 SC_PAGESIZE and Innotek_libc : Dave Yeo" 4 DosDevIOCtl and innotek_libc : Dave Yeo" 5 Re: DosDevIOCtl and innotek_libc : Thomas Dickey 6 Re: DosDevIOCtl and innotek_libc : Thomas Dickey 7 Re: DosDevIOCtl and innotek_libc : Dave Yeo" 8 Re: search order for libs with Innotek_libc : Dave Yeo" 9 Re: Perl help : John Poltorak **= Email 1 ==========================** Date: Mon, 24 Jan 2005 06:42:17 -0700 From: Andy Willis Subject: Re: Perl help Stefan.Neis at t-online.de wrote: > Hi, > > > >>>Question: does anyone know what 'uname -sv' returns on eCS? >>> >>> > >Here, I get "OS/2 2.45" (eCS 1.0), I suppose it'll be the same for >later versions. > > Regards, > Stefan > > > > Would it make any difference if it was run from cmd.exe or 4os2.exe? Andy **= Email 2 ==========================** Date: Mon, 24 Jan 2005 14:43:06 -0800 From: "Dave Yeo" Subject: Re: Re: Xfree86 with libc On Mon, 24 Jan 2005 09:27:19 +0100, Holger Veit wrote: >Warning: there are symbols in X11 which regularly already have a leading >underscore. IIRC, this holds for Xfree() >in particular - there is also an _Xfree(). Consequently, this has to be >modified to __Xfree, otherwise you'll get an insane mess of _Xfree and >Xfree which leads to a recursion in the application code. BTDT. I just added a couple of lines like line = ('_'line); Where line is the export and it seems to of worked ok. One interesting thing was XOS2RedirRoot which ended up with 3 underlines Dave **= Email 3 ==========================** Date: Mon, 24 Jan 2005 15:48:35 -0800 From: "Dave Yeo" Subject: SC_PAGESIZE and Innotek_libc I see that SC_PAGESIZE is defined in unistd.h but doesn't exist in lib. libcwrapper.c: In function `xf86getpagesize': libcwrapper.c:1844: error: `_SC_PAGESIZE' undeclared (first use in this function) should I plan on this working later or just define that we don't have it? here is where it is defined /* For xf86getpagesize() */ #if defined(linux) #define HAS_SC_PAGESIZE #define HAS_GETPAGESIZE #elif defined(CSRG_BASED) #define HAS_GETPAGESIZE #elif defined(DGUX) #define HAS_GETPAGESIZE #elif defined(sun) && !defined(SVR4) #define HAS_GETPAGESIZE #endif #ifdef XNO_SYSCONF #undef _SC_PAGESIZE #endif #ifdef HAVE_SYSV_IPC #include #include #endif #include Strangely this didn't seem to be a problem with EMX and gcc 3.0.3 Dave **= Email 4 ==========================** Date: Mon, 24 Jan 2005 16:57:14 -0800 From: "Dave Yeo" Subject: DosDevIOCtl and innotek_libc Hi I'm getting undefined symbol _DosDevIOCtl in os2main.o from xterm. This didn't happen under EMX.. Adding #define INCL_DOSDEVICES seems to of fixed this. /* os2main.c */ #define INCL_DOSFILEMGR #define INCL_DOSDEVIOCTL #define INCL_DOSSEMAPHORES #ifdef __INNOTEK_LIBC__ #define INCL_DOSDEVICES #endif #define I_NEED_OS2_H #include #define XTERM_MAIN Dave **= Email 5 ==========================** Date: Mon, 24 Jan 2005 20:17:32 -0500 (EST) From: Thomas Dickey Subject: Re: DosDevIOCtl and innotek_libc On Mon, 24 Jan 2005, Dave Yeo wrote: > Hi I'm getting undefined symbol _DosDevIOCtl in os2main.o from xterm. This didn't > happen under EMX.. Adding #define INCL_DOSDEVICES seems to of fixed this. if that still works with EMX, would be nice to know. > /* os2main.c */ > #define INCL_DOSFILEMGR > #define INCL_DOSDEVIOCTL > #define INCL_DOSSEMAPHORES > #ifdef __INNOTEK_LIBC__ > #define INCL_DOSDEVICES > #endif > #define I_NEED_OS2_H > #include > #define XTERM_MAIN > > Dave > > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 6 ==========================** Date: Mon, 24 Jan 2005 20:17:32 -0500 (EST) From: Thomas Dickey Subject: Re: DosDevIOCtl and innotek_libc On Mon, 24 Jan 2005, Dave Yeo wrote: > Hi I'm getting undefined symbol _DosDevIOCtl in os2main.o from xterm. This didn't > happen under EMX.. Adding #define INCL_DOSDEVICES seems to of fixed this. if that still works with EMX, would be nice to know. > /* os2main.c */ > #define INCL_DOSFILEMGR > #define INCL_DOSDEVIOCTL > #define INCL_DOSSEMAPHORES > #ifdef __INNOTEK_LIBC__ > #define INCL_DOSDEVICES > #endif > #define I_NEED_OS2_H > #include > #define XTERM_MAIN > > Dave > > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 7 ==========================** Date: Mon, 24 Jan 2005 19:11:53 -0800 From: "Dave Yeo" Subject: Re: DosDevIOCtl and innotek_libc On Mon, 24 Jan 2005 20:17:32 -0500 (EST), Thomas Dickey wrote: >On Mon, 24 Jan 2005, Dave Yeo wrote: > >> Hi I'm getting undefined symbol _DosDevIOCtl in os2main.o from xterm. This didn't >> happen under EMX.. Adding #define INCL_DOSDEVICES seems to of fixed this. > >if that still works with EMX, would be nice to know. This is the xterm that comes with XFree86 v4.4. It builds fine with gcc 3.0.3 and EMX. Is that what you meant? Dave **= Email 8 ==========================** Date: Mon, 24 Jan 2005 23:17:59 -0800 From: "Dave Yeo" Subject: Re: search order for libs with Innotek_libc On Sun, 23 Jan 2005 21:27:11 -0500, Henry Sobotka wrote: >Dave Yeo wrote: >> Given both libfoo.a and foo.a and something like gcc bar.c -lfoo which lib gets found first? > >[C:\temp]gcc -Zexe whichlib.c -Lc:/temp -lfoo > >[C:\temp]whichlib >libfoo.a found Seems that Innoteks gcc does search in the opposite order as 3.0.3 etc. I wonder what was the reasoning behind having 2 forwarder libs, one with ordinals and one without? Seems better to have libfoo.a have ordinals and the extra leading underline and foo.a to have ordinals and no leading underline for EMX apps. Dave **= Email 9 ==========================** Date: Tue, 25 Jan 2005 11:44:33 +0000 From: John Poltorak Subject: Re: Perl help On Mon, Jan 24, 2005 at 12:20:56PM +0000, Dave Saville wrote: > On Mon, 24 Jan 2005 11:16:03 +0000, John Poltorak wrote: > > >It's this bit of Perl code in oschooser.pl:- > > > > foreach $o ( at list) { > > if ($o->[4] && eval $o->[4]) { > > # Got a match! > > $ver = $o; > > last; > > } > > } > > > > > > > >Can't figure out the condition taht 'if' is checking at all... > > It would help if we knew what at list contained - but it would appear to be a > list of (anonymous) arrays and is testing the 5th element of same. If it > exists, first test, it runs it as code and the return from the eval is whatever > it did last. AFAICT at list is an array consisting lines from a file listing OS's supported. Each line consists of these five elements: # The operating system name visible to the user. # The version number visible to the user. # Webmin's internal code for the operating system, which you can find by looking at other entries in the file. This determines which actual config- files are used at installation time, and which modules are visible. # Webmin's internal version number for the operating system. Again, this is what actually determines which config- files to use when the OS is chosen. # A fragment of Perl code that is run at installation time to check for this operating system. If it evaluates to some some non-zero value, Webmin will never ask the user to choose his OS from a list when setup.sh is run. If you want the RPM version to be installable on this OS, this field must be filled in so that the RPM installation script can detect it - otherwise the install will fail. The code above must refer to the last of these elements. Assuming this was that element:- $uname =~/OS\/2/i what does the code above check? > -- > Regards > > Dave Saville > -- John