build %SRC_ROOT/stlport failed by RC.EXE Error: rcdll.dll not found in
path... as well.  But after I include the
%COMPATH\..\Common\MSDev98\Bin in %PATH, everything went fine
again.  It would be better to fix the set_soenv.1 to include 
%COMPATH\..\Common\MSDev98\Bin in %PATH for OpenOffice_1_0 to build
using MSDevStudio98 with out this problem.

The configure process should have written that directory into 
your PATH. In other words, your winenv.bat file should have 
in 'set PATH' the directory '.....\Program Files\Microsoft Visual 
Studio\Common\MSDev98\Bin'

maybe something went wrong with your configure process? 

What compiler path did you (explicitely) enter when asked? 

The work environment I used is as follow:
MS-Visual Studio 6.0 with MSDN-4.0-SP. at D:\MVS60
MS-Assembler with upgraded at D:\98DDK\Bin\Win98
JDK 1.3.1 at C:\java\j2sdk1.3.1_02
cygwin-b20 with bison.sample upgrade and perl5 symbolic link
at D:\cygnus\cgywin-b20
OpenOffice source tree (CVS -r OpenOffice_1_0)

I do as follow:
> cd config_office
> bash configure --with-lang=ALL
> ..... Java Home directory: //c/java/j2sdk1.3.1_02
> ..... M$ C/C++ compiler home directory: //d/MVS60/VC98
> ..... assembler is located: //d/98DDK/Bin/Win98

"set_soenv" gets called with following settings:
$COMPATH=NO_CL
$_gcc_include_path=NO_GCC_INCLUDE
$_gxx_include_path=NO_GXX_INCLUDE
$JAVA_HOME=NO_JAVA_HOME
$TCSH=NO_TCSH
$PERL=//D/Perl/bin/
$x_libraries=no_x_libraries
$x_includes=no_x_includes
$_LOCAL_SOLENV=DEFAULT
$_LOCAL_SOLVER=DEFAULT
$upd=641
$CYGWIN=//d/cygnus/CYGWIN~1/H-I586~1/bin
$STLPORT4=NO_STLPORT4
$enable_xprint=TRUE
$with_lang=,ALL,
$with_asm_home=NO_ASM_HOME
$with_unzip_home=UNZIP_IN_PATH
$MINGWIN32=0
$with_use_shell=4nt
$USE_GCC3=FALSE

And parts of the output of "winenv.bat" looks like this
rem OpenOffice 641 build environment file for: WINNT. 
rem Generated on: Sat Jun 15 00:06:30  2002 
rem Source this file to set up the build environment. 
rem 1. exec (t)csh 
rem 2. source winenv.bat 
rem #################################################################
set SRC_ROOT=d:\cases\OpenOffice\oo_1.0_src 
set JAVA_HOME=c:\java\j2sdk1.3.1_02 
set PERL_PATH=D:\Perl\bin\ 
set JDKLIB=c:\java\j2sdk1.3.1_02\lib 
set STLPORT4=NO_STLPORT4 
set ASM_PATH=d:\98DDK\Bin\Win98 
set UNZIP_PATH=UNZIP_IN_PATH 
...
rem 
rem Platform dependent constant values. 
rem 
set SOLAR_JAVA=TRUE 
set COM=MSC 
set COMPATH=d:\MVS60\VC98 
...
rem 
rem Variable values. 
rem 
set CYGWIN=d:\cygnus\CYGWIN~1\H-I586~1\bin 
set PERL=D:\Perl\bin\\perl.exe 
set UPD=641 
set SOLARUPD=641 
set WORK_STAMP=SRC641 
set TF_ONE51=SRC641 
...
set
PATH=.;%SOLARVER\%UPD\%INPATH\bin;%SOLARENV\bin;%SOLARENV\%OUTPATH\bin;%JAVA_HOME\bin;%COMPATH\bin;%PERL_PATH;%ASM_PATH;%SRC_ROOT\dmake;d;C:\cygnus\CYGWIN~1\H-I586~1\bin;D;C:\Perl\bin\;C;C:\WINNT\system32;C;C:\WINNT;C;C:\WINNT\System32\Wbem;C;C:\MSSQL7\BINN;D;C:\MVS60\VC98\Bin;d;C:\bin;d;C:\usr\local\bin;c;C:\GNU\WinCvs;C;C:\java\JMF21~1.1\lib;D;C:\Tools\SSH
Secure Shell;D;C:\Program Files\Adabas\bin;D;C:\Program
Files\Adabas\pgm;;C:\;;C:\;C;C:\boot.dos

Then I have to replace all the D;C:\ to D:\.. using text editor on
hand (Check the %PATH content and you will see what I mean -- for
example D;C:\MVS60\VC98\Bin is what I input as //d/MVS60/VC98/Bin )
and to get the winenv.bat to run in 4NT.EXE.

The %PATH dose not have "D;C:\MVS60\VC98\..\Common\MSDev98\Bin " or
"D:\MVS60\VC98\..\Common\MSDev98\Bin" included.

I have check the set_soenv.1 v0.1,07-06-2000 perl source which  dose
not seems to have a any %COMPATH\..\Common\MSDev98\Bin to $PATH
variable either.

Hope this help, and if there is need for helping to modify the
set_soenv.1 or current configuration/build procedure on Win32s for
OpenOffice.org, I am able, as well as welling to do so.
 

The C;D:\ entries are funny, don't know how this happens, 
but hand-editing solves that. 

The actual problem is your compiler path. There is an if-block 
in set_soenv.1 which I guess is responsible for that at line 
1088. That puts COMPATH explicitely into your path. However, 
I guess that the MSVC++ Environment does path settings by itself 
(including the paths you're missing). Maybe the location of your 
VC++ compiler is the reason for this. Your location for that doesn't 
look 'standard' to me - my COMPATH is  
c:\PROGRA~1\MICROS~3\VC98 (the numbers depend on the installation). 
But I'm not an expert on this. 

Either you have to change your compiler installation, or that 
if-block (or rather the statement in it) has to be refined 
(I mean the statement '$PATH .= $ps.'$COMPATH'.$BIN;')

I cc Ause on this to get another opinion. 

this looks like two completely different errors. the funny "drive
letters" should be fixed by replacing the '$cygwin eq "b"' section
with the following lines:
   if ( $cygwinver eq "b" )
   {  
      $variable =~ s/\//\\/g;
      $variable =~ s/\$/%/g;
      $variable =~ s#([:;])(\w):\\#$1\\\\$2\\#g;
      $variable =~ s/:/;/g;
      $variable =~ s/\\\\(\w)\\/$1:\\/g;
      $variable =~ s/^\\/$SYSTEMDRIVE\\/;
      $variable =~ s/;\\/;$SYSTEMDRIVE\\/g;
   }

did the old version ever work?

for the second error, the missing path entry, there seems to be an
other directory needed for building which isn't yet covered by the
configure process. i'm wondering what kind of binaries belong to which
directory. did you try specifying the compiler home as
"//d/MVS60/Common/MSDev98" ?

this looks like two completely different errors. the funny "drive
letters" should be fixed by replacing the '$cygwin eq "b"' section
with the following lines:
   if ( $cygwinver eq "b" )
   {  
      $variable =~ s/\//\\/g;
      $variable =~ s/\$/%/g;
      $variable =~ s#([:;])(\w):\\#$1\\\\$2\\#g;
      $variable =~ s/:/;/g;
      $variable =~ s/\\\\(\w)\\/$1:\\/g;
      $variable =~ s/^\\/$SYSTEMDRIVE\\/;
      $variable =~ s/;\\/;$SYSTEMDRIVE\\/g;
   }

did the old version ever work?

for the second error, the missing path entry, there seems to be an
other directory needed for building which isn't yet covered by the
configure process. i'm wondering what kind of binaries belong to which
directory. did you try specifying the compiler home as
"//d/MVS60/Common/MSDev98" ?

mspdb60.dll -- required by CL.EXE (M$ C/C++ compiler)
rcdll.dll -- required by RC.EXE (M$ 32bits resource compiler)

I have tried with //d/MVS60/Common/MSDev98/Bin as %COMPATH and it
didn't work either.

I then go ahead rewrite part of the 'set_soenv.1' - r1.70 to fix the
problems.  It has been tested on both cgywin-1.X.X and 
cgynus-b20 to generate correct winenv.bat for 4NT.EXE with out problem.

I include the patch as follow and hope that it helps.

Best regard.

Scott L. H. Yuan

Index: set_soenv.1
===================================================================
RCS file: /cvs/oo/tools/config_office/set_soenv.1,v
retrieving revision 1.70
diff -r1.70 set_soenv.1
3c3,4
< # Version:     0.1
---
> # Version:     0.1 
> # $Id$
634a636
>    $JAVA_HOME =~ s/[\s\/]+$//;	# remove trailing \n or \/ if there is any.
1063a1066
>    $PERL_PATH         =~ s/[\/\s]+$//; 	# Remove trailing / and spaces
1122a1126,1136
>    } 
>    elsif ( $USE_SHELL eq "4nt" )
>    {
>       # using 4NT.exe with Win32-Perl or similar
>       
>       # To make things easier, replace all \w{1}:\ to \w{1}|/ then 
>       # shift it back at once after dealing with the : to ;
transformation.
>       # in WinFormat().
>       $noldPATH =~ s!(\w):!$1|!g;
>       $noldPATH =~ s/\\/\//g;
>       $noldPATH =~ s/;/:/g;
1126c1140
<    $COMPATH_ROOT      =~ s/\/vc98$//;
---
>    $COMPATH_ROOT      =~ s/\/vc98$//i;
1146c1160
<    if ( ! ( $noldPATH =~ /(?:[:]|\A)(?:$COMPATH)(?:[:]|\Z|$ds)/ ) )
---
>    if ( ! ( $noldPATH =~ /[^\/]*\b$COMPATH\b[^\/]*/ ) )
1148c1162
< 	$PATH .= $ps.'$COMPATH'.$BIN;
---
>       $PATH .= $ps.'$COMPATH'.$BIN;
1149a1164,1166
>    # for MS-Visual Studio 6.0 to find mspdb60.dll (need by CL.EXE
C/C++ Compiler) 
>    # and rcdll.dll (need by RC.EXE -- 32 bit Resource Compiler)
location.
>    $PATH .= $ps.$COMPATH_ROOT.'/Common/MSDev98/Bin';
1152c1169
<    if ( ! ( $noldPATH =~ /(?:[:]|\A)(?:$PERL_PATH)(?:[:]|\Z|$ds)/ ) )
---
>    if ( ! ( $noldPATH =~ /[^\/]*\b$PERL_PATH\b[^\/]*/ ) )
1763,1765c1780,1789
<    # Check if the last character is a '/'.
<    if ( $retrn =~ /\/$/ ) 
<    {  chop( $retrn );
---
> 
>    if ($platform eq "$Winnt")
>    {  # The Perl 5.XXX file tester on Win32s system behave the same 
>       # on cgywin-build and MSwin32-builds and both using C:// and
D://.. 
>       # syntax (Viva the PERL!)
>       $retrn = $_[ 0 ];
>       $retrn =~ s!^/+([c-z])/!$1\|/!i;          # for cgywin-b20
>       $retrn =~ s!^/+cygdrive/([c-z])/!$1\|/!i; # for cgywin-1.X.X
> 
>       # Note: we use |/ to represent :/ to avoid conflict at
WinFormat();
1766a1791
>    
1767a1793,1797
>    $retrn =~ s!/+!/!g;
>    
>    # kill the last '/','\','\n' if they exists.
>    $retrn =~ s![\s/\\]+$!!;
> 
1797,1798c1827,1839
<    else 
<    {  return "true";
---
>    elsif( $platform eq $Winnt )
>    {  
>       # remember we've use |/ to replace :/ to 
>       # avoid conflict in WinFormat();
>       
>       $dir =~ s!\|!:/!;  # change it back here!
>       unless( -d $dir )
>       {  AddWarning( "set_soenv",
>                      "Directory $_[ 0 ] does not exist on your
system." );
>          return "false";
>       }
> 
>       return "true"
1834c1875,1877
<       {  printf("%-12s %-17s %-10s %-39s\n", "The variable", $_[ 0
], "is set to:", $_[ 1 ]) ; # to stdout
---
>       {  
>          printf("%-12s %-17s %-10s %-39s\n", 
>                 "The variable", $_[ 0 ], "is set to:", $_[ 1 ]);  #
to stdout
1924c1967,1970
<    {  $variable =~ s/\//\\/g;
---
>    {  $variable =~ s!//([c-z])/!$1\|/!gi;          # for cgywin-b20
>       $variable =~ s!/+cygdrive/([c-z])/!$1\|/!gi; # for cgywin-1.X.X
>       $variable =~ s/:/;/g; 
>       $variable =~ s/\//\\/g;
1926,1929c1972,1974
<       $variable =~ s/:/;/g;
<       $variable =~ s/^\\\\(\w)\\/$1:\\/g;
<       $variable =~ s/^\\/$SYSTEMDRIVE\\/;
<       $variable =~ s/;\\/;$SYSTEMDRIVE\\/g;
---
>       # $variable =~ s/^\\\\(\w)\\/$1:\\/g;
>       # $variable =~ s/^\\/$SYSTEMDRIVE\\/;
>       # $variable =~ s/;\\/;$SYSTEMDRIVE\\/g;
1973a2019
>    $variable =~ s!\|\\!:\\!g;

oh, there is quite a lot changed. could you please supply a context
diff (generated with "... diff -c ..." that can be applied with the
patch command?
and other issue to keep in mind is wether the used perl is window
native or the cygwin one. both are quite different in filename
handling (unix vs. windows).

Created attachment 2001 [details]
Patch for set_soenv.1-1.70 to generate correct winenv.bat

Attached is a diff -c version of the patch mentioned before.  

I have this patch agains the set_soenv.1 using both ActivePERL.exe
5.6.1 (Win32s Native) and PERL comes with cygwin-1.5.* (cygwin) to
test it, and they all work fine.

As you mentioned about the differences of file name handling between
the UNIX vs Win32s PERL, I specially do a test on my computer
(Windows2000 and 98SE) with the following script

print $^O, "\n";
print `uname`, "\n";
if( -d 'c:/java/j2sdk1.3.1_02/' ) {
   print 'Here!!';
}
# There is a directory name c:/java/j2sdk1.3.1_02
This is what ActivePerl.exe (Win32s Native) return under cygwin-b20:
bash-2.02$ perl t
MSWin32
CYGWIN_NT-5.0

Here!bash-2.02$

And here is what Perl comes with Cygwin-1.* (cgywin) return under
cgywin-1.*:
cgywin
CYGWIN_NT-5.0

Here!!
Administrator@BAOBAY ~

It seems that PERL is doing a very good job on UNIFYING 
the file handling on MSWin32 and cgywin.  Therefore we 
shall be save to using the D: (driver:) type notation for all
"Win32s" environment (both Native and cygwin).

Including '$COMPATH_ROOT\Common\MSDev98\Bin' in %PATH is always a good
thing to do since OUT-OF-BOX M$-Visual-Studio 6.0 installation require
it exists in %PATH% to function, but do not expect
M$-Visual-Stuido-.NET to be the same.

Created attachment 2004 [details]
small changes to prev. patch

there are some small changes to your patch. please confirm that it
still fixes the bug on your side. if it's ok, i'll commit it after
removing the lines now commented out

Created attachment 2006 [details]
minor change on : replacement from | to ~

I have test the set_soenv.1.patchxx with both CYGWIN-PERL and 
NATIVE-PERL and the if statment:
!    if ( ! ( $noldPATH =~
/[^\/]*\b$COMPATH_ROOT\/Common\/MSDev98\/Bin\b[^\/]*/ ) )
!    {
!        $PATH .= $ps.$COMPATH_ROOT.'/Common/MSDev98/Bin';
     }
for some reason, is not doing what expects.  After tracing the cause
it prove that the use of |/ to replace :/ for the driver letter in
Win32s is not a good idea, since the | is the logical OR in PERL
regular expression.  I have something like ...;D/Window... in the PATH
and the $COMPATH_ROOT is something like D|/MVS60.. which then I will
get match of 'D' then the
!        $PATH .= $ps.$COMPATH_ROOT.'/Common/MSDev98/Bin';
will get escaped.  The same to the $PERL_PATH and other, so I go ahead
replace the |/ to ~/ in the patch you've provided, everything seems to
work for me now.

changing drive names to "~/" is quite likely to cause problems when
using a win/tcsh combination.
i would still prefer the aproach of changing all ":" to ";" and
detecting drives from the context ( begin of line or pathseperator,
one char, pathsep. and dirseperator ).

Created attachment 2018 [details]
Replace ~/ to !/

As for your concern, I've change the ~/ to !/ and hope this help.

last patch fails when using cygwin perl. imported path
(windows/system32 etc.) and variables for tools in "solenv" (e.g.
DELIVER) are not correct. could you crosscheck this on your side?

Hi ause, this patch fails when you use cygwin-perl. The following
lines are from Scotts latest patch (id=2018).

--- 1123,1143 ----
        $noldPATH =~ s#(\w):#/cygdrive/$1#g;
        $noldPATH =~ s/\\/\//g;
        $noldPATH =~ s/;/:/g;
+    } 
+    elsif ( $USE_SHELL eq "4nt" )
+    {
+       # using 4NT.exe with Win32-Perl or similar
+       
+       # To make things easier, replace all \w{1}:\ to \w{1}!/ then 
+       # shift it back at once after dealing with the : to ; 
transformation.
+       # in WinFormat().
+       $noldPATH =~ s{(\w):}{$1!}g;
+       $noldPATH =~ s/\\/\//g;
+       $noldPATH =~ s/;/:/g;
     }
     
     $COMPATH_ROOT      = $COMPATH;
---------
In the 7th line is written:
+       # using 4NT.exe with Win32-Perl or similar
This is wrong, you are in the cygwin-perl section, the if case above
is: NON-cygwin-perl AND 4nt.
So, you use cygwin-perl, this means you have ":" as path separator
and in this section they all get replaced with "!". This breaks
the path parsing logic.

And I also agree with Armin, if you have MSVC+ installed then you
also should have the environement for it set before you start winenv.
./configure shouldn't even try to catch every different directory MS
invents for different MSVC+ versions.

Created attachment 2047 [details]
Fix WinFormat() with cygwin b20

Hi!

The attachement id=2047 should fix the problem with writing
the correct dos-style paths to winenv.bat when you use cygwin b20.

It also includes some parts of Scotts patch, but not the parts
concerning MSVC.

It still works with cygwin 1.3.10 and cygwin perl, but should also
work with cygwin b20 and native NT perl. I cannot test that!

Bye
   Volker

Created attachment 2074 [details]
last patch + msvc path + fixing tool variables (e.g. DELIVER)

this patch contains the last patch of volker, the additional path to
some compiler dlls and fixes the garbling of some environment
variables to access tools (cygwin perl only).
regarding the path issue, two path entries is acceptable for me. maybe
the next path issues will get me changing my mind...
if this patch doesn't introduce new problems, i would like to commit it.

Please notice that "scottyuan" is now "yuansc" 

I have test the Volker's patch under Cgywin-b20 bash with
Native-Perl on Win32s and is working right for me, and thanks
Volker for pointing out and fixed the problem in the last patch.

applied "set_soenv.1.patch5" and commited result.

I suppose you guys did not commit this to 1.1 RC3? I just got it from 
CVS and encountered this problem. 
With RC2 I did not have this problem, using exactly the same setup. 

Oh wait, this is not really a recent issue, and maybe I am not seeing 
exactly the same problem. I'll just commit a new issue.