This is a regression over LO 3.3.x and 3.5.x


Alex

I forgot to add that the connector is built at the same time as the main dev build.


Will test with Oracle connector download to check.

Alex

Reproduced on my libreoffice-3-6 branch.

It seems the internal mysql-connector-c++ and LibreOffice (connectivity/source/drivers/mysql/YCatalog.cxx) are compiled with a different C++ ABI.

The std::__debug::list<> implementationin YCatalog.cxx has a _M_impl._M_size member, but there is none in mysql-connector-c++-1.1.0/driver/mysql_metadata.cpp.

I remember we solved (or merely discussed?) a "problem like that" recently. Ah, I think we decided the "problem" had been solved in gcc proper...

Alex, I'm terribly busy these days; could you please:

1) force a rebuild of connectivity and mysql-connector-c++ (make connectivity.clean mysqlcppconn.clean)

2) rebuild in verbose mode (do not pass option "-s" to make)

3) compare the exact options passed to g++ in connectivity module and in mysqlcppconn module (from the build log)

I expect connectivity compiles with -std=c++11, but mysqlcppconn without.

(In reply to comment #3)

> Alex, I'm terribly busy these days; could you please: (...)

Won't be necessary anymore. Found the problem. MySQL C++ connector explicitly compiled in c++98 mode, apparently to work around a GCC bug. Attached patch removes that and fixes this bug (you need to not only make "mysqlcppcon.clean && make mysqlcppconn", but also "make mysqlc && make -o build dev-install").

What do do to about the other GCC bug? I'm not sure. Just ignore it and fail to build with GCC 4.6.1?

Created attachment 64413 [details]
bruote-force patch

@mstahl: since you introduced the "force mysqlcppconn to be compiled with -std=c++98", I'd like your input on this, so that we don't reintroduce the problem you solved...

Do we force whole LibO in -std=c++98 (or gnu++98) when compiling with
an affected gcc version and --without-system-mysql-cppconn? How can we detect
whether the version of g++ being used has the bug that led you to forcing
mysqlcppconn in c++98 mode?

Or should we do it the other way round, and force same compilation options
only for those gcc versions that broke c++98/c++11 ABI compatibility?

Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9931d736edfedb9b82a270d754f1ee8a2b134ec7

fdo#52275: Revert "mysqlcppconn: work around weird gcc issue"

Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=aeb97e51b05e1dfd6d535704a115213809c707fc&g=libreoffice-3-6

fdo#52275: Revert "mysqlcppconn: work around weird gcc issue"


It will be available in LibreOffice 3.6.1.

so i've reverted that change now (and stupidly forgot to set
Lionel as author in the master commit, but have fixed that
in the -3-6 commit).

however i don't think it's going to make any difference
on Mac OS X because i think the ancient gcc 4.0.1 we use
there doesn't support C++0x anyway, so please test
and perhaps i'll be surprised :)

(In reply to comment #8)

> 
> however i don't think it's going to make any difference
> on Mac OS X because i think the ancient gcc 4.0.1 we use
> there doesn't support C++0x anyway, so please test
> and perhaps i'll be surprised :)


OK, will rebuild and test, however Lionel's comments got me thinking, coz the autogen switches I'm using are as follows :

--enable-ext-mysql-connector
--with-libmysql-path=/Users/Shared/LO/mysql-connector-c-6.0.2-osx10.5-x86-32bit


Should I be changing these switches to something else, perhaps ?
The reason I'm using the C library is because mysqlcppconn wouldn't build for me on OSX 10.6.8




Alex

Alex,

it is quite a mystery how this mysql thing is supposed to work anyway;
AFAIK it can be built against a mysql C library or against a
mysql C++ library and both of these have to be on the system.

perhaps one of these happens to work and the other not
(on Mac at least)?

do users have to install some stuff from MySQL on the system
to be able to use the extension with LO?

fwiw, the stack trace you attached seems to indicate that an
exception is thrown somewhere in sql::mysql::MySQL_Driver::MySQL_Driver
and then not caught by anything, resulting in std::terminate.

maybe if you start it from the terminal, it prints out
the type of exception that is thrown.

(In reply to comment #10)

> it is quite a mystery how this mysql thing is supposed to work anyway;
> AFAIK it can be built against a mysql C library or against a
> mysql C++ library and both of these have to be on the system.

The C++ library is a wrapper around the C one, and thus uses the C one. This explains why both of them need to be installed.

Alex is using the system's C library, but the C++ one in the LibO sources as external module.

> fwiw, the stack trace you attached seems to indicate that an
> exception is thrown somewhere in sql::mysql::MySQL_Driver::MySQL_Driver
> and then not caught by anything, resulting in std::terminate.

Hmm... Possibly Alex was actually reporting a different problem that the one we just fixed :-|

(In reply to comment #10)

Hi Michael,

> it is quite a mystery how this mysql thing is supposed to work anyway;
> AFAIK it can be built against a mysql C library or against a
> mysql C++ library and both of these have to be on the system.
> 
> perhaps one of these happens to work and the other not
> (on Mac at least)?

I could not get the CPP library to work because of version conflicts in libmsyql16, which is why I downloaded the C library from mysql's web site, and then link to that at build time.


> 
> do users have to install some stuff from MySQL on the system
> to be able to use the extension with LO?

No, the mysql connector on Mac has historically included everything that was needed, in order to avoid having to add client libraries to the system. 

As it turns out, Apple's OSX has included a mysql server/client binaries since Leopard 10.5, but even then were/are still prone to version conflicts (since Apple was always more than a step behind with its versions). However, even with those client binaries pre-installed, one still needed to download the libmysqlclient16 libraries in order to build anything with them.



> maybe if you start it from the terminal, it prints out
> the type of exception that is thrown.

I will have a look later on today, after installing my clean build from last night.


Alex

(In reply to comment #2)


> 
> Will test with Oracle connector download to check.
> 


So, I forcibly removed the home built connector extension from my yesterday's LO dev build, restarted the app and installed the Oracle Mysql native connector extension downloaded from the AOOo extensions website - what do you know, no crash !!


Alex

(In reply to comment #10)

Hi Michael,


> it is quite a mystery how this mysql thing is supposed to work anyway;
> AFAIK it can be built against a mysql C library or against a
> mysql C++ library and both of these have to be on the system.
> 

So, I tried building once more using :


--enable-ext-mysql-connector
--with-system-mysql

and the build fails in mysqlcppconn. I'll open a separate bug issue for that with the build log.



> perhaps one of these happens to work and the other not
> (on Mac at least)?
> 

It appears that the build only completes when the external (MySQL provided source) C libraries are used. 



Alex

The link I've added to fdo#45652 is related to someone on Gentoo with build problems similar to what I experienced in the past on Mac OSX, which was the reason why I downloaded the MySQL C source libraries directly from the MySQL web site and pointed my build to them instead.


Alex

OK, so did a make clean of mysqlcppconn pointing to external mysql source libraries, it seems to build OK, but throws the following :


Compiling: mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.cpp
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.h: In copy constructor 'sql::mysql::MySQL_Warning::MySQL_Warning(const sql::mysql::MySQL_Warning&)':
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.h:45: warning: 'sql::mysql::MySQL_Warning::next' will be initialized after
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.h:44: warning:   'const sql::SQLString sql::mysql::MySQL_Warning::descr'
/Users/Shared/LO/master/mysqlcppconn/unxmacxi.pro/misc/build/mysql-connector-c++-1.1.0/driver/mysql_warning.cpp:97: warning:   when initialized here
Making:    mysqlcppconn.lib
Making:    libmysqlcppconn.dylib
/Users/Shared/LO/master/solenv/bin/checkdll.sh -L../../../../../unxmacxi.pro/lib -L/Users/Shared/LO/master/solver/unxmacxi.pro/lib  ../../../../../unxmacxi.pro/lib/libmysqlcppconn.dylib
Checking DLL ../../../../../unxmacxi.pro/lib/libmysqlcppconn.dylib ...
Multiprocessing build is finished

(In reply to comment #16)
> OK, so did a make clean of mysqlcppconn pointing to external mysql source
> libraries, it seems to build OK,

When you do that, PLUS you need to rebuild mysqlc and reinstall the extension, is the libmysqlFOO.dylib shipped as part of the extension?

Could you check that the LibO process indeed uses that library, and not the system/default one?

(In reply to comment #17)


> When you do that, PLUS you need to rebuild mysqlc and reinstall the extension,
> is the libmysqlFOO.dylib shipped as part of the extension?
> 
> Could you check that the LibO process indeed uses that library, and not the
> system/default one?


Did a pull yesterday and a clean build from a new shell. Will test later on today and report back.


Alex

Ho hum,

so now, on a fresh build, with a clean installation and LO user profile (i.e. purged from /User/alex/Library/Application Support/ before installing LOdev) :

the driver appears to be registered, but if I try to connect I get the following error :

A connection for the following URL was requested "sdbc:mysql:mysqlc:127.0.0.1:3306/ipdatabase".

and I can not connect. This error is reminiscent of the passive component registration problems that Stephan fixed with his previous commits, they haven't been reverted (partly or wholly) by any chance ?


Alex

(In reply to comment #19)

> 
> the driver appears to be registered, but if I try to connect I get the
> following error :


By "appears to be registered", I mean I can see it in the list of pre-installed extensions.


Alex

(In reply to comment #17)
> (In reply to comment #16)
> > OK, so did a make clean of mysqlcppconn pointing to external mysql source
> > libraries, it seems to build OK,
> 
> When you do that, PLUS you need to rebuild mysqlc and reinstall the extension,
> is the libmysqlFOO.dylib shipped as part of the extension?
> 

I found libmysqllo.dylib, which is present in the application in 

LOdev.app/Contents/programs directory.


lsof | grep soffice gives the following :

soffice    1399 alex  txt      REG               14,2    319660 35504633 /Applications/LOdev.app/Contents/MacOS/libmysqllo.dylib


Alex

(In reply to comment #21)
> (In reply to comment #17)
>> (In reply to comment #16)

>>> OK, so did a make clean of mysqlcppconn pointing to external mysql source
>>> libraries, it seems to build OK,

>> When you do that, PLUS you need to rebuild mysqlc and reinstall the extension,
>> is the libmysqlFOO.dylib shipped as part of the extension?

> I found libmysqllo.dylib, which is present in the application in 
> 
> LOdev.app/Contents/programs directory.

That's not the one I was looking for; I was looking for libmysql15.dylib or libmysql16.dylib or something like that. My guess is that the the .oxt file which works contains such a file, and the .oxt file that does not work does not contain it.

Any news here? If no news / no test on newer LibreOffice, we should close this bug.

Hi Lionel,

Slipped under the radar, sorry. Will have a look again this weekend. 

Alex

At the moment, this works in my LO 4.0.2, and LO 4.2 master builds with the relevant native mysql connectors, so closing as WFM.


Alex