Re: Octave & Fortran continued

[Michael Goffioul]

On Tue, Dec 30, 2008 at 7:36 PM, Benjamin Lindner <address@hidden> wrote:
> Michael Goffioul wrote:
>> Just for the record, mixing code gfortran and MSVC is a tough beast
>> and up to now I didn't succeed. Doing the same with g77 was easier
>> as MSVC could link in g77-compiled objects by also linking to libf2c
>> (compiled with MSVC). This provided the needed runtime functions
>> required by g77-compiled code.
>>
>> Given all these problems, I decided to give MinGW a try, using the
>> latest version based on gcc-4.3.0. But recompiling all deps takes
>> time, given the only 30min of free time I have in the evening...
>>
>
> I found that the 'official' mingw gcc-4.3.0 package is quite buggy in the
> sense of packaging.
> I switched to TDM's ports of mingw32/gcc and they work like a charm in my
> case.
> I currently use gcc-tdm-4.3.0-2, which also contains gfortran.
> However I have no experience in the combination mingw/msvc...

Official MinGW gcc is not buggy per-se, but I found 2 problems that are
easy to fix:
1) some headers are missing in the g++ archive, but they are contained
in the full .7z archive
2) libstdc++ is compiled with concept-checks enabled, but some packages
are not concept-checks compliant (like GiNaC); this can be easily worked
around by disabling concept-checks in c++config.h

[Note: I also got some problems in making old libtool work with that
version of gcc, such that I had to re-libtoolize a few packages; maybe
tdm-gcc works better in that area...]

Combining MSVC and gfortran is not really feasible, so I gave up that
path. Instead, I spent some time recently to recompile everything with
MinGW in the same way as I do for MSVC. I recently got a 3.0.3 version
that passes all tests.

While doing that, I started to think we (Benjamin and I) should merge
our efforts, as most of the bits are similar. We should have a single
build framework that is able to generate binaries for MSVC or MinGW.
So, I started to rework my build scripts to use a modular approach
like Benjamin's one, with additional support for automatic package
detection and dependency building. However, it's still embryonic at
this stage, but it'll re-use large parts of Benjamin's script and mines.

Benjamin, are you OK to merge our work? If yes, are you OK that I
make an initial proposal for build scripts and we start from there?

Michael.