[odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw

[Andrew Cunningham]

Hi Sten,
 I am confused as to why you are trying to do this when the ODB compiler
and libraries are available on Windows. Maybe you can explain what the goal
is?

Andrew

On Sun, Oct 9, 2016 at 12:42 PM, Sten Kultakangas <ratkaisut at gmail.com>
wrote:

> Hello Boris
>
> I have just made the ODB working with the underlying cross-compiler
> x86_64-linux-gnu->i686-w64-mingw. I downloaded and built the latest
> tools from your GIT and configured ODB with
>
> ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --prefix=/i686-w64-mingw32
> --with-gxx-name=/i686-w64-mingw32/bin/i686-w64-mingw32-g++
> --with-gcc-plugin-dir=/i686-w64-mingw32/lib/gcc/i686-w64-
> mingw32/6.2.0/plugin
> CPPFLAGS='-fmax-errors=1
> -I/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/include'
>
> (note: i did not use program-prefix anymore)
>
> Also configured libodb, libodb-mssql and libodb-boost with
> ./configure --build=x86_64-linux-gnu --host=i686-w64-mingw32
> --prefix=/i686-w64-mingw32 --disable-shared --enable-static
>
> All the ODB components worked out of the box without needing to modify
> the sources. The hardest problem was to build libboost using the
> cross-compiler as it did not produce libboost_thread by default
> because of a bug in
> boost_1_62_0/libs/thread/build/Jamfile.v2
>
> A quickfix was to make the following modification:
>
> local rule default_threadapi ( )
> {
>     local api = pthread ;
>     #if [ os.name ] = "NT" { api = win32 ; }
>     api = win32 ; #xxxxx
>     return $(api) ;
> }
>
> Anyways libboost_thread is not needed by ODB but it was needed by
> ICCBackend being developed so i could not proceed with testing without
> libboost_thread.
>
> Now I uploaded the executable to a Windows server and got the following
> output:
>
> C:\Users\Administrator\Desktop\ICCBackend>ICCBackend.exe
> 35:17.621164 main Starting backend
> 35:17.628000 ...ICCBackend Registering handler for signal 2
> 35:17.628977 ...ICCBackend Registering handler for signal 21
> 35:17.628977 ...ICCBackend Registering handler for signal 15
> 35:17.628977 ...ICCBackend Attempting to bind to 127.0.0.1:8090
> 35:17.629953 ...ICCBackend Attempting to bind to [::1]:8090
> 35:17.630930 ...ICCBackend Attempting to bind to 127.0.0.1:59402
> 35:17.631907 ...ICCBackend Attempting to bind to [::1]:59402
> 35:17.631907 ...Run Running backend
> 35:22.632099 ...RefreshData Instantiating database connector
> 35:22.636005 ...RefreshData Caught signal 11 (invalid memory access)
> 35:22.683858 ...RefreshData 0xffffffff: ???
> 35:22.684835 ...RefreshData 0xffffffff: ???
> 35:22.684835 ...RefreshData 0x00000001: ???
> 35:22.685812 ...RefreshData 0x0000000c: ???
> 35:22.685812 ...RefreshData 0x00000001: ???
> 35:22.685812 ...RefreshData 0x00000003: ???
> 35:22.686788 ...RefreshData 0x00000004: ???
> 35:22.686788 ...RefreshData 0xffffffff: ???
>
> The exception was caused by the following code:
>
> void ICCBackend::RefreshData()
> {
> LogScope();
>
> filter2iccSettings.clear();
> id2skillList.clear();
> extension2skillList.clear();
> id2agentMonitor.clear();
> id2agentList.clear();
> kampanjaQueueSummary.clear();
>
> iccSettings.clear();
> iccWallboard.clear();
> skillList.clear();
> skillMonitor.clear();
> agentMonitor.clear();
> agentList.clear();
>
> Log(trace) << "Instantiating database connector";
> unique_ptr<odb::database> db(new odb::mssql::database("testbench",
> "test12345", "", "testbench\\SQLEXPRESS2005"));
> odb::transaction t(db->begin());
>
> Log(trace) << "Refreshing iCCSettings data";
> for(const auto& i : db->query<iCCSettings_view>()) {
> iccSettings.push_back(i);
> filter2iccSettings[i.Filter_lcase] = &iccSettings.back();
> }
> //...
> }
>
> So the good news is that the problem is not with the code synthesized
> by ODB (at least yet), but rather somewhere between libodb-mssql and
> odbc32.dll
> The bad news is that i don't have Windows locally and the remote
> testbench doesn't have any debugger. Sadly libbacktrace compiled with
> the cross-compiler didn't produce a correct output. I'll investigate
> the problem tomorrow when i get to the Windows workstation.
>
> Best regards,
> Sten Kultakangas
>
>
>
>
> On Sun, Oct 9, 2016 at 7:45 PM, Boris Kolpackov <boris at codesynthesis.com>
> wrote:
> > Hi Sten,
> >
> > So you are trying to use a cross-compiler as the underlying C++ compiler.
> > I don't think anyone tried this but I don't see why it shouldn't work.
> Once
> > you make it work, a summary of steps involved would be much appreciated.
> >
> > Sten Kultakangas <ratkaisut at gmail.com> writes:
> >
> >> So the main cause is that GCC plugin API was changed in version 6.2.0
> >> and ODB is not compatible with it anymore?
> >
> > Yes, that's the standard story with each major GCC version. Can you try
> > the latest pre-release which has GCC 6 compatibility fixes?
> >
> > http://codesynthesis.com/~boris/tmp/odb/pre-release/a9/
> >
> > Boris
>
>