Date: Mon, 24 Jan 2005 00:04:19 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 511 ************************************************** Sunday 23 January 2005 Number 511 ************************************************** Subjects for today 1 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 2 Re: gcc 3.3.5 b4 - MakeOmfLibs.cmd : Michael Greene 3 Passing parameters to configure : John Poltorak 4 Re: gcc 3.3.5 b4 - MakeOmfLibs.cmd : Dave Yeo" 5 Re: gcc 3.3.5 b4 - MakeOmfLibs.cmd : Knut St. Osmundsen" 6 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Knut St. Osmundsen" 7 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : John Poltorak 8 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 9 Re: Passing parameters to configure : Yuri Dario" 10 Re: Passing parameters to configure : John Poltorak 11 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 12 Re: Passing parameters to configure : Stefan.Neis at t-online.de 13 Re: zlib : John Poltorak 14 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : John Poltorak 15 Re: Passing parameters to configure : John Poltorak 16 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : lamikr 17 Porting Webmin to a New Operating System : John Poltorak 18 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Stefan.Neis at t-online.de 19 Re: Passing parameters to configure : Steven Levine" 20 Re: Passing parameters to configure : John Poltorak 21 Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 : Knut St. Osmundsen" **= Email 1 ==========================** Date: Sat, 22 Jan 2005 15:45:57 +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 Huh? What happened here? My comment seems to have vanished... Anyway, what I wanted to write is that the problem are wildcards which you carefully escaped to avoid expansion by the shell (think of stuff like "unzip zip-File *.c" (or "... '*.c'" on Unix systems)). If the program then expands those wildcards, it's going to be infuriating. EMX' _wildcard has some heuristics to avoid such unwanted expansion in the most common cases, but there _is_ a problem). Ideally, the modified startup code would be able to check where it was started from, but even then it's not going to be completely trivial to always get the "right" behaviour. Regards, Stefan **= Email 2 ==========================** Date: Sat, 22 Jan 2005 10:10:19 -0500 From: Michael Greene Subject: Re: gcc 3.3.5 b4 - MakeOmfLibs.cmd I downloaded gcc 3.3.5 b4 and ran MakeOmfLibs.cmd. I get these 2 warnings: [D:\usr\lib]D:\usr\lib\..\bin\emxomf.exe -t -p128 D:\usr\lib\dbg\libc_l_s.a emxomf warning: Cannot find address of communal/external variable _DYNAMIC [D:\usr\lib]D:\usr\lib\..\bin\emxomf.exe -t -p128 D:\usr\lib\dbg\libc_s.a emxomf warning: Cannot find address of communal/external variable _DYNAMIC -- M Greene Voice Memeber #1356 IRC (MikeG): irc.va.webbnet.info #os/2 and #learnc++ ashburn.va.us.undernet.org #os/2warp irc.ecomstation.com #eCS http://members.cox.net/greenemk/os2/index.html **= Email 3 ==========================** Date: Sat, 22 Jan 2005 16:41:10 +0000 From: John Poltorak Subject: Passing parameters to configure How do a go about passing parameter to configure? I now how to start configure with avialable options like '--prefix=...' where this particular parameter is read from a file, but I've just come across POVRAY which insists on configure being run with the parameter COMPILED_BY="your name " How could I get this option into the configure command line from a parameter file? -- John **= Email 4 ==========================** Date: Sat, 22 Jan 2005 09:01:43 -0800 From: "Dave Yeo" Subject: Re: gcc 3.3.5 b4 - MakeOmfLibs.cmd On Sat, 22 Jan 2005 10:10:19 -0500, Michael Greene wrote: >I downloaded gcc 3.3.5 b4 and ran MakeOmfLibs.cmd. I get these 2 warnings: > > > >[D:\usr\lib]D:\usr\lib\..\bin\emxomf.exe -t -p128 D:\usr\lib\dbg\libc_l_s.a >emxomf warning: Cannot find address of communal/external variable _DYNAMIC > >[D:\usr\lib]D:\usr\lib\..\bin\emxomf.exe -t -p128 D:\usr\lib\dbg\libc_s.a >emxomf warning: Cannot find address of communal/external variable _DYNAMIC I got the same warnings here. I think this is related to static builds being broken. eg you can link with libc.dll but not libc_.a Dave **= Email 5 ==========================** Date: Sat, 22 Jan 2005 19:35:11 +0100 From: "Knut St. Osmundsen" Subject: Re: gcc 3.3.5 b4 - MakeOmfLibs.cmd Dave Yeo wrote: > On Sat, 22 Jan 2005 10:10:19 -0500, Michael Greene wrote: > > >>I downloaded gcc 3.3.5 b4 and ran MakeOmfLibs.cmd. I get these 2 warnings: >> >> >> >>[D:\usr\lib]D:\usr\lib\..\bin\emxomf.exe -t -p128 D:\usr\lib\dbg\libc_l_s.a >>emxomf warning: Cannot find address of communal/external variable _DYNAMIC >> >>[D:\usr\lib]D:\usr\lib\..\bin\emxomf.exe -t -p128 D:\usr\lib\dbg\libc_s.a >>emxomf warning: Cannot find address of communal/external variable _DYNAMIC > > > I got the same warnings here. I think this is related to static builds being broken. eg you can link with libc.dll but not libc_.a > Dave No, it's related to some BSD code (nsswitch IIRC) checking for the DYNAMIC symbol to see if it's static or dynamically linked IIRC. Just ignore it. Kind Regards, knut **= Email 6 ==========================** Date: Sat, 22 Jan 2005 19:41:07 +0100 From: "Knut St. Osmundsen" Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 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? Unsurprisingly I think we have exactly the same 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. Excellent idea. A -Zwildcard and an extra set of crt0 modules. I'll try do it next time I've got a weekend to spend on libc again. Kind Regards, knut **= Email 7 ==========================** Date: Sat, 22 Jan 2005 18:59:37 +0000 From: John Poltorak Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 On Sat, Jan 22, 2005 at 07:41:07PM +0100, Knut St. Osmundsen wrote: > > > 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? > > Unsurprisingly I think we have exactly the same 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. > > Excellent idea. A -Zwildcard and an extra set of crt0 modules. I'll try > do it next time I've got a weekend to spend on libc again. I don't suppose there is any way of automatically adding EA support globally... > Kind Regards, > knut -- John **= Email 8 ==========================** Date: Sat, 22 Jan 2005 20:03:00 +0100 From: Stefan.Neis at t-online.de Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 Knut St. Osmundsen wrote: > > > > 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? > > Unsurprisingly I think we have exactly the same function... :-) Well, with all that different licencing in the EMX libraries, I never know which ones you could just reuse, which ones you wanted to update anyway, which ones newly added, which ones need to be/are reimplemented and which ones are missing. This is especially confusing if I'm at a machine where I don't have your gcc port installed. ;-) OTOH, I wanted to get my idea out to the public before forgetting about it. ;-) Regards, Stefan **= Email 9 ==========================** Date: Sat, 22 Jan 2005 20:02:38 +0100 (CET) From: "Yuri Dario" Subject: Re: Passing parameters to configure Hi, >How could I get this option into the configure command line from a >parameter file? follow this sample #! /bin/sh CFLAGS="-s -Zomf -O3 -march=pentium -mcpu=pentium3" \ CXXFLAGS="-s -Zomf -O3 -march=pentium -mcpu=pentium3" \ LDFLAGS="-s -Zmap -Zhigh-mem -Zomf -Zexe" \ LN_CP_F="cp.exe" \ RANLIB="echo" \ AR="emxomfar" \ ../configure --disable-clamav --with-zlib=E:\dev\gcc06-b4\local --prefix=/usr/local/clamav Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 10 ==========================** Date: Sat, 22 Jan 2005 19:18:16 +0000 From: John Poltorak Subject: Re: Passing parameters to configure On Sat, Jan 22, 2005 at 08:02:38PM +0100, Yuri Dario wrote: > Hi, > > >How could I get this option into the configure command line from a > >parameter file? > > follow this sample > > #! /bin/sh > CFLAGS="-s -Zomf -O3 -march=pentium -mcpu=pentium3" \ > CXXFLAGS="-s -Zomf -O3 -march=pentium -mcpu=pentium3" \ > LDFLAGS="-s -Zmap -Zhigh-mem -Zomf -Zexe" \ > LN_CP_F="cp.exe" \ > RANLIB="echo" \ > AR="emxomfar" \ > ./configure --disable-clamav --with-zlib=E:\dev\gcc06-b4\local > --prefix=/usr/local/clamav I've already tried this but can't find the correct syntax. It looks like I need to include quotes (") as part of the parameter. I think I need to run something like this at the command line:- ../configure $parms where $parms gets resolved as:- COMPILED_BY="me " but I can't work out what $parms needs to be set to... > > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.os2power.com/yuri > * http://www.teamos2.it > */ -- John **= Email 11 ==========================** Date: Sat, 22 Jan 2005 20:33:12 +0100 From: Stefan.Neis at t-online.de Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 John Poltorak wrote: > > Excellent idea. A -Zwildcard and an extra set of crt0 modules. I'll try > > do it next time I've got a weekend to spend on libc again. > > I don't suppose there is any way of automatically adding EA support > globally... Well, first of all EAP support is typically irrelevant for most programs, the exceptions being programs that copy or archive files, or am I missing something? Theoretically, you could e.g. modify the routines that read/write files to first read/write the size of EA data, then read/write EA data and then read/write the rest of the file, but that's rather much work and probably results in desaster if you use that on programs it wasn't meant for (i.e. everything expecting to get file content from offset 0 onwards). I think its easier to try and handle that by adding some OS/2 specific code to the (few?) programs where this is relevant. Regards, Stefan **= Email 12 ==========================** Date: Sat, 22 Jan 2005 20:36:47 +0100 From: Stefan.Neis at t-online.de Subject: Re: Passing parameters to configure Hi, > I think I need to run something like this at the command line:- > > ../configure $parms > > where $parms gets resolved as:- > > COMPILED_BY="me " > > but I can't work out what $parms needs to be set to... Well, I don't know, but I'd rather think that what you need is: COMPILED_BY="me " ../configure i.e. I suppose it really is an environment variable, not a parameter. If you actually need to escape the quotes '\"' (without the surrounding single quotes) should do... Regards, Stefan **= Email 13 ==========================** Date: Sat, 22 Jan 2005 19:38:30 +0000 From: John Poltorak Subject: Re: zlib On Sun, Jan 16, 2005 at 01:46:50PM -0800, Dave Yeo wrote: > On Sun, 16 Jan 2005 08:53:31 +0000, John Poltorak wrote: > > >It would be good to include build instructions for OS/2 within the > >archive which even provides support for DOS. Is the win32\makefile.gcc a > >reasonable example to follow? > > You know I haven't even looked at these yet. I've just been extending someone elses makefile. I'll check these out > Also I'd send the makefiles but I think the list is stripping attachments now If you have any patches or a build script and it is getting stripped off, can you send it to the UX2BS list? I really need to get ZLIB included in UX2BS as a an uptodate working app as it's so widely used by so many programmes. > Dave > -- John **= Email 14 ==========================** Date: Sat, 22 Jan 2005 19:46:02 +0000 From: John Poltorak Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 On Sat, Jan 22, 2005 at 08:33:12PM +0100, Stefan.Neis at t-online.de wrote: > John Poltorak wrote: > > > Excellent idea. A -Zwildcard and an extra set of crt0 modules. I'll try > > > do it next time I've got a weekend to spend on libc again. > > > > I don't suppose there is any way of automatically adding EA support > > globally... > > Well, first of all EAP support is typically irrelevant for most programs, > the exceptions being programs that copy or archive files, or am I missing > something? You're right, the ability to handle EAs is a non issue for most programs. > Theoretically, you could e.g. modify the routines that read/write files > to first read/write the size of EA data, then read/write EA data and > then read/write the rest of the file, but that's rather much work and > probably results in desaster if you use that on programs it wasn't > meant for (i.e. everything expecting to get file content from offset 0 > onwards). > I think its easier to try and handle that by adding some OS/2 specific > code to the (few?) programs where this is relevant. I don't know what the scope of programmes handling EAs might be, but it would be great if we could automatically have it in tar, bzip2, gzip, rsync, wget among others besides cp and mv. > Regards, > Stefan > > -- John **= Email 15 ==========================** Date: Sat, 22 Jan 2005 20:23:55 +0000 From: John Poltorak Subject: Re: Passing parameters to configure On Sat, Jan 22, 2005 at 08:36:47PM +0100, Stefan.Neis at t-online.de wrote: > Hi, > > > I think I need to run something like this at the command line:- > > > > ../configure $parms > > > > where $parms gets resolved as:- > > > > COMPILED_BY="me " > > > > but I can't work out what $parms needs to be set to... > > Well, I don't know, but I'd rather think that what you need > is: > COMPILED_BY="me " ../configure > i.e. I suppose it really is an environment variable, not a > parameter. If you actually need to escape the quotes '\"' > (without the surrounding single quotes) should do... I don't really see how it could be an environment variable... This is what it says when I run POVRAY's configure without without any parameters:- Welcome to the POV-Ray 3.6.1 configure script. This script will prepare the source distribution of POV-Ray 3.6.1 for Unix for compilation on this machine. Compiling the program yourself means that the POV-Ray Team(tm) is not responsible for supporting this version, no matter if it is the unmodified official POV-Ray source code or a customized version. Refer to the POV-Ray source license conditions that come with this package. In order to start configuration, you have to provide a valid contact information that will be included in the executable and displayed whenever POV-Ray (or a modified version of it) is started. In case you intend to distribute this binary, this information will help users to contact the appropriate maintainers. To start configuring POV-Ray type in the following command with your own contact information: ../configure COMPILED_BY="your name " > Regards, > Stefan > > -- John **= Email 16 ==========================** Date: Sat, 22 Jan 2005 23:21:58 +0200 From: lamikr Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 What about Symlink extension that Martin made about one year ago. Is that using EAs for storing symlink information. Is symlink supported btw. in the Innoteks lib? >I don't know what the scope of programmes handling EAs might be, but it >would be great if we could automatically have it in tar, bzip2, gzip, >rsync, wget among others besides cp and mv. > > > > >> Regards, >> Stefan >> >> >> >> > > > > **= Email 17 ==========================** Date: Sat, 22 Jan 2005 22:45:15 +0000 From: John Poltorak Subject: Porting Webmin to a New Operating System Whilst messing around with Webmin I actually came across some docs! In particular this section looked to be worth studying:- http://www.webmin.com/modules.html#port What entry should we have in os_list.txt? Here is an example for Linux:- Foobar Linux 1.0 redhat-linux 7.3 `cat /etc/foobar-release 2>&1` =~ /Foobar.*1\.0/i The line is made up of five fields, separated by tabs. They are : # 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. -- John **= Email 18 ==========================** Date: Sun, 23 Jan 2005 00:31:03 +0100 From: Stefan.Neis at t-online.de Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 Hi, > What about Symlink extension that Martin made about one year ago. > Is that using EAs for storing symlink information. Probably. > Is symlink supported btw. in the Innoteks lib? Yes. And it's using EAs for this purpose. AFAIK, it's even compatible with the way Linux creates symlinks on HPFS in the latest release. Regards, Stefan **= Email 19 ==========================** Date: Sun, 23 Jan 2005 00:58:32 -0800 From: "Steven Levine" Subject: Re: Passing parameters to configure In <20050122202355.I18360 at warpix.org>, on 01/22/05 at 08:23 PM, John Poltorak said: >I don't really see how it could be an environment variable... It will be. This is how configure scripts work. :-) To see what really happens, find the for ac_option statement in configure and then find the code that handles the *=* case. If you can read the code you will see that COMPILED_BY ends up exported to the environment with the value you supplied. HTH, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 20 ==========================** Date: Sun, 23 Jan 2005 11:25:37 +0000 From: John Poltorak Subject: Re: Passing parameters to configure On Sun, Jan 23, 2005 at 12:58:32AM -0800, Steven Levine wrote: > In <20050122202355.I18360 at warpix.org>, on 01/22/05 > at 08:23 PM, John Poltorak said: > > >I don't really see how it could be an environment variable... > > It will be. This is how configure scripts work. :-) > > To see what really happens, find the > > for ac_option > > statement in configure and then find the code that handles the *=* case. > If you can read the code you will see that COMPILED_BY ends up exported to > the environment with the value you supplied. Setting the environment variable does indeed work as you say and now configure runs without any problem. > HTH, > > Steven > > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.100c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- > -- John **= Email 21 ==========================** Date: Sun, 23 Jan 2005 13:17:28 +0100 From: "Knut St. Osmundsen" Subject: Re: wildcard expansion, was: coreutils with gcc 3.3.5 b4 John Poltorak wrote: > On Sat, Jan 22, 2005 at 08:33:12PM +0100, Stefan.Neis at t-online.de > wrote: > >> John Poltorak wrote: >> >>>> Excellent idea. A -Zwildcard and an extra set of crt0 modules. >>>> I'll try do it next time I've got a weekend to spend on libc >>>> again. >>> >>> >>> I don't suppose there is any way of automatically adding EA >>> support globally... >> >> Well, first of all EAP support is typically irrelevant for most >> programs, the exceptions being programs that copy or archive files, >> or am I missing something? > > > You're right, the ability to handle EAs is a non issue for most > programs. > > >> Theoretically, you could e.g. modify the routines that read/write >> files to first read/write the size of EA data, then read/write EA >> data and then read/write the rest of the file, but that's rather >> much work and probably results in desaster if you use that on >> programs it wasn't meant for (i.e. everything expecting to get file >> content from offset 0 onwards). I think its easier to try and >> handle that by adding some OS/2 specific code to the (few?) >> programs where this is relevant. > > > I don't know what the scope of programmes handling EAs might be, but > it would be great if we could automatically have it in tar, bzip2, > gzip, rsync, wget among others besides cp and mv. Linux got EA support a while back. If stuff like coreutils starts using it would make sense to implement that interface in LIBC too. The linux guys got it from SGI it seems, so it's not a standarized api yet. Anyway, look for these functions: [lf]*setxattr, [lf]*getxattr, [lf]*listxattr and [lf]*removexattr. And these commands: attr, getfattr and setattr. The BSD guys seems to be making a extattr_* api family. We'll have to see which ends up being used. Kind Regards, knut