[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MSVC compiler patches
From: |
Michael Goffioul |
Subject: |
Re: MSVC compiler patches |
Date: |
Thu, 02 Nov 2006 21:09:55 +0100 |
User-agent: |
Thunderbird 1.5.0.7 (Windows/20060909) |
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.