bugGNU Octave - Bugs: bug #39446, MXE-Octave: LAPACK build mixes...

 
 

bug #39446: MXE-Octave: LAPACK build mixes MinGW and MSVC

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Tue 09 Jul 2013 12:38:27 PM UTC
   
 
Category:  Configuration and Build System Severity:  1 - Wish
Priority:  3 - Low Item Group:  Build Failure
Status:  Wont Fix Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 03 Jul 2016 07:43:59 AM UTC, comment #23: 

OK, I'll close it.
If anyone wants to try again with MSVC this bug report can be reopened.


Philip Nienhuis <philipnienhuis>
Group Member
Sat 02 Jul 2016 09:11:50 PM UTC, comment #22: 

Sounds like it can be closed, but I'll let Philip do it.

Rik <rik5>
Group administrator
Sat 02 Jul 2016 08:54:17 PM UTC, comment #21: 

I don't know, you reported this bug :)

My understanding was this bug was about attempting to build with mxe-octave natively on Windows, but some of the build makefiles were accidentally picking up MSVC files that happened to be installed on your system.

Mike Miller <mtmiller>
Group Member
Sat 02 Jul 2016 08:24:57 PM UTC, comment #20: 

... with "won't fix" ?

Philip Nienhuis <philipnienhuis>
Group Member
Sat 02 Jul 2016 08:24:38 PM UTC, comment #19: 

AFAIK MSVC doesn't work anymore to build mxe-octave natively on Windows.
Shall we just close this report?

Philip Nienhuis <philipnienhuis>
Group Member
Thu 05 Feb 2015 02:43:54 AM UTC, comment #18: 

@Philip: The mailing lists are extremely flaky right now.  Try using -email is unavailable- rather than @octave.org.  It seemed to help for me.

Rik <rik5>
Group administrator
Wed 04 Feb 2015 10:06:04 PM UTC, comment #17: 

Sure there are probably loads of hard to reconcile build environments installed side-by-side on many dev systems.

As Michael G pointed out, MSVC is especially creepy as it is detected through the Windows registry rather than being in the PATH or so. Yet I wouldn't be surprised if there are configure checks that can access the Windows registry as well.

[OT]
What's wrong with the mailing lists? I can't post anymore since a few days; using Nabble I can see my own posts and many many other posts with the banner "Not accepted by the mailing list yet"; and I get replies about:

The message could not be delivered, the mail server at mx2.sub5.homie.mail.dreamhost.com [208.113.200.128] said:
<<< 550 5.1.1 <octave-maintainers@octave.org>: Recipient address rejected: User unknown in virtual alias table


Apologies for this, I just ask here as I can't seem to get anything posted now. Nothing gets through.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 04 Feb 2015 08:35:00 PM UTC, comment #16: 

I'm cross compiling usually on Linux. Native Windows was just an  exercise on can it be done :)


John Donoghue <lostbard>
Group Member
Wed 04 Feb 2015 07:10:57 PM UTC, comment #15: 

Only fractionally serious :) And thanks for implicitly confirming my summary that this is about building natively on Windows.

And I don't mean building on Windows at all, I meant the combination of trying to build with MXE / MinGW while having MSVC installed and detected by parts of the build...

I would say someone's Linux environment that has gcc and Intel icc and CUDA and ATLAS and clang all configured and mixed in together is also invalid.

I'm sure if someone is so motivated, they can figure out what parts of the environment are being detected and picked up by LAPACK and whatever other libraries this might affect. And it may end up just being a note like "here's what to take out of your PATH or environment to make this work".

Mike Miller <mtmiller>
Group Member
Wed 04 Feb 2015 07:01:05 PM UTC, comment #14: 

"invalid build environment" - don't say that too loud.

Some devs are still building natively on Windows, at least until recently (John D). I see no reason why that shouldn't be supported.
Perhaps the classdev developer (Michael G) is still building with MSVC... (the whole MSVC setup in MXE was his anyway)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 04 Feb 2015 06:51:56 PM UTC, comment #13: 

This bug is about building Octave using the MXE build system on a Windows system that just happens to have MSVC installed, right?

We could easily just consider this an invalid build environment ;)

Lowering priority and setting to postponed since we have no way to test or do anything about this at the moment. Also any official Octave binaries will almost certainly be cross-compiled for Windows on a Linux build host.

Mike Miller <mtmiller>
Group Member
Wed 04 Feb 2015 06:11:12 PM UTC, comment #12: 

On my build boxes I have no MSVC installed; at work (where I do have MSVC) I usually have no time for Octave development.
So all in all I can't test right now.

Anyway I think this bug report is about the MXE build system rather than Octave itself.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 04 Feb 2015 04:23:38 AM UTC, comment #11: 

The last commentary on this bug was in July, 2013.  Is this bug still relevant?  I'm trying to find out which bugs may need to be fixed before the 4.0 release.

Rik <rik5>
Group administrator
Wed 10 Jul 2013 07:58:00 PM UTC, comment #10: 

Oh, come on Philip, look further... ;)

It starts at line 50 in GNUtoMS.cmake (as of lapack-3.4.2): it looks for vcvars32.bat in PATH, then it looks into the registry. And that's your problem: even if VS tools are not in your PATH, this cmake script will still manage to detect your VS installation.

But apparently it doesn't work as expected. The cmake script should create a lib.bat wrapper (look into GNUtoMS subdir) that is supposed to setup VS tools, then call lib.exe. But it didn't work for you.

Michael Goffioul <goffioul>
Wed 10 Jul 2013 07:26:44 PM UTC, comment #9: 

@John D:  MSVC is installed on that particular Win 7 box.

Today I had a few minutes to peek there at GNUtoMS.cmake (& other files in that subdir) but it gave me no clue how it pulls in MSVC (but that's obviously my ignorance), nor how to avoid it.

In a private conversation with Michael G. I mentioned that the LAPACK README indicates that: "LAPACK can be installed with make. Configuration haev to be set in make.inc file. ..." (rest of spelling errors ignored)
...so maybe it's a better option to build LAPACK w/o invoking cmake.

FWIW, I remember that not so long ago a number of Linux distros had miscompiled LAPACK libs, and IIRC LAPACK could easily be rebuilt using plain configure-make-make install sequences.
(in that particular case it was just 3 or 4 modules that had to be rebuilt w/o optimization)

(re-titled OpenBLAS => LAPACK)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 10 Jul 2013 12:44:03 AM UTC, comment #8: 

Is MSVC or anything outides of the mingw paths in your path variable?

John Donoghue <lostbard>
Group Member
Tue 09 Jul 2013 09:32:36 PM UTC, comment #7: 

Well, the cmake file I mentioned is part of LAPACK sources. OpenBLAS does not use cmake, BUT as part of the compilation process, it can generate an optimized LAPACK library. It does that by downloading regular LAPACK sources, patching them and compiling the library. If it uses cmake to compile LAPACK, then the problem will also occur. But nevertheless, the problem is still in LAPACK.

Michael Goffioul <goffioul>
Tue 09 Jul 2013 08:36:42 PM UTC, comment #6: 

It's definitely not only LAPACK - the whole bug report was initiated because it started with identical issues with OpenBLAS.

But I'd agree it look like a cmake problem. Apparently cmake likes MSVC better than MinGW.
I'd suppose cmake can be instructed to choose alternative build tools.

I'm busy with other stuff now, maybe later on I can have a closer look at it.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 09 Jul 2013 08:10:27 PM UTC, comment #5: 

Technically, those import libs are not needed by MinGW. I think it's a CMAKE problem only, and probably a LAPACK problem only.

Michael Goffioul <goffioul>
Tue 09 Jul 2013 07:14:24 PM UTC, comment #4: 

That's what I suspected.

Is there a way to point to the MinGW build tools rather than VS?

Perhaps CMAKE/GNUtoMS.cmake needs to be patched depending on desired build tools?
(can't look now, it was on my machine at work - hopefully I have some time for it tomorrow).

Same for OpenBLAS, of course. And any other SW dependency package needed for the MXE builds that behaves the same ... (Qt?)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 09 Jul 2013 01:47:48 PM UTC, comment #3: 

I think it's trying to use VS tools to generate the MSVC-compatible import library file (.lib). And it tries to do it, because it detected that VS was installed. If you look into CMAKE/GNUtoMS.cmake (inside lapack source tree), you should see what I mean.

Michael Goffioul <goffioul>
Tue 09 Jul 2013 12:55:42 PM UTC, comment #2: 

Same happens for LAPACK (now with (plain) BLAS selected).

FYI, on this PC MSVC 2010 express is installed. Would configure pick that up automatically, rather than MinGW? If so, is there a configure setting to enable MSVC or MinGW selection?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 09 Jul 2013 12:48:28 PM UTC, comment #1: 

FYI, what I ahve is:

$ hg summary
parent: 3125:0457ec42059e tip
 dist-files.mk: add new patches for pstoedit

Philip Nienhuis <philipnienhuis>
Group Member
Tue 09 Jul 2013 12:38:27 PM UTC, original submission:  

Native build of MXE-Octve w --enable-openblas give this in the LAPACK build log:


make[1]: Entering directory `/home/Nienhu01/mxe-octave'
rm -rf   '/home/Nienhu01/mxe-octave/tmp-lapack'
mkdir -p '/home/Nienhu01/mxe-octave/tmp-lapack'
cd '/home/Nienhu01/mxe-octave/tmp-lapack' &&  tar xzf '/home/Nienhu01/mxe-octave/pkg/lapack-3.4.2.tgz'
test ! -d '/home/Nienhu01/mxe-octave/src/lapack' || cp -a '/home/Nienhu01/mxe-octave/src/lapack' '/home/Nienhu01/mxe-octave/tmp-lapack'
cd '/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
cd '/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2' && cmake -G 'MSYS Makefiles' -DCMAKE_TOOLCHAIN_FILE='/home/Nienhu01/mxe-octave/usr/i686-pc-mingw32/share/cmake/mxe-conf.cmake' -DCMAKE_Fortran_FLAGS='' .
-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler: C:/MinGW/bin/gfortran.exe
-- Check for working Fortran compiler: C:/MinGW/bin/gfortran.exe  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether C:/MinGW/bin/gfortran.exe supports Fortran 90
-- Checking whether C:/MinGW/bin/gfortran.exe supports Fortran 90 -- yes
-- Found PythonInterp: C:/Python27/ArcGIS10.1/python.exe (found version "2.7.2")
-- Looking for Python found - TRUE
-- Using Python version 2.7.2
-- Reducing RELEASE optimization level to O2
-- Looking for Fortran NONE - found
-- Looking for Fortran INT_CPU_TIME - found
-- Looking for Fortran EXT_ETIME - not found
-- Looking for Fortran EXT_ETIME_ - not found
-- Looking for Fortran INT_ETIME - found
-- --> Will use second_INT_ETIME.f and dsecnd_INT_ETIME.f as timing function.
-- Using supplied NETLIB BLAS implementation
-- Using supplied NETLIB LAPACK implementation
-- Building Single Precision
-- Building Double Precision
-- Building Complex Precision
-- Building Double Complex Precision
-- Configuring done
-- Generating done
-- Build files have been written to: C:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2
make -C '/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/SRC' -j '1' VERBOSE=1 install
make[2]: Entering directory `/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/SRC'
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 && /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/usr/bin/cmake.exe -H/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 -B/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 --check-build-system CMakeFiles/Makefile.cmake 0
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 && /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/usr/bin/cmake.exe -E cmake_progress_start /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/CMakeFiles /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/SRC/CMakeFiles/progress.marks
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 && make -f CMakeFiles/Makefile2 SRC/all
make[3]: Entering directory `/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
make -f BLAS/SRC/CMakeFiles/blas.dir/build.make BLAS/SRC/CMakeFiles/blas.dir/depend
make[4]: Entering directory `/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/usr/bin/cmake.exe -E cmake_depends "MSYS Makefiles" /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2 /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC/CMakeFiles/blas.dir/DependInfo.cmake --color=
Dependee "c:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC/CMakeFiles/blas.dir/DependInfo.cmake" is newer than depender "c:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC/CMakeFiles/blas.dir/depend.internal".
Dependee "c:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "c:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC/CMakeFiles/blas.dir/depend.internal".
Scanning dependencies of target blas
make[4]: Leaving directory `/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
make -f BLAS/SRC/CMakeFiles/blas.dir/build.make BLAS/SRC/CMakeFiles/blas.dir/requires
make[4]: Entering directory `/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
make[4]: Nothing to be done for `BLAS/SRC/CMakeFiles/blas.dir/requires'.
make[4]: Leaving directory `/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
make -f BLAS/SRC/CMakeFiles/blas.dir/build.make BLAS/SRC/CMakeFiles/blas.dir/build
make[4]: Entering directory `/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2'
/C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/usr/bin/cmake.exe -E cmake_progress_report /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/CMakeFiles
[  0%] Building Fortran object BLAS/SRC/CMakeFiles/blas.dir/isamax.f.obj
:
<...many FORTRAN modules compiled...>
:
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC && /C/MinGW/bin/gfortran.exe  -Dblas_EXPORTS -O2   -c /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC/xerbla_array.f -o CMakeFiles/blas.dir/xerbla_array.f.obj
Linking Fortran shared library ../../bin/libblas.dll
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC && /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/usr/bin/cmake.exe -E remove -f CMakeFiles/blas.dir/objects.a
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC && /C/MinGW/bin/ar.exe cr CMakeFiles/blas.dir/objects.a @CMakeFiles/blas.dir/objects1.rsp
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC && /C/MinGW/bin/gfortran.exe     -shared -o ../../bin/libblas.dll -Wl,--out-implib,../../lib/libblas.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/blas.dir/objects.a -Wl,--no-whole-archive  -Wl,--output-def,blas.def
cd /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/BLAS/SRC && /C/MinGW/msys/1.0/home/Nienhu01/mxe-octave/usr/bin/cmake.exe -Dlib="C:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/CMakeFiles/GNUtoMSlib.bat" -Ddef="blas.def" -Ddll="../../bin/libblas.dll" -Dimp="../../lib/libblas.dll.a" -P "C:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/CMAKE/GNUtoMS/lib.cmake"
Setting environment for using Microsoft Visual Studio 2010 x86 tools.

ERROR: Cannot determine the location of the VS Common Tools folder.

'lib' is not recognized as an internal or external command,
operable program or batch file.
CMake Error at C:/MinGW/msys/1.0/home/Nienhu01/mxe-octave/tmp-lapack/lapack-3.4.2/CMAKE/GNUtoMS/lib.cmake:9 (message):
  lib failed: 1


Philip Nienhuis <philipnienhuis>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-03 philipnienhuis StatusPostponed Wont Fix
        Open/ClosedOpen Closed
    2016-07-02 rik5 Severity4 - Important 1 - Wish
    2016-07-01 rik5 Severity2 - Minor 4 - Important
    2015-02-04 mtmiller Severity3 - Normal 2 - Minor
        Priority5 - Normal 3 - Low
        StatusNeed Info Postponed
    2015-02-04 rik5 StatusNone Need Info
    2013-07-10 philipnienhuis CategoryNone Configuration and Build System
        SummaryMXE-Octave: Openblas build mixes MinGW and MSVC MXE-Octave: LAPACK build mixes MinGW and MSVC
    2013-07-09 philipnienhuis Carbon-Copy- Added goffioul

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code