Empathy List Archives

B

buttim

Mon, Feb 13, 2017 11:09 PM

I'm having a hard time trying to cross compile OpenSCAD under Ubuntu for
Windows.
I did manage tio get executables in june, but recently I get the following
error:

../src/LibraryInfo.cc:27:17: fatal error: zip.h: No such file or directory

Any good soul with an advice for me?

--
View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I'm having a hard time trying to cross compile OpenSCAD under Ubuntu for Windows. I did manage tio get executables in june, but recently I get the following error: ../src/LibraryInfo.cc:27:17: fatal error: zip.h: No such file or directory Any good soul with an advice for me? -- View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Mon, Feb 13, 2017 11:24 PM

On 02/14/2017 12:09 AM, buttim wrote:

I'm having a hard time trying to cross compile OpenSCAD under Ubuntu
for Windows.

Is that cross compiling using MXE (like the official binaries are
compiled)?

I did manage tio get executables in june, but recently I get the following
error:

../src/LibraryInfo.cc:27:17: fatal error: zip.h: No such file or directory

This means it did detect libzip for some reason and set ENABLE_LIBZIP
but either the include path is wrong or it's not installed.

There is currently an build issue where the MXE build does not find
libzip, but that should just disable compression support, not fail
to build.
Actually I did run the cross build for master yesterday on our build
machine and that did run though.

ciao,
Torsten.

On 02/14/2017 12:09 AM, buttim wrote: > I'm having a hard time trying to cross compile OpenSCAD under Ubuntu > for Windows. > Is that cross compiling using MXE (like the official binaries are compiled)? > I did manage tio get executables in june, but recently I get the following > error: > > ../src/LibraryInfo.cc:27:17: fatal error: zip.h: No such file or directory > This means it did detect libzip for some reason and set ENABLE_LIBZIP but either the include path is wrong or it's not installed. There is currently an build issue where the MXE build does not find libzip, but that should just disable compression support, not fail to build. Actually I did run the cross build for master yesterday on our build machine and that did run though. ciao, Torsten.

B

buttim

Mon, Feb 13, 2017 11:34 PM

You nailed it. Disabling zip in openscad.pro by commenting away the line

CONFIG += libzip

the compilation goes on (not finished yet but seems promising anyway).
Maybe a bug in the detection logic for zip support.
Worth opening a bug report?

--
View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20415.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

You nailed it. Disabling zip in openscad.pro by commenting away the line CONFIG += libzip the compilation goes on (not finished yet but seems promising anyway). Maybe a bug in the detection logic for zip support. Worth opening a bug report? -- View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20415.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Mon, Feb 13, 2017 11:40 PM

On 02/14/2017 12:34 AM, buttim wrote:

the compilation goes on (not finished yet but seems promising anyway).
Maybe a bug in the detection logic for zip support.
Worth opening a bug report?

Hmm, can you find out why it thinks it's there? As I didn't
have this so far, it will be hard to fix without additional
information.
Unless it will go away when fixing the other issue I mentioned,
but that does not seem too likely.

Maybe it's detecting the header installed on Linux instead of
just looking in the cross compilation env?

ciao,
Torsten.

On 02/14/2017 12:34 AM, buttim wrote: > the compilation goes on (not finished yet but seems promising anyway). > Maybe a bug in the detection logic for zip support. > Worth opening a bug report? > Hmm, can you find out why it thinks it's there? As I didn't have this so far, it will be hard to fix without additional information. Unless it will go away when fixing the other issue I mentioned, but that does not seem too likely. Maybe it's detecting the header installed on Linux instead of just looking in the cross compilation env? ciao, Torsten.

B

buttim

Mon, Feb 13, 2017 11:53 PM

I swear I have no idea of how the different build tools work but, yes, I will
definitely give it a try. At worse I will be of no help but will learn
something (something I should have learned quite a time ago).

In the meantime another problem showed up. As I said compilation was going
at full speed. So this time is the linker complaining:

/usr/bin/ld: unrecognized option '--stack'

--
View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20417.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I swear I have no idea of how the different build tools work but, yes, I will definitely give it a try. At worse I will be of no help but will learn something (something I should have learned quite a time ago). In the meantime another problem showed up. As I said compilation was going at full speed. So this time is the linker complaining: /usr/bin/ld: unrecognized option '--stack' -- View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20417.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Tue, Feb 14, 2017 12:12 AM

On 02/14/2017 12:53 AM, buttim wrote:

/usr/bin/ld: unrecognized option '--stack'

Now that sounds like it's running the wrong linker.

So back to the first question, how exactly are you doing the
cross compilation. It might case some mix-up of system native
and cross compilation.

The build server uses essentially:

export MXEDIR=/opt/mxe
. ./scripts/setenv-mingw-xbuild.sh 64
./scripts/release-common.sh -snapshot mingw64

Which does expect full MXE environment in /opt/mxe

ciao,
Torsten.

On 02/14/2017 12:53 AM, buttim wrote: > /usr/bin/ld: unrecognized option '--stack' > Now that sounds like it's running the wrong linker. So back to the first question, how exactly are you doing the cross compilation. It might case some mix-up of system native and cross compilation. The build server uses essentially: export MXEDIR=/opt/mxe . ./scripts/setenv-mingw-xbuild.sh 64 ./scripts/release-common.sh -snapshot mingw64 Which does expect full MXE environment in /opt/mxe ciao, Torsten.

B

buttim

Tue, Feb 14, 2017 12:17 AM

I'm using the scripts provided:

source scripts/setenv-mingw-xbuild.sh
scripts mingw-x-build-dependencies.sh

and then running qmake and make (the way I did a few months ago)

cd mingw32.static
qmake ../openscad.pro CONFIG+=mingw-cross-env
make

--
View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20419.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I'm using the scripts provided: source scripts/setenv-mingw-xbuild.sh scripts mingw-x-build-dependencies.sh and then running qmake and make (the way I did a few months ago) cd mingw32.static qmake ../openscad.pro CONFIG+=mingw-cross-env make -- View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20419.html Sent from the OpenSCAD mailing list archive at Nabble.com.

B

buttim

Tue, Feb 14, 2017 12:29 AM

For the firs issue regarding libzip I suspect the MXE builder script simply
does not specify the libzip package.
I modified it adding libzip in 4 places and now it's downlaoding libzip and
compiling it.

This actually solves the problem but creates a new one (oh my!)

../src/import_amf.cc:330:66: error: cannot convert 'const value_type* {aka
const wchar_t*}' to 'const char*' for argument '2' to 'zip_file*
zip_fopen(zip*, const char*, zip_flags_t)'
zipfile = zip_fopen(archive, f.filename().c_str(), ZIP_FL_NODIR);

--
View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20420.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

For the firs issue regarding libzip I suspect the MXE builder script simply does not specify the libzip package. I modified it adding libzip in 4 places and now it's downlaoding libzip and compiling it. This actually solves the problem but creates a new one (oh my!) ../src/import_amf.cc:330:66: error: cannot convert 'const value_type* {aka const wchar_t*}' to 'const char*' for argument '2' to 'zip_file* zip_fopen(zip*, const char*, zip_flags_t)' zipfile = zip_fopen(archive, f.filename().c_str(), ZIP_FL_NODIR); -- View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20420.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Tue, Feb 14, 2017 12:36 AM

On 02/14/2017 01:17 AM, buttim wrote:

I'm using the scripts provided:

source scripts/setenv-mingw-xbuild.sh
scripts mingw-x-build-dependencies.sh

and then running qmake and make (the way I did a few months ago)

cd mingw32.static
qmake ../openscad.pro CONFIG+=mingw-cross-env
make

I'm not sure what's going on then, the scripts should set
up the environment to the cross compilation stuff. For some
reason you are still getting the wrong linker as the error

/usr/bin/ld: unrecognized option '--stack'

shows. I think it is supposed to run the mingw one which is

<MXE>/usr/bin/x86_64-w64-mingw32.static-ld

Can you trace all the command line output (maybe running
qmake with -d to make it verbose) into some file and put
that to pastebin or something? Maybe this gives some clue
what's going wrong.

ciao,
Torsten.

On 02/14/2017 01:17 AM, buttim wrote: > I'm using the scripts provided: > > source scripts/setenv-mingw-xbuild.sh > scripts mingw-x-build-dependencies.sh > > and then running qmake and make (the way I did a few months ago) > > cd mingw32.static > qmake ../openscad.pro CONFIG+=mingw-cross-env > make > I'm not sure what's going on then, the scripts should set up the environment to the cross compilation stuff. For some reason you are still getting the wrong linker as the error /usr/bin/ld: unrecognized option '--stack' shows. I think it is supposed to run the mingw one which is <MXE>/usr/bin/x86_64-w64-mingw32.static-ld Can you trace all the command line output (maybe running qmake with -d to make it verbose) into some file and put that to pastebin or something? Maybe this gives some clue what's going wrong. ciao, Torsten.

B

buttim

Tue, Feb 14, 2017 12:44 AM

qmakelog.zip http://forum.openscad.org/file/n20423/qmakelog.zip
the qmake output exceeded 512kB, so I could not upload it to pastebin

--
View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20423.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

qmakelog.zip <http://forum.openscad.org/file/n20423/qmakelog.zip> the qmake output exceeded 512kB, so I could not upload it to pastebin -- View this message in context: http://forum.openscad.org/Windows-cross-compilation-tp20413p20423.html Sent from the OpenSCAD mailing list archive at Nabble.com.

discuss@lists.openscad.org

Windows cross compilation