Compiling for Windows
Hey all, I've tried following the instructions here:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Cross-compiling_for_Windows_on_Linux_or_Mac_OS_X
And I've been having a hell of a time.
- Installed fresh Fedora 23 (64-bit) on a VM
- Installed mxe dependencies
dnf install
autoconf automake bash bison bzip2 flex gcc-c++
gdk-pixbuf2-devel gettext git gperf intltool make
sed libffi-devel libtool openssl-devel p7zip patch
perl pkgconfig python ruby scons unzip wget xz - Downloaded and built mxe
git clone git://github.com/mxe/mxe.git
cd mxe
make mpfr eigen opencsg cgal qt
export PATH=/home/jamie/usr/bin:$PATH
since this make command succeeds without errors, I believe it worked. - Download and prepare to build OpenSCAD
cd
git clone git://github.com/openscad/openscad.git
cd openscad
git submodule init
git submodule update
ln -s /home/jamie/mxe/usr/i686-w64-mingw32.static/ mingw-cross-env
At this point nothing I try seems to work.
This works but I'm unsure if it populates the correct values:
source ./scripts/setenv-mingw-xbuild.sh 64
Trying this script gives me an error about missing cmake:
./scripts/mingw-x-build-dependencies.sh
But I have cmake (or the nearest thing) at
/home/jamie/mxe/usr/bin/i686-w64-mingw32.static-cmake
but plain 'cmake' is nowhere in the path according to 'which cmake'
I also tried what look like explicit instructions for building, adapting the
qmake command line from near the bottom of the wiki page to the nearest
qmake in my path:
i686-w64-mingw32.static-qmake-qt4 CONFIG+=mingw-cross-env openscad.pro
And it complains about eigen3 (and harfbuzz and freetype2) not being found
in pkg-config search path.
I have also tried the commands from the README.md file, with similar
results.
Is there a complete set of instructions somewhere? Or is there a specific
set of component versions that is known to work?
-Jamie
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Which version of cmake have you installed? I seem to remember I had the same
problem and solved it downgrading cmake to version 2.8.4
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766p17767.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hard to say without attempting to reproduce, but some ideas:
o Could this be a 32-bit/64-bit mixup? The scripts you’re using take an argument specifying which Windows architecture to build for. That could explain path issues.
o It’s also possible to build natively under Windows (experimental), see https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_on_Microsoft_Windows
If you’re a skilled Windows user it might be better to start off with the second option.
(but I also say that because we’d love some help on improving support for Windows as we don’t have any Windows devs on the team right now :))
Cheers,
-Marius
Ok I feel silly. I was missing cmake, just like the error message was
telling me. I had a cross-environment cmake binary but I was missing the
/native/ cmake, so it was sufficient to install it:
dnf install cmake
I'm still building openscad_deps now, and it is progressing well enough, I
think it might work this time.
Once all is done, I think I might report back on what went well and what
tripped me up.
-Jamie
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766p17778.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Your report will be greatly appreciated! I had some luck in the past trying
to rebuild under Windows but am not currently able to do it.
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766p17793.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Von: buttim maurizio.butti@gmail.com
Your report will be greatly appreciated! I had some luck in the past trying
to rebuild under Windows but am not currently able to do it.
That seems to be a different topic. What Jamie is doing is the same
way the official Windows binaries are built.
Those are created on a Linux system using the MXE build environment
(See http://mxe.cc/).
For "native" Windows compilation (meaning using Visual Studio and
friends) there is currently no known solution as we don't have
someone who works with that and could give a guideline.
What I tried successfully is building in the MSYS2 environment which
is basically a Unix environment layer on Windows. This is documented
in the manual:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_on_Microsoft_Windows
This at least works with the QtCreator as IDE. I don't know if that
still works, but some people did use that procedure successfully in
the past.
ciao,
Torsten.
Sorry, what I actually meant was "for Windows". I am trying the cross
compilation route too.
Still struggling with strange errors in compiling dependencies, namely glib.
The errors seems to be "m4_copy: won't overwrite defined macro: glib_DEFUN".
Still checking for trivial errors though.
tp3 wrote
Von: buttim <
maurizio.butti@
>
Your report will be greatly appreciated! I had some luck in the past
trying
to rebuild under Windows but am not currently able to do it.
That seems to be a different topic. What Jamie is doing is the same
way the official Windows binaries are built.
Those are created on a Linux system using the MXE build environment
(See http://mxe.cc/).
For "native" Windows compilation (meaning using Visual Studio and
friends) there is currently no known solution as we don't have
someone who works with that and could give a guideline.
What I tried successfully is building in the MSYS2 environment which
is basically a Unix environment layer on Windows. This is documented
in the manual:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_on_Microsoft_Windows
This at least works with the QtCreator as IDE. I don't know if that
still works, but some people did use that procedure successfully in
the past.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@.openscad
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766p17798.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 06/22/2016 04:47 PM, buttim wrote:
Sorry, what I actually meant was "for Windows". I am trying the cross
compilation route too.
Hmm, that's strange as this process and the scripts are used
for the official builds and MXE is pretty self-contained.
Although we don't compile all the dependencies for every build,
so there could be an actual MXE issue too. But in general it's
quite stable - especially for the more commonly used packages.
ciao,
Torsten.
What I discovered right now is that having libgl2.0-dev installed caused the
problem.
It manifested with the following message in the build log
"error: m4_copy: won't overwrite defined macro: glib_DEFUN"
I'm using Ubuntu 16.04
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766p17800.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
First I'd like to say buttim's comment about the cmake version dependency was
spot on. Later versions of cmake (not exactly sure but guessing cmake 3.3.0
and later) will fail on the version of cgal (4.5) pulled by the openscad
fork of mxe (https://github.com/openscad/mxe).
Unfortunately it appears my Fedora 23 cannot downgrade cmake low enough for
it to work with cgal 4.5. It might have been possible to get an older cmake
by going outside the package manager to install the older cmake, but that's
beyond what I have patience for, so I'm basically stuck with the newer,
incompatible cmake.
Ultimately I was able to build two ways:
- By using the latest mxe and fixing a dynamic vs. static bug in it
- By fixing cgal 4.5 to be compatible with cmake 3.4.3
For the first method, pointing to the latest mxe was fairly simple:
- Get all the openscad stuff
git clone https://github.com/openscad/openscad.git - modify scripts/mingw-x-build-dependencies.sh to point to mxe/mxe.git
instead of openscad/mxe.git by modifying line 69 to be:
git clone git://github.com/mxe/mxe.git $MXEDIR
and also remove "git checkout openscad-snapshot-build", to get master
instead of branch - within release-common.sh, change references 'i686-pc-mingw32-makensis' to
'i686-w64-mingw32.static-makensis' instead, since that's the name of the
makensis binary (lines 136 and 144) - There is apparently a bug in the latest mxe, where it will always build
shared libraries for cgal regardless of whether static or dynamic is
requested. I believe this update introduced the problem:
https://github.com/mxe/mxe/commit/9f0dbfafc60b725dc09c85059b5b58c3298e3319
This update removed "-DBUILD_SHARED_LIBS=OFF" and added
"-DCGAL_BUILD_SHARED_LIBS=$(CMAKE_SHARED_BOOL)"
but it seems that cgal makefiles don't much care about the value of
CGAL_BUILD_SHARED_LIBS and when BUILD_SHARED_LIBS is unspecified, it
defaults to dynamic.
I submitted an issue https://github.com/mxe/mxe/issues/1402
And as a workaround, I modified the ~/openscad_deps/mxe-w64/src/cgal.mk,
changing back to '-DBUILD_SHARED_LIBS=FALSE' - The static and dynamic libraries can't both be present, so if you've
accidentally built the dynamic ones libCGAL.dll.a, libCGAL_Core.dll.a,
libCGAL_ImageIO.dll.a, and libCGAL_Qt4.dll.a, these must be removed or else
the final linking of the .exe will fail. They reside in
~/openscad_deps/mxe-w64/usr/i686-w64-mingw32.static/lib/ Remove the
".dll.a" versions and leave the ".a" versions. - Then building openscad works, via ./scripts/release-common.sh mingw32
Now, to fix cgal 4.5 so that it doesn't fail with newer cmake... this was a
challenge.
First I observed that it generated two log files, one here, which seemed
useless:
~/openscad_deps/mxe/tmp-cgal-i686-w64-mingw32.static/CGAL-4.5/CMakeFiles/CMakeOutput.log
and another one here, which was more informative:
~/openscad_deps/mxe/log/cgal_i686-w64-mingw32.static
The latter gave this as the error:
-- Sources for CGAL component library 'CGAL_Qt4/CMakeLists.txt' detected
CMake Error at src/CMakeLists.txt:81 (add_subdirectory):
add_subdirectory given source
"/home/vector/openscad_deps/mxe/tmp-cgal-i686-w64-mingw32.static/CGAL-4.5/src/CGAL_Qt4/CMakeLists.txt"
which is not an existing directory.
Apparently it was choking from being given a file (.../CMakeLists.txt) when
it was expecting a directory. After a LOT of digging I found the place
where the string was generated, coinciding with a commit on the CGAL source
tree with a promising comment:
https://github.com/CGAL/cgal/commit/61e61220eb43ea8c3d4a6ebd84d44b0510d8533d
This seemed like a 'smoking gun' for the string being messed up due to a
cmake version dependence.
To fix it, I modified the CGAL package, at
~/openscad_deps/mxe/CGAL-4.5.tar.xz. I opened the archive and essentially
applied the patch, replacing "string(REPLACE ...)" with
"get_filename_component(...)" as shown in the commit. The proper way to do
this would be to insert a patch into the mxe/src, but I don't know the
details of how to do that.
I then recompiled cgal (from mxe directory, "make
build-only-cgal_i686-w64-mingw32.static"), using build-only to prevent
checksum failure and re-download from wiping my changes to CGAL-4.5.tar.xz.
Finally, I was ready to try compiling openscad itself:
./scripts/release-common.sh mingw32
This went without a hitch, and the resulting .exe worked.
-Jamie
--
View this message in context: http://forum.openscad.org/Compiling-for-Windows-tp17766p17801.html
Sent from the OpenSCAD mailing list archive at Nabble.com.