Re: Build fail with MacOs in connectivity part
Indeed Norbert is right, I got this: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/odbcinst.h and SQLWCHAR is defined as Norbert indicated. I suppose it's 64 bits since config.log displays this: build='x86_64-apple-darwin13.2.0' build_cpu='x86_64' host_cpu='x86_64' Julien -- View this message in context: http://nabble.documentfoundation.org/Build-fail-with-MacOs-in-connectivity-part-tp4111804p4111839.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
I suppose it's 64 bits since config.log displays this: build='x86_64-apple-darwin13.2.0' build_cpu='x86_64' host_cpu='x86_64' Nope. That is misleading. For Windows, Mac and iOS, we don't use autofoo to decide whether to build 32- or 64-bit code. Instead, we build 32-bit, unless you specifically ask for 64-bit code with the --enable-64-bit configure option. (And note that for Windows a 64-bit build does not work, don't even try, unless you want to work on that.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On Sun, Jun 08, 2014 at 11:04:04AM -0700, Norbert Thiebaud wrote: On Sun, Jun 8, 2014 at 10:55 AM, Julien Nabet serval2...@yahoo.fr wrote: Now is the boost_assertion wrong or is there something else to fix? (and which one?) I doubt the assertion is wrong there. internally we use 16 bits for character representation (OUString)... 32 bit wchar_t will probably not play well with that. (I put these assertions.) Yes, exactly. I tried to avoid converting back and forth, and since all tinderbox platforms built fine, I thought I got away with it. how about not using --with-system-odbc ? any particular reason you added that ? Well, essentially this means that TDF build LibreOffice is built with a different ODBC ABI than the MacOS X system ODBC ABI. I think it does not really matter, because LibreOffice never uses the wide characters ODBC API. The code is there, many functions take a shall I use wide characters in ODBC calls bool parameter, but it is always called with false. However, if I'm wrong about this, then it will fail hard, in the form of corrupting data (character strings), because LibreOffice will provide/expect UTF-16 when the driver will expect wchar_t (which I expect will be UCS4/UTF-32). Maybe that's even what Julien was trying to investigate when trying to build with --with-system-odbc? -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On 09/06/2014 09:55, Lionel Elie Mamane wrote: Well, essentially this means that TDF build LibreOffice is built with a different ODBC ABI than the MacOS X system ODBC ABI. I think it does not really matter, because LibreOffice never uses the wide characters ODBC API. The code is there, many functions take a shall I use wide characters in ODBC calls bool parameter, but it is always called with false. However, if I'm wrong about this, then it will fail hard, in the form of corrupting data (character strings), because LibreOffice will provide/expect UTF-16 when the driver will expect wchar_t (which I expect will be UCS4/UTF-32). Maybe that's even what Julien was trying to investigate when trying to build with --with-system-odbc? Well, in fact I just copied pasted the autogen.input from my Linux to MacOs to just give a try. I had to comment every Mysql/MariaDB options since brew (a repository manager) freezed to install mysql connector (at least for some minutes when installing Mysql after having retrieved Boost and other components + build Mysql with cmake). Julien ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
I had to comment every Mysql/MariaDB options since brew (a repository manager) freezed to install mysql connector Please avoid all 3rd-party software packages when building LO for OS X. Using such is not supported and will often lead to build problems. (Unfortunately, yes, this currently means you have to install at least autoconf and automake yourself, and also manually take care of some Java bits like Ant and Junit, if you insist on building with Java support.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
Thank you Tor for these advice, I removed them. About Ant, Autoconf and Automake, I used brew. Concerning Junit, I disabled it. About 64 bits, indeed I hadn't put --enable-64-bits, I added it. Finally about Windows, I'm aware there's a pb with 64 build. I did try 1 or 2 years ago to build (just simple 32 bits) on Windows with Cygwin and had failed. Perhaps I'll give a try another time since I was on Vista and now I've got Seven :-) Julien -- View this message in context: http://nabble.documentfoundation.org/Build-fail-with-MacOs-in-connectivity-part-tp4111804p4111854.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
Le 09/06/2014 10:06, Julien Nabet a écrit : I had to comment every Mysql/MariaDB options since brew (a repository manager) freezed to install mysql connector (at least for some minutes when installing Mysql after having retrieved Boost and other components + build Mysql with cmake). Note that the connector code builds on OSX, but doesn't work, even when using the mysql C and/or C++ sources - there is some mislinking or incompatible construction going on that I haven't managed to fathom out. The dylib gets built, but fails to be recognized when called by LO dynld and throws an error. Back on topic, I haven't tried LO's ODBC support in a while on OSX 64bit, at one stage, it was completely hosed, but that was a while ago. I didn't/don't use homebrew to point to unixODBC, but take the default LO build config in this regard. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On Mon, Jun 9, 2014 at 12:55 AM, Lionel Elie Mamane lio...@mamane.lu wrote: Well, essentially this means that TDF build LibreOffice is built with a different ODBC ABI than the MacOS X system ODBC ABI. I think it does not really matter, because LibreOffice never uses the wide characters ODBC API. The code is there, many functions take a shall I use wide characters in ODBC calls bool parameter, but it is always called with false. However, if I'm wrong about this, then it will fail hard, in the form of corrupting data (character strings), because LibreOffice will provide/expect UTF-16 when the driver will expect wchar_t (which I expect will be UCS4/UTF-32). Maybe that's even what Julien was trying to investigate when trying to build with --with-system-odbc? Well, reading a bit more about it it seems to me that we 1/ use unixOdbc headers to build but at runtime on mac explicitely load libiodbc.dylib this is not liekly to end well. It seems that we _should_ be building forcibly against system-odbc on Mac... and deal with the conversion UCS4 UCS2 when on 64 bits (or better based on the size of SQLWCHAR) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
Trying to unwind, I found this: http://opengrok.libreoffice.org/xref/core/external/unixODBC/inc/odbc/sqltypes.h#112 112 #ifdef SQL_WCHART_CONVERT 113 typedef wchar_t WCHAR; 114 #else 115 typedef unsigned short WCHAR; 116 #endif After a test, I confirm that unsigned short has a size of 2 bytes. So it means that WCHAR is made from wchart_t but then I'm stuck because I don't know where's defined SQL_WCHART_CONVERT (and what it is) -- View this message in context: http://nabble.documentfoundation.org/Build-fail-with-MacOs-in-connectivity-part-tp4111804p4111807.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On Sun, Jun 8, 2014 at 9:05 AM, julien2412 serval2...@yahoo.fr wrote: --with-system-odbc Any idea? Julien with-system-odbc pick sqlext.h from the 10.8 SDK it define SQLWCHAR using #if defined(WIN32) typedef unsigned short SQLWCHAR; #else # include stdlib.h # if defined(__cplusplus) || \ defined(_WCHAR_T) || \ defined(_WCHAR_T_DEFINED) || \ defined(_WCHAR_T_DEFINED_)|| \ defined(_WCHAR_T_DECLARED)|| \ defined(_BSD_WCHAR_T_DEFINED_)|| \ defined(_BSD_WCHAR_T_)|| \ defined(_BSD_CT_RUNE_T_) typedef wchar_t SQLWCHAR; # else #error Please make sure your system supports the wchar_t type # endif #endif /* WIN32 */ iow as wchar_t which in 10.9 (iow using clang) is defined as int not short. (see i386/_types.h) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On 08/06/2014 19:29, Norbert Thiebaud wrote: On Sun, Jun 8, 2014 at 9:05 AM, julien2412 serval2...@yahoo.fr wrote: --with-system-odbc Any idea? Julien with-system-odbc pick sqlext.h from the 10.8 SDK it define SQLWCHAR using #if defined(WIN32) typedef unsigned short SQLWCHAR; #else # include stdlib.h # if defined(__cplusplus) || \ defined(_WCHAR_T) || \ defined(_WCHAR_T_DEFINED) || \ defined(_WCHAR_T_DEFINED_)|| \ defined(_WCHAR_T_DECLARED)|| \ defined(_BSD_WCHAR_T_DEFINED_)|| \ defined(_BSD_WCHAR_T_)|| \ defined(_BSD_CT_RUNE_T_) typedef wchar_t SQLWCHAR; # else #error Please make sure your system supports the wchar_t type # endif #endif /* WIN32 */ iow as wchar_t which in 10.9 (iow using clang) is defined as int not short. (see i386/_types.h) Thank you Norbert for your feedback. Now is the boost_assertion wrong or is there something else to fix? (and which one?) Julien ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On Sun, Jun 8, 2014 at 10:55 AM, Julien Nabet serval2...@yahoo.fr wrote: Now is the boost_assertion wrong or is there something else to fix? (and which one?) I doubt the assertion is wrong there. internally we use 16 bits for character representation (OUString)... 32 bit wchar_t will probably not play well with that. how about not using --with-system-odbc ? any particular reason you added that ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
On Sun, Jun 08, 2014 at 09:05:36AM -0700, julien2412 [via Document Foundation Mail Archive] wrote: I gave a try to a MacOs build and had this error: [build CXX] connectivity/source/drivers/odbc/OTools.cxx /lo/core/connectivity/source/drivers/odbc/OPreparedStatement.cxx:338:9: error: static_assert failed sizeof(SQLWCHAR) == 2 BOOST_STATIC_ASSERT( sizeof(SQLWCHAR)== 2 ); ^ /lo/core/workdir/UnpackedTarball/boost/boost/static_assert.hpp:78:41: note: expanded from macro 'BOOST_STATIC_ASSERT' # define BOOST_STATIC_ASSERT( ... ) static_assert(__VA_ARGS__, #__VA_ARGS__) Can you find me what SQLWCHAR is #define-d to in your build? Or at least the value of sizeof(SQLWCHAR)? What is your ODBC implementation? Is it unixodbc? Has it been compiled with the SQL_WCHART_CONVERT option, or do you set it in any way? Our (TDF) official build seems to use --without-system-odbc However, if the MacOS X official unixodbc uses SQL_WCHART_CONVERT, then most probably the TDF build is incompatible with the official MacOS X unixodbc :-( Is this a 32 bit build or 64 bit build? (In case that makes a difference...) All the code that fails to compile just blindly assumes that an ODBC Unicode char is 2 bytes (UCS2 or UTF-16 encoding). If that's not true on MacOS X, then it needs to be adapted :-| -- Lionel -- View this message in context: http://nabble.documentfoundation.org/Build-fail-with-MacOs-in-connectivity-part-tp4111804p4111812.html Sent from the Dev mailing list archive at Nabble.com.___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build fail with MacOs in connectivity part
Sorry Lionel, I had just checked my emails, not the forum. I'll take a look Julien -- View this message in context: http://nabble.documentfoundation.org/Build-fail-with-MacOs-in-connectivity-part-tp4111804p4111817.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
