mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Problem cross compiling TOra


From: Adam Ward
Subject: Re: [Mingw-cross-env-list] Problem cross compiling TOra
Date: Sun, 27 Sep 2015 16:50:28 +0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 27/09/15 15:21, Tony Theodore wrote:
Hi Adam,

I’m actually on the lookout for a new postgres tool and Tora looks interesting.
I gather it is a fork of an early TOAD code base, which is Oracle specific.
I have been using it at work for some time, and configured a windows build environment in a vm earlier this year (since been deleted for reasons unrelated to TOra). I am hoping that a linux based cross compile configuration can be established because the requirements for the windows compilation setup is quite large.
It currently compiles and runs fine as an ELF binary.
On 25 Sep 2015, at 22:34, Adam Ward <address@hidden> wrote:

Hi,
I am trying to cross compile TOra [1] on debian jessie for use on 64 bit 
Windows.
The error is at the end of this email, I am including my build environment to 
help troubleshoot.
Any insight is appreciated :)

I am using Docker to ensure a consistent environment, specifically a container 
by thewtex [2].
You don’t need to install wine for mxe, indeed, we finally have a way to 
disable it during builds. I advise against using it for any sort of building, 
all it does is hide problems or creates new hidden ones.

I built a container with the required packages as follows.
Some sources have moved since the base container was originally created, and 
the debian httpredir repository does not have all the required packages:
I’d suggest always using the latest mxe version (and apt for that matter), you 
don’t want to be manually maintaining such things.
I have done that as well, with the same result.

DORACLE_PATH_INCLUDES=/usr/include/oracle/11.2/client64 
-DORACLE_PATH_LIB=/usr/lib/oracle/11.2/client64/lib 
-DCMAKE_TOOLCHAIN_FILE=/usr/src/mxe/usr/x86_64-w64-mingw32.static/share/cmake/mxe-conf.cmake
 -DLOKI_LIBRARY=/usr/include/loki -DLOKI_INCLUDE_DIR=/usr/include/loki
Looks like you’re trying to mix cross-libs with native ones.
I just checked, mxe does not have a libloki-dev.
TOra cmake file fails unless I point cmake at the installed header and include for the external setup.
I have been assuming the internal one is out of date :)
-DCMAKE_SOURCE_DIR=../src -DQT5_BUILD=ON 
-DQt5Core_DIR=/usr/src/mxe/usr/x86_64-w64-mingw32.static/qt5/lib/cmake/Qt5Core 
-DQt5Gui_DIR=/usr/src/mxe/usr/x86_64-w64-mingw32.static/qt5/lib/cmake/Qt5Gui 
-DQt5Network_DIR=/usr/src/mxe/usr/x86_64-w64-
Do you really need all the `Qt5xxx_DIR` settings? Note that they point to 
non-existent directories.
As part of the container I create, qt5 is built with mxe, however I still need to point cmake to the result, otherwise it does not work.
/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-ar: /machine:X86: No such file 
or directory
/machine:X86 is an msvc flag. There’s a pull request [1] to fix this.

As a starting point, use the new prefixed cmake with these options:

x86_64-w64-mingw32.static-cmake \
     -DBOOST_ROOT=/usr/src/mxe/usr/x86_64-w64-mingw32.static/include \
     -DQT5_BUILD=ON \
     -DENABLE_PGSQL=ON \
     -DENABLE_DB2=OFF \
     -DENABLE_TERADATA=OFF \
     -DWANT_INTERNAL_LOKI=ON \
     -DWANT_INTERNAL_QSCINTILLA=OFF

You’ll run into an existing tora issue [2] unless you have specified the 
correct oracle paths. If you get past those, there will likely be mxe issues 
with cmake and static Qt linking [3] that will hopefully be resolved soon. 
Maybe try the shared builds instead in the mean time.

Cheers,

Tony


[1] https://github.com/tora-tool/tora/pull/13
[2] https://github.com/tora-tool/tora/issues/4
[3] https://github.com/mxe/mxe/issues/852


Thanks for the information, I will look into it.

Also, in CMakeLists.txt I had to change
SET(CMAKE_CXX_FLAGS_DEBUG "-O0 -fno-inline -rdynamic")
to
SET(CMAKE_CXX_FLAGS_DEBUG "-O0 -fno-inline ")
But then I ran into this problem.
However, I gather the rdynamic flag outputs functions as they are called, which is presumably why it is included for Debug releases.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]