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