Re: MSVC compiler patches

[Michael Goffioul]

John W. Eaton a écrit :
>   1.4 Unix-to-MSVC compilation scripts
>   ------------------------------------
>
>   These scripts provide a UNIX-like compilation interface, based on the
>   Microsoft compilation tools.  The package is available from the Octave
>   web site.
>
> We haven't put anything in place yet.  Which scripts do we need to
> make available from the web site?  If they are required by Octave the
> build process, then maybe we should include them with the Octave
> sources?  Is it just the cccl script?
>   

It's a package that includes cc-msvc, ar-msvc and ranlib-msvc. Those 
scripts are able to
compile octave, readline (shared) and glob (static). I sent them a few 
days ago. I'll resend
them tomorrow with the latest versions I have.

>   1.5 Glob library
>   ----------------
>
>   Octave also requires a filename globbing library.  This library is
>   typically part of the C library on UNIX systems, but is not part of
>   the Windows or MSVC run-time libraries.  You can find a glob package
>   on the Octave website.
>
> OK, I need to do this.
>   

Please use the modified package I sent. It contains modifications to 
make it compilable
with the Unix-to-MSVC compilation scripts.

>   1.7 F2C
>   -------
>
>   As there exist no free MSVC-like fortran compiler, the compilation
>   process makes use of the f2c utility and the libf2c library.
>
> Shouldn't it be possible to use g77 or gfortran to compile the Fortran
> bits?
>   

Maybe, I didn't try. Do you gain something by using g77? Is it faster?

>   2. Compilation
>   ==============
>
>   Copy the following lines into a shell script and execute it (note that
>   you can use whatever you want as installation directory):
>
>   --- BEGIN (cut me)
>   #!/bin/sh
>   if ! grep "__declspec(noreturn dllimport)" configure 2>&1 > /dev/null; then
>     echo "Pre-processing configure script..."
>     sed -e "s/'extern \"C\" void exit (int);'/'extern \"C\" __declspec(noreturn dllimport) 
> void exit (int);' 'extern \"C\" void exit (int);'/g" configure \
>       > configure.tmp
>     mv configure.tmp configure
>   fi
>
> What is the purpose of doing this?
>   

This works around a problem I have with autoconf-2.59 (MSYS and cygwin) 
and the
MSVC compiler, regarding the exit() function. The configure script tried 
to find the right
exit() declaration by trying several possibilities. Normally, it ended 
up with finding
"void exit(int)". The problem then appeared in C++ mode of the configure 
script: in that
case, a "exit" declaration was added to the test program, which didn't 
match the actual
declaration found in stdlib.h and the C++ just failed. This lead to test 
failure for all tests
done in C++ mode.

I just checked the configure script generated by autoconf-2.60 and I 
couldn't find the
same code for "exit", so maybe this has changed. However, when porting 
octave, I
used version 2.59 and I had the edit the configure script every time I 
ran autoconf.
That's why I created a script to perform this step.

>   CC=cc-msvc CXX=cc-msvc NM="dumpbin -symbols" AR=ar-msvc RANLIB=ranlib-msvc \
>     ./configure --build=i686-pc-msdosmsvc --prefix=/usr/local/octave-vc8-debug 
> --with-f2c
>
> Since this last line just sets a variable in a shell script, I don't see
> that it has any effect.  At least on Unixy systems, executing a shell
> script can't have any effect on the parent environment.
>   

It does not have an effect on the parent environment, but it does have 
one in the
environment in which the configure script runs.

> If running this script is necessary, then shouldn't this be included
> as part of the Octave build process instead of hidden in a README
> file?
>   

The user is expected to read the README's, right? ;-)
In my case, I put the above lines into a configure.vc script. But you 
can type it at the bash
prompt. The important things in the command is:
   - setting CC and CXX correctly (for the moment, the use of NM does 
not lead to
     useful results)
   - defines the build host as being ix86-pc-msdosmsvc

>   2.1 MSYS
>   --------
>
>   When building from the MSYS shell and CVS, everything should run fine
>   until building the doc.  At some point, TeX might ask you for the
>   location of the file conf.texi.  If this happens, simply type
>   "../conf.texi" and the process should continue.
>
> Is this a bug in the texi2... scripts?  If so, we should probably
> report it.
>   

In MiKTeX, texi2dvi is an executable, not a script. I'm not using a 
bleeding edge version of
MiKTeX, so maybe the problem has ben already fixed. Note that the 
problem only appear
when generating PDF; I think the problem is in pdftex.

>   2.2 Cygwin
>   ----------
>
>   Building from the Cygwin shell and CVS produces more compile-time
>   errors when generating the documentation.  Here are some fixes that
>   should work around most problems:
>
>     * edit "run-octave" and add the 2 lines right after the definition of
>       LOADPATH and IMAGEPATH:
>
>         LOADPATH=`cygpath -d -p $LOADPATH`
>         IMAGEPATH=`cygpath -d $IMAGEPATH`
>
> We could just add these lines to the script.  They would need to be
> added only when appropriate though, and I'm not sure what is the right
> condition to check.
>   

This is exactly the problem. These lines are only required when 
cross-compiling from the
cygwin shell to MSVC. I don't know exactly how to test for this in a 
reliable way.

>   3. Installation
>   ===============
>
>   The compiled Octave is relocatable.   This means that whetever
>   installation dir you chose at configure time, you can move the whole
>   installation directory to another location without any problem.   Octave
>   should still run OK.
>
> There are still some problems with this.  The variables in
> octave_config_info need to have OCTAVE_HOME substituted appropriately,
> and we need to have a solution for the scripts like mkoctfile and
> octave-config that also rely on paths.  In another message, I asked:
>   

If you don't compile anything, then the problem with octave_config_info 
mismatch is only
visible in the fact that the inputrc (for readline) is not parsed. For 
the scripts like mkoctfile,
I still didn't find a good solution. Porting the script to a batch file 
is rather impossible due
to the syntax limitations (Matlab under Windows solved this by including 
a full perl distro
in its installation...). I'd like to find a solution that does not 
require a MSYS shell...

Michael.