Trouble compiling under Windows with MinGW

[Jeff Hunter]

I've have attempted to build deal.ii a few times now under Windows, but can never get the final product to link. This is the CMake config that seems to work the best:

###

#

# deal.II configuration:

# CMAKE_BUILD_TYPE: DebugRelease

# BUILD_SHARED_LIBS: ON

# CMAKE_INSTALL_PREFIX: D:/deal.ii-install

# CMAKE_SOURCE_DIR: C:/Users/j/Annals/Code/deal.II (Version 8.0.0)

# CMAKE_BINARY_DIR: C:/Users/j/Annals/Code/deal.ii-attempt-1

# CMAKE_CXX_COMPILER: GNU 4.7.2 on platform Windows AMD64

# C:/MinGW/bin/mingw32-g++.exe

#

# Configured Features (DEAL_II_ALLOW_BUNDLED = ON, DEAL_II_ALLOW_AUTODETECTION = OFF):

# ( DEAL_II_WITH_64BIT_INDICES = OFF )

# ( DEAL_II_WITH_ARPACK = OFF )

# DEAL_II_WITH_BOOST set up with bundled packages (forced)

# ( DEAL_II_WITH_FUNCTIONPARSER = OFF )

# ( DEAL_II_WITH_HDF5 = OFF )

# ( DEAL_II_WITH_LAPACK = OFF )

# ( DEAL_II_WITH_METIS = OFF )

# ( DEAL_II_WITH_MPI = OFF )

# ( DEAL_II_WITH_MUMPS = OFF )

# ( DEAL_II_WITH_NETCDF = OFF )

# ( DEAL_II_WITH_P4EST = OFF )

# ( DEAL_II_WITH_PETSC = OFF )

# ( DEAL_II_WITH_SLEPC = OFF )

# ( DEAL_II_WITH_THREADS = OFF )

# ( DEAL_II_WITH_TRILINOS = OFF )

# ( DEAL_II_WITH_UMFPACK = OFF )

# ( DEAL_II_WITH_ZLIB = OFF )

#

# Component configuration:

# DEAL_II_COMPONENT_COMPAT_FILES

# ( DEAL_II_COMPONENT_DOCUMENTATION = OFF )

# DEAL_II_COMPONENT_EXAMPLES

# DEAL_II_COMPONENT_MESH_CONVERTER

# ( DEAL_II_COMPONENT_PARAMETER_GUI = OFF )

#

# Detailed information (compiler flags, feature configuration) can be found in detailed.log

#

###

In addition, I have removed the check which disables shared libraries under Windows. This makes it all the way to "Linking CXX shared library libdeal_II.dll" but then crashes with:

CMakeFiles\deal_II.dir/objects.a(full_matrix.cc.obj):full_matrix.cc:(.text$_ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv[__ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv]+0x5e): undefined reference to `cabsf'
CMakeFiles\deal_II.dir/objects.a(full_matrix.cc.obj):full_matrix.cc:(.text$_ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv[__ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv]+0x99): undefined reference to `cabsf'
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: CMakeFiles\deal_II.dir/objects.a(full_matrix.cc.obj): bad reloc address 0x99 in section `.text$_ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv[__ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv]'
collect2.exe: error: ld returned 1 exit status
source\CMakeFiles\deal_II.dir\build.make:549: recipe for target 'source/libdeal_II.dll' failed
mingw32-make[2]: *** [source/libdeal_II.dll] Error 1
CMakeFiles\Makefile2:453: recipe for target 'source/CMakeFiles/deal_II.dir/all'
failed
mingw32-make[1]: *** [source/CMakeFiles/deal_II.dir/all] Error 2
Makefile:115: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

Any advice would be greatly appreciated.

[Matthias Maier]

Hi Jeff,

we have some severe linking issues under Windows (Cygwin or MinGW) at
the moment. You basically have two options:


a) If your computer supports hardware virtualization, you can use a
virtualbox image as discussed here [1]. this will give you a minimal
linux with deal.II and a lot of optional dependencies readily
installed.


b) If you really want to use MingW on a native Windows, use the latest
development version. I've introduced some changes in CMake so that
dynamic linkage works (in principle). You can get this version via svn
as discussed in the documentation.

First, just try to compile and link the Release configuration, specify

-DCMAKE_BUILD_TYPE=Release

via the cmake command line or GUI. If you can run several example steps
successfully with that, let us know and move on to combined DebugRelease
configuration.


Best,
Matthias


[1] https://code.google.com/p/dealii/issues/detail?id=89

[Timo Heister]

> [1] https://code.google.com/p/dealii/issues/detail?id=89

The FAQ now has an entry about this:
https://code.google.com/p/dealii/wiki/FrequentlyAskedQuestions#Run_deal.II_through_a_virtual_box

--
Timo Heister
http://www.math.clemson.edu/~heister/

[Jeff Hunter]

Even when building with the latest version and Release only, the exact error still occurs.

My understanding is that there exists some problem with std::complex when under MinGW. As a test, I removed all references to std::complex from the source and cmake scripts. This allowed the library to compile and install.

The problem now is that a simple test program compiles but SegFaults. The test program #imports <deal.II/grid/tria.h>, declares a Triangulation<2> t; and then quits.

So it seems that my excision of std::complex either broke the library quite seriously, or it just didn't want to work regardless.

Does anyone have further advice I could leverage? I'm open to any fix, either with MinGW, deal.II code, or system settings.

[Timo Heister]

Dear Jeff,

What are your plans regarding deal.II if I may ask? Even if you get it
work under windows natively (difficult to impossible) you are
restricted to run without multi-threading or any external library
(probably no blas/lapack/umfpack either). This will restrict your
usage considerably (you can run maybe half of the tutorial programs).

My experience is much better running a virtual machine (which is very
easy to get to work, see my earlier email). You can even use
MPI/multithreading/Trilinos/PETSc/etc. without any problems. If you
run into the limitations of the virtual machine (larger computations,
3d, etc.), you can always install linux on one of your machines.

Sorry, I can not offer help for your problem.

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Jeff Hunter]

My intention is to get as much of Deal.ii working under Linux/Windows as possible. I've got a little physics simulator I'm trying to write, but problems with my program exist on both systems.

Ubuntu 13.04 doesn't play nice with the graphics chips on my machine (NVidia GTX 770m + integrated), making it difficult to impossible to write compute shader code (part of my little simulator). Windows plays very nice with that chip, but doesn't play at all with Deal.ii.

It has so far seemed easier to compile Deal.ii under Windows than to get Ubuntu working alongside switch-able video chips, which led to my decision. To be fair, I'm a bit glad that the solution is to stop trying to make a Windows build work.

Where could one check on or help with the development of a Windows version of Deal.ii?

[Wolfgang Bangerth]

> Where could one check on or help with the development of a Windows
> version of Deal.ii?

You're on the right mailing list -- everyone with deal.II experience is
here. Unfortunately, none of us have Windows experience :-(

In an ideal world, it would be possible to build deal.II with MS Visual
C++. Last anyone tried, it was -- let's just say: an uphill battle due
to the incredible bugginess of their C++ parser. It would be an
interesting experiment to make it work with the native Intel C++
compiler on Windows which we know has a very good C++ frontend. I don't
know enough to suggest how to do this but assume that it is possible to
tell CMake to use this compiler. I believe that in the short run, Intel
C++ on Windows offers the least path of resistance to making things work.

Best
Wolfgang

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Krzysztof Bzowski]

It is no so simple. Cmake cannot generate project directly for Windows
ICC. Only possibility is to generate project for Visual Studio and
change Compiler for each project in Solution to Intel C++. I have tried
that some times ago but a lot C++ errors occurred (but still less then
with native VS compiler). I have not tested it with latest 8.0/8.1pre.
Maybe its worth a try.

[Timo Heister]

>> It would be an
>> interesting experiment to make it work with the native Intel C++
>> compiler on Windows which we know has a very good C++ frontend.

Good idea, but it looks like the Intel compiler is tied into Visual
Studio and is probably trying to be compatible. We might end up with
similar problems.

Apparently clang is already in a somewhat working state running on top
of mingw: http://clang.llvm.org/docs/UsersManual.html#mingw-w64
Maybe this is something to try out?

There is also some hope to get native clang on Windows at some point
in the future:
http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html

But, my bet is that running a virtual machine will still give a much
better experience (even if somebody gets it to compile).

[bruno.t...@gmail.com]

Jeff,

Ubuntu 13.04 doesn't play nice with the graphics chips on my machine (NVidia GTX 770m + integrated), making it difficult to impossible to write compute shader code (part of my little simulator). Windows plays very nice with that chip, but doesn't play at all with Deal.ii.

It has so far seemed easier to compile Deal.ii under Windows than to get Ubuntu working alongside switch-able video chips, which led to my decision. To be fair, I'm a bit glad that the solution is to stop trying to make a Windows build work.

Could you install Ubuntu 12.04 ? There is a bug in the kernel used by Ubuntu 13.04. It should be fix in the newer version of the kernel so if you want you can also try to upgrade the kernel.

Best

Bruno

[Wolfgang Bangerth]

Jeff:

> CMakeFiles\deal_II.dir/objects.a(full_matrix.cc.obj):full_matrix.cc:(.text$_ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv[__ZNK6dealii10FullMatrixISt7complexIfEE7l1_normEv]+0x5e):
> undefined reference to `cabsf'

Interesting. You only get one kind of error -- I find this quite encouraging.
On linux, cabsf is part of the libm (on my laptop, in /lib64/libm-2.15.so in
fact). Can you try to find out whether this is true for your system as well?

If so, then maybe we simply forget to just link with libm. If you do
make VERBOSE=ON
it should print the command lines for your. Can you post the one for the link
step that fails?

Best
W.

[Wolfgang Bangerth]

On 09/06/2013 01:17 AM, Krzysztof Bzowski wrote:
> It is no so simple. Cmake cannot generate project directly for Windows ICC.
> Only possibility is to generate project for Visual Studio and change Compiler
> for each project in Solution to Intel C++. I have tried that some times ago
> but a lot C++ errors occurred (but still less then with native VS compiler). I
> have not tested it with latest 8.0/8.1pre. Maybe its worth a try.

Can you post these error messages? It may very well be easy enough to fix them
and that would help make progress getting things to run on Windows. Any help
on this would certainly be greatly appreciated!

[Jeff Hunter]

Well, I feel dumb. In my defense, this is my first time compiling anything with MinGW.

With libm, everything goes fine actually! So I feel a bit embarrassed.

However: mingw32/bin/ld.exe: final link failed: Memory exhausted

[bruno.t...@gmail.com]

Jeff,

However: mingw32/bin/ld.exe: final link failed: Memory exhausted

Apparently this error appears either because you don't have enough memory or because you ran into a bug of mingw. The solution seems to try another version of mingw. I saw people advising to use tdm-mingw

Here are some links where they describe problems similar to yours and how to fix it.:

http://wiki.wxwidgets.org/Compiling_wxWidgets_with_MinGW#Memory_Exhausted_.28bin.2Fld.exe:_out_of_memory_allocating_N_bytes.29
http://qt-project.org/forums/viewthread/19773

Best,

Bruno

[Matthias Maier]

Am 18. Sep 2013, 16:36 schrieb Timo Heister <hei...@clemson.edu>:

> I think we might be going over 4gigs of RAM for the linker in mingw in
> debug mode. Jeff, can you check with 'top'? That means you won't be
> able to make it work unless there is a 64bit mingw that works.

The linker in current mingw toolchains for 32bit and 64bit is
broken. Not just wrt. memory consumption.

At least this is my result after spending an afternoon with it 3 months
ago.

Best,
Matthias

[Wolfgang Bangerth]

On 09/18/2013 12:10 AM, Jeff Hunter wrote:
> Well, I feel dumb. In my defense, this is my first time compiling
> anything with MinGW.
>
> With libm, everything goes fine actually! So I feel a bit embarrassed.

How did you add libm to the link line? By hand, by running the same
command from the command line, but with -lm added?

[Timo Heister]

I think we might be going over 4gigs of RAM for the linker in mingw in
debug mode. Jeff, can you check with 'top'? That means you won't be
able to make it work unless there is a 64bit mingw that works.

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.