On Sun, Jun 08, 2014 at 11:04:04AM -0700, Norbert Thiebaud wrote:
On Sun, Jun 8, 2014 at 10:55 AM, Julien Nabet <serval2412@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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.