cmake not linking shlwapi using mingw

[s1m...@gmail.com]

Hi,

I am trying to build the ceres-solver using mingw-w64. While I had some problems building glog, bulding gflags was easy using cmake.
With the recent improvements on detecting the gflags namespace gflgas was found during the cmake process of the ceres-solver.

After building the library, the linking of the tests caused some errors. This was due to the fact, that the Shlwapi library is used by gflags if available, as mentioned in the FindGflags.cmake file. But the check is only done for MSVC compiler and not for WIN32. But gflags uses this library also when building with mingw-w64.
After changing the the variable from MSVC to WIN32, the tests where successfully linked. WIN32 is true for MSVC and MINGW but not for CygWin (since 2.8.4 http://www.cmake.org/Wiki/CMake_Useful_Variables).

Maybe you could change this in the FindGflags.cmake.



Although bulding is done correctly, the following tests fail:
5:block_jacobi_preconditioner_test
7:block_random_access_diagonal_matrix_test
14:corrector_test
16:covariance_test
32:dogleg_strategy_test
34:local_parameterization_test
51:schur_eliminator_test
53:small_blas_test
62:system_test

I am not using SuiteSparse, CXSparse BLAS or LAPACK.


Another issue concerning the cmake process is BLAS and LAPACK. Even if not using SuiteSparse, they can optionally used by Ceres directly for some operations.
Is it possible to simplify this process and let BLAS and LAPACK be detected by cmake and used by ceres, although not using SuiteSparse?

Regards,
Simeon

[Sameer Agarwal]

Simeon,
Thanks for the feedback.  My comments are inline.

After building the library, the linking of the tests caused some errors. This was due to the fact, that the Shlwapi library is used by gflags if available, as mentioned in the FindGflags.cmake file. But the check is only done for MSVC compiler and not for WIN32. But gflags uses this library also when building with mingw-w64.
After changing the the variable from MSVC to WIN32, the tests where successfully linked. WIN32 is true for MSVC and MINGW but not for CygWin (since 2.8.4 http://www.cmake.org/Wiki/CMake_Useful_Variables).

I have filed 

https://github.com/ceres-solver/ceres-solver/issues/156 

 

to keep track of this.

Although bulding is done correctly, the following tests fail:
5:block_jacobi_preconditioner_test
7:block_random_access_diagonal_matrix_test
14:corrector_test
16:covariance_test
32:dogleg_strategy_test
34:local_parameterization_test
51:schur_eliminator_test
53:small_blas_test
62:system_test

can you provide the cmake and execution log ?

I am not using SuiteSparse, CXSparse BLAS or LAPACK.


Another issue concerning the cmake process is BLAS and LAPACK. Even if not using SuiteSparse, they can optionally used by Ceres directly for some operations.
Is it possible to simplify this process and let BLAS and LAPACK be detected by cmake and used by ceres, although not using SuiteSparse?

I thought this worked already. could you share the commandline you used and the failure you got? 

Sameer

Regards,
Simeon

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/0577027b-4007-41ae-850a-7b02b3ca668d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Stewart]

Simeon,

Your patch should now be submitted to master (patch: https://ceres-solver-review.googlesource.com/6440).

Regarding this:

Another issue concerning the cmake process is BLAS and LAPACK. Even if not using SuiteSparse, they can optionally used by Ceres directly for some operations.
Is it possible to simplify this process and let BLAS and LAPACK be detected by cmake and used by ceres, although not using SuiteSparse?

This certainly should be fine, either by disabling SUITESPARSE & CXSPARSE in the CMake GUI, or via: -DCXSPARSE=OFF -DSUITESPARSE=OFF -DEIGENSPARSE=OFF when invoking CMake on the command line.  Obviously you might want to enable EIGENSPARSE to get a sparse linear solver (which only depends on Eigen) - although note that this results in an LGPL version of Ceres (which is otherwise BSD) due to the licensing of the Simplicial Cholesky factorization in Eigen.

By default, LAPACK (& BLAS) are used, if you are seeing LAPACK turned off in CMake, then there should be an associated message in the CMake log saying that they could not be found, and so are being disabled - is this what is happening for you?  Ceres uses the FindBLAS.cmake & FindLAPACK.cmake scripts that ship with CMake to detect these, and I think they should support MinGW.

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUBKV8_KZBd1pqLGTPecGxenW9DtxJWq9B2CrDdoRub9UQ%40mail.gmail.com.

[s1m...@gmail.com]

Hi Sameer and Alex,

thank you for submitting the patch, it works as expected.
BLAS and LAPACK I am only using on linux, see below.
I made a summary of the problems that occurred so far. Attached you can find the test logs.

Simeon




I am building the ceres-solver on two different platforms:

I am using glog   , gflags-2.1.1 and eigen 3.2.4, using EIGENSPARSE=ON


1) linux with openSUSE 13.2 (x86_64)
As expected all tests pass
Since I have build ATLAS on this platform I want to use it.

Before this step I added the location of my library to my PATH and set LD_LIBRARY_PATH to the correct directory.

But when I specify -DBLA_VENDOR=ATLAS in the cmake step, a get the following cmake output:
-- A library with BLAS API not found. Please specify library location.
-- LAPACK requires BLAS
-- Did not find LAPACK library, disabling LAPACK support.
-- Did not find BLAS library, disabling LAPACK support.

but when checking CMakeCache.txt:

########################
# EXTERNAL cache entries
########################

//Path to a library.
BLAS_atlas_LIBRARY:FILEPATH=/home/atlas/local/lib/libatlas.a

//Path to a library.
BLAS_f77blas_LIBRARY:FILEPATH=/home/atlas/local/lib/libf77blas.a

//No help, variable specified on the command line.
BLA_VENDOR:UNINITIALIZED=ATLAS

.
.
.

########################
# INTERNAL cache entries
########################

//ADVANCED property for variable: BLAS_atlas_LIBRARY
BLAS_atlas_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: BLAS_f77blas_LIBRARY
BLAS_f77blas_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: BLAS_f77blas_atlas_WORKS
BLAS_f77blas_atlas_WORKS-ADVANCED:INTERNAL=1
//Have function dgemm_
BLAS_f77blas_atlas_WORKS:INTERNAL=
//ADVANCED property for variable: CMAKE_AR
CMAKE_AR-ADVANCED:INTERNAL=1


Maybe you could add support for the ATLAS library.



If I don't give this option, the default lapack and blas libraries are found.
-- Found LAPACK library: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
-- Found BLAS library: /usr/lib64/libblas.so

In CMakeCache.txt:

//Path to a library.
BLAS_atlas_LIBRARY:FILEPATH=/home/atlas/local/lib/libatlas.a

//Path to a library.
BLAS_blas_LIBRARY:FILEPATH=/usr/lib64/libblas.so


Of course I can change the
BLAS_blas_LIBRARY:FILEPATH
in the CMakeCache file.

Note that the the lapack created by atlas has the same name "liblapack.a"
and I think because it comes first in my PATH, the ATLAS version is used.
But the cmake output states otherwise.
CMakeCache:

//Path to a library.
LAPACK_lapack_LIBRARY:FILEPATH=/home/atlas/local/lib/liblapack.a




2) Windows 7 64, but I want to compile for 32bit windows

a) MSVC Compiler, Visual Studio 12 2013 (MSVC 18.0.311)

the glog library is not found (it is called libglog.lib and libglog.dll) in the cmake process
it must be specified manually.
This is due to the fact, that cmake does not add the lib prefix when the Visual Studio generator is used.
Renaming libglog to glog makes cmake find the library.

Building the ceres as a static library works, but all binaries fail due to link errors.
Seems that all the libraries don't export the needed functions.


Building ceres as a shared library automatically disables testing. The library is built.

The following examples fail due to link errors:
libmv_bundle_adjuster
bundle_adjuster
circle_fit
more_garbow_hillstrom
nist
powell
robot_pose_mle
denoising
sampled_function

This examples are built:
curve_fitting
curve_fitting_c
ellipse_approximation
helloworld
helloworld_analytic_diff
helloworld_numeric_diff
libmv_homography
robust_curve_fitting
rosenbrock
simple_bundle_adjuster


b) cygwin environment, cygwin 32 bit version for windows with gcc 4.9.2
Building glog and gflags works.
gflags tests all pass

building ceres works, but

The following tests FAILED:
53 - small_blas_test (Failed)

see attached file


c) mingw-w64: i686-4.9.2-posix-sjlj-rt_v3-rev1

Building glog with mingw was really a complete mess.
The configure script does not support mingw and because glog defines it's own posix threads, I had to use a different mingw install with win32 threads for building glog.
Most of the test can not be build. Here I used glog 0.3.4.

Building gflags using cmake was strait forward, all tests passed.

Building ceres as a static library works.

Many tests fail:

85% tests passed, 9 tests failed out of 62

Total Test time (real) =  74.65 sec

The following tests FAILED:
      5 - block_jacobi_preconditioner_test (SEGFAULT)
      7 - block_random_access_diagonal_matrix_test (SEGFAULT)
     14 - corrector_test (SEGFAULT)
     16 - covariance_test (SEGFAULT)
     32 - dogleg_strategy_test (SEGFAULT)
     34 - local_parameterization_test (SEGFAULT)
     51 - schur_eliminator_test (SEGFAULT)
     53 - small_blas_test (SEGFAULT)
     62 - system_test (SEGFAULT)
Errors while running CTest
makefile:116: recipe for target 'test' failed
mingw32-make: *** [test] Error 8

See attached file.


d) all platforms

The Example ellipse_approximations seems to fail on all platforms with all compilers.

[Alex Stewart]

Simeon,

Nothing in Ceres should preclude using ATLAS, I think the reason CMake is not accepting your ATLAS install is because dgemm_ is not defined in your f77blas library:

//Have function dgemm_
BLAS_f77blas_atlas_WORKS:INTERNAL=

which is how FindBLAS.cmake (shipped with CMake, Ceres does not have its own) determines whether the libraries found are actually valid.  What is the output of:

nm /home/atlas/local/lib/libf77blas.a | grep --color dgemm

?

I am not sure what is going on here:

If I don't give this option, the default lapack and blas libraries are found.
-- Found LAPACK library: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
-- Found BLAS library: /usr/lib64/libblas.so

//Path to a library.
LAPACK_lapack_LIBRARY:FILEPATH=/home/atlas/local/lib/liblapack.a

I suspect this could be CMake getting confused if you are not clearing your build directory between making modifications to various variables.  The console output when building Ceres:

-- Found LAPACK library: /usr/lib64/liblapack.so;/usr/lib64/libblas.so

contains the LAPACK libraries that are actually going to be used by Ceres (the contents of the LAPACK_LIBRARIES variable set by FindLAPACK.cmake).

The only failure in the Cygwin test log is here:

/home/benutzer/ceres-solver/internal/ceres/small_blas_test.cc:286: Failure

The difference between (c_minus_ref - c_minus).norm() and 0.0 is 4.4754520913118096e-16, which exceeds kTolerance, where

(c_minus_ref - c_minus).norm() evaluates to 4.4754520913118096e-16,

0.0 evaluates to 0, and

kTolerance evaluates to 4.4408920985006262e-16.

Which is only just failing, by 3e-18.  It is interesting that this fails on Cygwin but not other platforms.  Sameer / Keir can chime in, with their thoughts on whether we should inflate the tolerance.

For MinGW, I think you are hitting this MinGW bug that affects Eigen: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=556, as even the (first) MatrixMatrixMultiply test in small_blas_test is failing, which calls straight onto Eigen for small fixed size matrix multiplications.  Frankly if basic matrix ops are failing, to paraphrase, you will not be going to space today.  You could try substituting the -O3 with -O2 in CMAKE_CXX_FLAGS_RELEASE (visible in the advanced view in the GUI) and rebuilding to see if that resolves the issue as it appears to do from the bug report.

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/2ebf0af6-6c5a-48da-9fa8-48bc5ef19e79%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<CygwinLastTest.log><MingwLastTest.log>

[Sameer Agarwal]

That last failure in small_blas_test was fixed recently. That tolerance is too tight. Try the master branch and see if you still get a failure.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/E97D65C0-D53A-436E-9A1A-38F38AF7F59E%40gmail.com.

[s1m...@gmail.com]

Thanks again for the helpful comments.


a)

nm /home/atlas/local/lib/libf77blas.a | grep --color dgemm

dgemm.o:
                 U atl_f77wrap_dgemm_
0000000000000000 T dgemm_
ATL_F77wrap_dgemm.o:
                 U ATL_dgemm
0000000000000000 T atl_f77wrap_dgemm_

I suspect this could be CMake getting confused if you are not clearing your build directory between making modifications to various variables. 

 

You were right about clearing the build directory.


b) changing the optimization from -O3 to -O2 in CMAKE_CXX_FLAGS_RELEASE, when compiling with mingw:
the segfault errors caused by eigen don't occur anymore.

I receive windows errors, pop up several times:
corrector_test.exe has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.


same error with:
graph_test
local_parameterization_test
ordered_groups_test
parameter_block_test
problem_test
triplet_sparse_matrix_test

see attached file MinGwLastTest2.log


when closing the pop up windows very quickly while while windows is searching for a solution, all tests pass.
I think the error occurred already in my previous build, but there I closed the pop-up windows very quickly. That's why I only noticed the segfault errors caused by eigen.


see attached file MinGwLastTest3.log



c)

That last failure in small_blas_test was fixed recently. That tolerance is too tight. Try the master branch and see if you still get a failure.

The small_blas_test still fails with cygwin using the master branch, commit:  998279196969dc7d7795b2c161da6fa8bee11bc8


Simeon

[Alex Stewart]

Simeon,

From a fresh build directory, if you invoke CMake with —debug-trycompile, and then look at the contents of <BUILD_DIR>/CMakeFiles/CMakeOutput.log and search for “dgemm”, there should be a section that starts with:

Determining if the function dgemm_ exists passed with the following output:

...

which contains the compilation & link commands actually used to perform the test as to whether dgemm exists.  What happens if you run these manually in a terminal?  What errors are produced?

I receive windows errors, pop up several times: 
corrector_test.exe has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.

The tests failing are all death tests.  It is odd that these are triggering dialog windows as there is code in gtest specifically to prevent this on Windows & MinGW and Ceres is using a fairly recent of gtest (March 2014 HEAD, which is > the 1.7 current stable release - gtest is very mature), and a quick examination doesn’t show up any MinGW related death test patches since then, but there are some google hits for MinGW gtest death test related issues.  IMO this looks like a MinGW problem.

b) changing the optimization from -O3 to -O2 in CMAKE_CXX_FLAGS_RELEASE, when compiling with mingw:

the segfault errors caused by eigen don't occur anymore.

Can you please try this patch: https://ceres-solver-review.googlesource.com/#/c/6460/

It should do this automatically when MinGW is detected.

The small_blas_test still fails with cygwin using the master branch, commit:  998279196969dc7d7795b2c161da6fa8bee11bc8

Please try the patch here on Cygwin: https://ceres-solver-review.googlesource.com/6461

-Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/e094befe-35b6-4d6e-bc90-34d85d1cdd4c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<MinGwLastTest2.log><MinGwLastTest3.log>

[s1m...@gmail.com]

Thank you Alex for your help,
 

From a fresh build directory, if you invoke CMake with —debug-trycompile, and then look at the contents of <BUILD_DIR>/CMakeFiles/

CMakeOutput.log and search for “dgemm”, there should be a section that starts with:

Determining if the function dgemm_ exists passed with the following output:

dgemm (or sgemm) is not found in the entire file

when not using the atlas library, at least sgemm is found:
 

Determining if the function sgemm_ exists passed with the following output:
Change Dir: /home/benutzer/libbuild/ceres-solver/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTryCompileExec2750402384/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec2750402384.dir/build.make CMakeFiles/cmTryCompileExec2750402384.dir/build
gmake[1]: Entering directory '/home/benutzer/libbuild/ceres-solver/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/benutzer/libbuild/ceres-solver/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec2750402384.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=sgemm_   -o CMakeFiles/cmTryCompileExec2750402384.dir/CheckFunctionExists.c.o   -c /usr/share/cmake/Modules/CheckFuncti
Linking C executable cmTryCompileExec2750402384
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec2750402384.dir/link.txt --verbose=1
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=sgemm_    CMakeFiles/cmTryCompileExec2750402384.dir/CheckFunctionExists.c.o  -o cmTryCompileExec2750402384 -rdynamic -l
gmake[1]: Leaving directory '/home/benutzer/libbuild/ceres-solver/build/CMakeFiles/CMakeTmp'

Can you please try this patch: https://ceres-solver-review.googlesource.com/#/c/6460/

It should do this automatically when MinGW is detected.

Please try the patch here on Cygwin: https://ceres-solver-review.googlesource.com/6461

Both were merged in the master branch.
Using Cygwin, all tests pass.

Using mingw, the error messages still pop up, but otherwise, all tests pass (after building from a clean build dir).


Simeon