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

Sten Kultakangas ratkaisut at gmail.com
Sun Oct 9 15:42:55 EDT 2016


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



More information about the odb-users mailing list