Compiling for Windows

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling for Windows

Jamie_K
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.

1. Installed fresh Fedora 23 (64-bit) on a VM
2. 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
3. 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.
4. 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
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

buttim
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
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

kintel
Administrator
In reply to this post by Jamie_K
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

Jamie_K
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
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

buttim
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.
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

tp3
Von: buttim <[hidden email]>
> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

buttim
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 <[hidden email]>
> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

tp3
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

buttim
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
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

Jamie_K
In reply to this post by tp3
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:
1. By using the latest mxe and fixing a dynamic vs. static bug in it
2. 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:
1. Get all the openscad stuff
git clone https://github.com/openscad/openscad.git
2. 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
3. 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)
4. 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'
5. 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.
6. 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
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

kintel
Administrator
Hi Jamie,

Thanks for the digging!

> On Jun 23, 2016, at 06:00 AM, Jamie_K <[hidden email]> wrote:
>
> 2. By fixing cgal 4.5 to be compatible with cmake 3.4.3
>
The latest MXE has CGAL 4.6.3 - perhaps that works better.
..but the better option is probably to upgrade MXE all the way to 4.8.1, to avoid having to maintain legacy code.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Close command

Michele
The Close command from the File menu, is performing an Exit.  I'd expect it to close the current file but leave the program running.  That is AFAIK, the standard meaning of "close".  Is this fixed in some newer version?

Windows version 2014.12.25 (git 73163f2)

            - Michele


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Compiling for Windows

tp3
In reply to this post by kintel
Oh, that sounds like a bumpy road ahead with CGAL on MXE. If the
upgrade works, it would be very cool if that could be pushed to
the official MXE project.

I don't know if it became easier, but upgrading earlier versions
was quite tricky as they need to ship some kind of pre-generated
configuration file for the cmake process.

The MXE clone in the openscad project on github is only there
as staging area to prevent unexpected upgrades and help when we
need to add new packages.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Close command

kintel
Administrator
In reply to this post by Michele
Hi Michele,

We will close the program if you close the last open file.

 -Marius

PS. Your version is pretty old. The latest official release is 2015.03-2.

> On Jun 23, 2016, at 12:50 PM, Michele Denber <[hidden email]> wrote:
>
> The Close command from the File menu, is performing an Exit.  I'd expect it to close the current file but leave the program running.  That is AFAIK, the standard meaning of "close".  Is this fixed in some newer version?
>
> Windows version 2014.12.25 (git 73163f2)
>
>             - Michele
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Close command

MichaelAtOz
Administrator
In reply to this post by Michele
Michele wrote
The Close command from the File menu, is performing an Exit.  I'd expect
it to close the current file but leave the program running.  That is
AFAIK, the standard meaning of "close".  Is this fixed in some newer
version?

Windows version 2014.12.25 (git 73163f2)

             - Michele


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I'm not sure if it is in 2014.12.25 but current versions have an 'allow opening multiple documents' advanced preference.
When set it operates the way you expect with multiple files, except closing the final document closes the program. Which is logical, as the graphic display window is undefined without a source file.
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: Close command

Michele
On 06-23-2016 9:51 PM, MichaelAtOz wrote:
>
> I'm not sure if it is in 2014.12.25 but current versions have an 'allow
> opening multiple documents' advanced preference.
> When set it operates the way you expect with multiple files, except closing
> the final document closes the program. Which is logical, as the graphic
> display window is undefined without a source file.
>    
Yes, but that does not require exiting the program.  When you first
start the program, the graphics window is blank until you start writing
code and rendering.  This is the way Microsoft Word, CorelDraw, and
Photoshop all work.  If you have one file open and click Close, the file
is closed but the program remains running with a blank text or graphics
window.

That's the way every program I've ever used that offers a Close command
works.  Closing the last file leaves the program running with a blank
window ready to either open a new file or start creating a new
document.  I submit that Openscad is non-standard in that regard.

             - Michele



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Close command

Kenneth Sloan
Heh…

I nominate “Openscad is non-s
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.




> On Jun 25, 2016, at 10:36 , Michele Denber <[hidden email]> wrote:
>
> On 06-23-2016 9:51 PM, MichaelAtOz wrote:
>>
>> I'm not sure if it is in 2014.12.25 but current versions have an 'allow
>> opening multiple documents' advanced preference.
>> When set it operates the way you expect with multiple files, except closing
>> the final document closes the program. Which is logical, as the graphic
>> display window is undefined without a source file.
>>  
> Yes, but that does not require exiting the program.  When you first start the program, the graphics window is blank until you start writing code and rendering.  This is the way Microsoft Word, CorelDraw, and Photoshop all work.  If you have one file open and click Close, the file is closed but the program remains running with a blank text or graphics window.
>
> That's the way every program I've ever used that offers a Close command works.  Closing the last file leaves the program running with a blank window ready to either open a new file or start creating a new document.  I submit that Openscad is non-standard in that regard.
>
>            - Michele
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Close command

Kenneth Sloan
In reply to this post by Michele
Heh…

I nominate “Openscad is non-standard” as the understatement of the year.

In a language where a cube may have different H,W,D, and where coders specify hex-nuts as “cylinder”s, I don’t think the slightly different handling of “Close” makes it on to the first page of examples of “non-standard” usage.

You were surprised.  Get over it.  I wouldn’t be surprised if there were not 10 existing OpenSCAD users who would complain about things “breaking” if the behavior were changed.

and, besides - working differently from Microsoft Word, CorelDraw, and Photoshop is not prima facie evidence of being “wrong”.

Being “different” is not always a bad thing.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.




> On Jun 25, 2016, at 10:36 , Michele Denber <[hidden email]> wrote:
>
> On 06-23-2016 9:51 PM, MichaelAtOz wrote:
>>
>> I'm not sure if it is in 2014.12.25 but current versions have an 'allow
>> opening multiple documents' advanced preference.
>> When set it operates the way you expect with multiple files, except closing
>> the final document closes the program. Which is logical, as the graphic
>> display window is undefined without a source file.
>>  
> Yes, but that does not require exiting the program.  When you first start the program, the graphics window is blank until you start writing code and rendering.  This is the way Microsoft Word, CorelDraw, and Photoshop all work.  If you have one file open and click Close, the file is closed but the program remains running with a blank text or graphics window.
>
> That's the way every program I've ever used that offers a Close command works.  Closing the last file leaves the program running with a blank window ready to either open a new file or start creating a new document.  I submit that Openscad is non-standard in that regard.
>
>            - Michele
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Close command

Michele
On 06-25-2016 3:44 PM, Kenneth Sloan wrote:
> Heh…
>
> I nominate “Openscad is non-standard” as the understatement of the year.
>
> In a language where a cube may have different H,W,D, and where coders specify hex-nuts as “cylinder”s, I don’t think the slightly different handling of “Close” makes it on to the first page of examples of “non-standard” usage.
>
> You were surprised.  Get over it.
>    

This is what I get for trying to help?  Get over it??  Well then yes yes
Ken, you've totally convinced me.  "Close" should mean "Exit" after
all.  Also "Export" should mean "set the basic unit size to the parsec"
and "New" should mean "cd / ; rm -rf".  That's different too.

And "Save" should mean "Welcome to my block list".  Like this.

             - Michele


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org