From: UnixOS2 Archive
To: "UnixOS2 Archive" <UnixOS2_Archive at unixos2.com>
Date: Sat, 1 Feb 2003 04:52:46 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 31

**************************************************
Friday 31 January 2003
 Number  31
**************************************************

Subjects for today
 
1  Re:  setup unixos2 : Ken Ames <kenames at pacbell.net>
2  Re:  setup unixos2 : Ken Ames <kenames at pacbell.net>
3  Re:  setup unixos2 : John Poltorak <jp at manninghammills.org>
4  Re:  LYNX : Mika Laitio <lamikr at cc.jyu.fi>
5   Include path : John Poltorak <jp at manninghammills.org>
6  Re:  Include path : Thomas Dickey <dickey at herndon4.his.com>
7  Re:  Include path : Thomas Hoffmann <thoffman at zappa.sax.de>
8  Re:  setup unixos2 : John Poltorak <jp at manninghammills.org>
9  Re:  Include path : John Poltorak <jp at manninghammills.org>

**= Email   1 ==========================**

Date:  Sat, 01 Feb 2003 08:31:41 -0800
From:  Ken Ames <kenames at pacbell.net>
Subject:  Re:  setup unixos2

hi John,
  I set emxopt = and ran a clean build again, this time it gave the 
extracting messages like you said below but it still got confused when 
it tried to build perl with the

make: *** No rule to make target `miniperl.exe', needed by `all'.  Stop.

error. then I cd'ed into \unixos2\workdir\perl-5.8.0 directory and from 
there ran

\unixos2\scripts\build\build_perl.cmd

which proceeded much further. now it stopped saying this

DProf.xs:294: storage size of `t' isn't known

so it seems to be moving along. btw, my system is celeron 1.3ghz with 
512meg ram and the original error happens even if the build system is 
the only thing going.

Ken


John Poltorak wrote:

>On Fri, Jan 31, 2003 at 10:36:43AM -0800, Ken Ames wrote:
>  
>
>>hi,
>>   ok, I tried again to run ux2_bootstrap.cmd to get unixos2 setup but 
>>it still is not working correctly. it gets to where it wants to build 
>>perl but bombs out saying
>>
>>make: *** No rule to make target `miniperl.exe', needed by `all'.  Stop.
>>    
>>
>
>
>No, the real problem occurs earlier with:-
>
>Extracting Makefile (with variable substitutions)
>Configure: os2/Makefile.SHs[14]: too many files open in shell
>Configure: ./Makefile.SH[24]: too many files open in shell
>Configure: UU/myread[16]: too many files open in shell
>
>This is what you should have:-
>
>
>Extracting Makefile (with variable substitutions)
>Extracting myconfig (with variable substitutions)
>Extracting pod/Makefile (with variable substitutions)
>Extracting Policy.sh (with variable substitutions)
>Extracting writemain (with variable substitutions)
>Extracting x2p/cflags (with variable substitutions)
>Extracting x2p/Makefile (with variable substitutions)
>Run make depend now? [y]
>
>Is your system memory constrained or possibly doing a lot of other tasks 
>while this Perl build is taking place
>
>
>Maybe you need to set EMXOPT or somesuch. I can't really say without 
>knowing your circumstances.
>
>
>  
>
>>Ken
>>
>>    
>>
>
>
>  
>


**= Email   2 ==========================**

Date:  Sat, 01 Feb 2003 08:31:41 -0800
From:  Ken Ames <kenames at pacbell.net>
Subject:  Re:  setup unixos2

hi John,
  I set emxopt = and ran a clean build again, this time it gave the 
extracting messages like you said below but it still got confused when 
it tried to build perl with the

make: *** No rule to make target `miniperl.exe', needed by `all'.  Stop.

error. then I cd'ed into \unixos2\workdir\perl-5.8.0 directory and from 
there ran

\unixos2\scripts\build\build_perl.cmd

which proceeded much further. now it stopped saying this

DProf.xs:294: storage size of `t' isn't known

so it seems to be moving along. btw, my system is celeron 1.3ghz with 
512meg ram and the original error happens even if the build system is 
the only thing going.

Ken


John Poltorak wrote:

>On Fri, Jan 31, 2003 at 10:36:43AM -0800, Ken Ames wrote:
>  
>
>>hi,
>>   ok, I tried again to run ux2_bootstrap.cmd to get unixos2 setup but 
>>it still is not working correctly. it gets to where it wants to build 
>>perl but bombs out saying
>>
>>make: *** No rule to make target `miniperl.exe', needed by `all'.  Stop.
>>    
>>
>
>
>No, the real problem occurs earlier with:-
>
>Extracting Makefile (with variable substitutions)
>Configure: os2/Makefile.SHs[14]: too many files open in shell
>Configure: ./Makefile.SH[24]: too many files open in shell
>Configure: UU/myread[16]: too many files open in shell
>
>This is what you should have:-
>
>
>Extracting Makefile (with variable substitutions)
>Extracting myconfig (with variable substitutions)
>Extracting pod/Makefile (with variable substitutions)
>Extracting Policy.sh (with variable substitutions)
>Extracting writemain (with variable substitutions)
>Extracting x2p/cflags (with variable substitutions)
>Extracting x2p/Makefile (with variable substitutions)
>Run make depend now? [y]
>
>Is your system memory constrained or possibly doing a lot of other tasks 
>while this Perl build is taking place
>
>
>Maybe you need to set EMXOPT or somesuch. I can't really say without 
>knowing your circumstances.
>
>
>  
>
>>Ken
>>
>>    
>>
>
>
>  
>


**= Email   3 ==========================**

Date:  Sat, 1 Feb 2003 09:39:26 +0000
From:  John Poltorak <jp at manninghammills.org>
Subject:  Re:  setup unixos2

On Fri, Jan 31, 2003 at 10:36:43AM -0800, Ken Ames wrote:
> hi,
>    ok, I tried again to run ux2_bootstrap.cmd to get unixos2 setup but 
> it still is not working correctly. it gets to where it wants to build 
> perl but bombs out saying
> 
> make: *** No rule to make target `miniperl.exe', needed by `all'.  Stop.


No, the real problem occurs earlier with:-

Extracting Makefile (with variable substitutions)
Configure: os2/Makefile.SHs[14]: too many files open in shell
Configure: ./Makefile.SH[24]: too many files open in shell
Configure: UU/myread[16]: too many files open in shell

This is what you should have:-


Extracting Makefile (with variable substitutions)
Extracting myconfig (with variable substitutions)
Extracting pod/Makefile (with variable substitutions)
Extracting Policy.sh (with variable substitutions)
Extracting writemain (with variable substitutions)
Extracting x2p/cflags (with variable substitutions)
Extracting x2p/Makefile (with variable substitutions)
Run make depend now? [y]

Is your system memory constrained or possibly doing a lot of other tasks 
while this Perl build is taking place


Maybe you need to set EMXOPT or somesuch. I can't really say without 
knowing your circumstances.


> Ken
> 


-- 
John



**= Email   4 ==========================**

Date:  Sat, 1 Feb 2003 12:05:03 +0200 (EET)
From:  Mika Laitio <lamikr at cc.jyu.fi>
Subject:  Re:  LYNX

> I'll have to check - iirc, it's running FP12 (I have a copy of FP14, but
> did not get around to installing it, since it's one of 10 OS's I have on
> that box, and OS/2 hasn't been _that_ good about updates).
>
> What versions could install properly on a 60G drive, btw?  My OS/2 is on
> a box with 2 8G's, and iirc, it wouldn't have been able to install on the
> newer with 40G's.  So I didn't add it to the newer machine.

I believe that most of the people are using FP 15 which has worked very
well at least for me. In addition most of the people have downloaded
danis* IDE drivers for getting better performing systems in the new
motherboards. These drivers can be found on Hobbes.

I have myself switched my existing OS/2 to a newer computer (and bigger
harddrive) by making following steps.

1) boot to OS/2 by using floppy disks
2) Make zip from the OS/2 partition with the pkzip. (Turn all
possible switches on so that all hidden system files, EAS, etc get
zipped) Alternatively you could just use XCOPY with parameters
"/H /O /T /S /E /R /V"
3) If you had OS/2 installed in drive E in the old system, reserve letter
E also for the OS/2 in the new computer
4) Copy the zip somehow to new computer
5) Boot to new computer with OS/2 floppies
6) Extract OS/2 zip file
7) Run magick command SYSINSTX to make new partition bootable

You can find info also from the following address:

http://en.ecomstation.ru/configtool/cfgdat01.php#Key007

Mika


**= Email   5 ==========================**

Date:  Sat, 1 Feb 2003 14:43:00 +0000
From:  John Poltorak <jp at manninghammills.org>
Subject:   Include path


Is the current directory automatically searched for headers? 

If so, how would you ensure that C_INCLUDE_PATH was searched first?

-- 
John


**= Email   6 ==========================**

Date:  Sat, 1 Feb 2003 14:46:14 -0500
From:  Thomas Dickey <dickey at herndon4.his.com>
Subject:  Re:  Include path

On Sat, Feb 01, 2003 at 05:34:27PM +0000, John Poltorak wrote:
> I was attempting to compile regex.dll and my cwd was glibc-2.2.4\posix
> 
> which includes the subdirectory 'sys' and within it there is a file called 
> types.h.
> 
> It appears that this is the file that got loaded by
> 
> #include <sys/types.h> 
> 
> within regex.c instead of the one from EMX which was on the C_INCLUDE_PATH.

there's probably a -I option in the makefile that points to the current
directory (even a "-I." will do this).

-- 
Thomas E. Dickey <dickey at invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

**= Email   7 ==========================**

Date:  Sat, 01 Feb 2003 16:46:33 +0100
From:  Thomas Hoffmann <thoffman at zappa.sax.de>
Subject:  Re:  Include path

It depends:

#include "ffo.h"
searches in the current dir first,

#include <bar.h>
does not.

As gcc says:

The `#include' Directive
------------------------

    Both user and system header files are included using the
preprocessing directive `#include'.  It has three variants:

`#include <FILE>'
      This variant is used for system header files.  It searches for a
      file named FILE in a list of directories specified by you, then in
      a standard list of system directories.  You specify directories to
      search for header files with the command option `-I' (*note
      Invocation::.).  The option `-nostdinc' inhibits searching the
      standard system directories; in this case only the directories you
      specify are searched.

      The parsing of this form of `#include' is slightly special because
      comments are not recognized within the `<...>'.  Thus, in
      `#include <x/*y>' the `/*' does not start a comment and the
      directive specifies inclusion of a system header file named
      `x/*y'.  Of course, a header file with such a name is unlikely to
      exist on Unix, where shell wildcard features would make it hard to
      manipulate.

      The argument FILE may not contain a `>' character.  It may,
      however, contain a `<' character.

`#include "FILE"'
      This variant is used for header files of your own program.  It
      searches for a file named FILE first in the current directory,
      then in the same directories used for system header files.  The
      current directory is the directory of the current input file.  It
      is tried first because it is presumed to be the location of the
      files that the current input file refers to.  (If the `-I-' option
      is used, the special treatment of the current directory is
      inhibited.)

      The argument FILE may not contain `"' characters.  If backslashes
      occur within FILE, they are considered ordinary text characters,
      not escape characters.  None of the character escape sequences
      appropriate to string constants in C are processed.  Thus,
      `#include "x\n\\y"' specifies a filename containing three
      backslashes.  It is not clear why this behavior is ever useful, but
      the ANSI standard specifies it.

`#include ANYTHING ELSE'
      This variant is called a "computed #include".  Any `#include'
      directive whose argument does not fit the above two forms is a
      computed include.  The text ANYTHING ELSE is checked for macro
      calls, which are expanded (*note Macros::.).  When this is done,
      the result must fit one of the above two variants--in particular,
      the expanded text must in the end be surrounded by either quotes
      or angle braces.

      This feature allows you to define a macro which controls the file
      name to be used at a later point in the program.  One application
      of this is to allow a site-specific configuration file for your
      program to specify the names of the system include files to be
      used.  This can help in porting the program to various operating
      systems in which the necessary system header files are found in
      different places.



John Poltorak wrote:
> Is the current directory automatically searched for headers? 
> 
> If so, how would you ensure that C_INCLUDE_PATH was searched first?
> 


**= Email   8 ==========================**

Date:  Sat, 1 Feb 2003 16:49:52 +0000
From:  John Poltorak <jp at manninghammills.org>
Subject:  Re:  setup unixos2

On Sat, Feb 01, 2003 at 08:31:41AM -0800, Ken Ames wrote:
> hi John,
>   I set emxopt = and ran a clean build again, this time it gave the 
> extracting messages like you said below but it still got confused when 
> it tried to build perl with the
> 
> make: *** No rule to make target `miniperl.exe', needed by `all'.  Stop.

I'd suggest you do a comparison of your perl.log with this one:-

http://warped.mentabolism.org/UnixOS2/logs/perl.log

It may provide some pointers...

> so it seems to be moving along. btw, my system is celeron 1.3ghz with 
> 512meg ram and the original error happens even if the build system is 
> the only thing going.

There must be *some* reason for Configure to think that there are too many 
files open...

 
> Ken


-- 
John


**= Email   9 ==========================**

Date:  Sat, 1 Feb 2003 17:34:27 +0000
From:  John Poltorak <jp at manninghammills.org>
Subject:  Re:  Include path

On Sat, Feb 01, 2003 at 04:46:33PM +0100, Thomas Hoffmann wrote:
> It depends:
> 
> #include "ffo.h"
> searches in the current dir first,
> 
> #include <bar.h>
> does not.

This is how I believed it worked...
...but it does not explain how one of my compiles went wrong.

I was attempting to compile regex.dll and my cwd was glibc-2.2.4\posix

which includes the subdirectory 'sys' and within it there is a file called 
types.h.


It appears that this is the file that got loaded by

#include <sys/types.h> 

within regex.c instead of the one from EMX which was on the C_INCLUDE_PATH.

I only managed to load the correct one once I renamed the sys directory 
under the posix directory.

I'd like to understand why this is happening...


> John Poltorak wrote:
> > Is the current directory automatically searched for headers? 
> > 
> > If so, how would you ensure that C_INCLUDE_PATH was searched first?
> > 
> 

-- 
John