Summary: | >=dev-db/mysql-workbench-6.3.3 fails to build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Josh Holmer <shssoichiro> |
Component: | Current packages | Assignee: | Hans de Graaff <graaff> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, hydrapolic, ihatewindoz, mysql-bugs, tswatzke |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
MYSQL Server generated /usr/include/x86_64-pc-linux-gnu/mysql/my_config.h
MySQL Connector C generated /usr/include/x86_64-pc-linux-gnu/mysql/my_config.h Build log |
Description
Josh Holmer
2015-08-03 15:28:34 UTC
What are the installed versions and USE flags of virtual/mysql, virtual/libmysqlclient, dev-db/mysql, dev-db/mariadb, dev-db/percona-server, dev-db/mysql-connector-c, dev-db/mariadb-galera and/or dev-db/mysql-cluster? (Omit any that do not exist on the machine) Also, please attach the full build.log file to this bug virtual/libmysqlclient-18 virtual/mysql-5.6-r6 dev-db/mariadb-10.0.20-r1 dev-db/mysql-connector-c-6.1.6 I can't attach the build.log as it exceeds the 1000 kb limit. (In reply to Josh Holmer from comment #3) > I can't attach the build.log as it exceeds the 1000 kb limit. Compress it with bzip2 or xz first then (In reply to Brian Evans from comment #4) > (In reply to Josh Holmer from comment #3) > > I can't attach the build.log as it exceeds the 1000 kb limit. > > Compress it with bzip2 or xz first then Never mind, I tried that just now but it still fails. In Chrome I get an E_ACCESS_DENIED error. In Firefox I click the Submit button and nothing appears to happen at all. I would suspect this is related to using gcc 4.9. I have not tested that myself yet. I have the same issue. I am using gcc 4.9.x since 01/2015 and built mysql-workbench many times before. Thus it is a current bug elsewhere. Linux oriongl64 4.1.0-gentoo #1 SMP Tue Jun 23 11:40:48 CEST 2015 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux (In reply to Tom-Steve Watzke from comment #7) > I have the same issue. > I am using gcc 4.9.x since 01/2015 and built mysql-workbench many times > before. > Thus it is a current bug elsewhere. > > Linux oriongl64 4.1.0-gentoo #1 SMP Tue Jun 23 11:40:48 CEST 2015 x86_64 > Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel GNU/Linux Which mysql server and client versions are you building against? Here are my "mysql versions": $ equery -Cq l $(qlist -IC mysql) dev-db/mysql-5.6.26-r1 dev-db/mysql-connector-c++-1.1.6 dev-db/mysql-connector-c-6.1.6 dev-db/mysql-init-scripts-2.1_alpha4 dev-db/mysql-workbench-6.3.4 dev-perl/DBD-mysql-4.31.0 virtual/libmysqlclient-18 virtual/mysql-5.6-r6 I've hit the same error. The socket defines should come from the MYSQL server package... As Gentoo recently switched to virtual/libmysqlclient dev-db/mysql-connector-c I tried to downgrade my mysql version before this change. # forcefully nuke it... emerge -C virtual/libmysqlclient dev-db/mysql-connector-c # need the older virtual otherwise we pull in dev-db/mysql-connector-c again emerge -av1 =dev-db/mysql-5.6.24 =virtual/mysql-5.6-r2 As the mysql-connector-c++ linkage to libmysqlclient broke, I needed to recompile mysql-connector-c++. emerge -1 mysql-connector-c++ Compiling went fine then. So the bug seems to be hidden somewhere in the linkage or inclusion of headers from mysql package due to split in mysql-connector-c. (In reply to h.habighorst from comment #10) > I've hit the same error. > > The socket defines should come from the MYSQL server package... As Gentoo > recently switched to > > virtual/libmysqlclient > dev-db/mysql-connector-c > > I tried to downgrade my mysql version before this change. > > # forcefully nuke it... > emerge -C virtual/libmysqlclient dev-db/mysql-connector-c > > # need the older virtual otherwise we pull in dev-db/mysql-connector-c again > emerge -av1 =dev-db/mysql-5.6.24 =virtual/mysql-5.6-r2 > > As the mysql-connector-c++ linkage to libmysqlclient broke, I needed to > recompile mysql-connector-c++. > > emerge -1 mysql-connector-c++ > > Compiling went fine then. > > So the bug seems to be hidden somewhere in the linkage or inclusion of > headers from mysql package due to split in mysql-connector-c. CONFIRMED: Built without errors using this downgrade. I've had a bit more time today... Following the "trail", I noticed the following: uriel mysql # find /usr/include/mysql -type f -exec grep -Hi 'SOCKET_SIZE_TYPE' {} \; ./my_global.h:typedef socket_len_t SOCKET_SIZE_TYPE; /* Used by NDB */ So definition should come out of this package. The include path gets correctly set and used in my case (Variable MYSQL_INCLUDE_DIRS ). However: my_global.h does not get included. It seems that the inclusion of my_global.h always leads to inclusion of mysql-workbench-community-6.3.4-src/library/sql.parser/source/my_global.h As my_global.h in mysql-connector-c has MY_GLOBAL_INCLUDED defined, use explicitly that and refer to it explicitly in the mysql workbench source code. Added to the beginning of the following file: mysql-workbench-community-6.3.4-src/library/sql.parser/source/my_global.h: #ifndef MY_GLOBAL_INCLUDED #include <mysql/my_global.h> #endif This fixed compilation for me. Anyone knows maybe a nicer way? Narf. Confused myself brilliantly. Pain killer kills brain. The direction was right, the path was wrong. It's not an inclusion problem, but it seems as if some automagic disappeared somewhere... I knew I have had seen the mentioned variables somewhere but was unable to remember where. https://github.com/MariaDB/mariadb-connector-c/blob/master/cmake/CheckTypes.cmake Found them. So I think the problem is rather simple - CMake doesn't pick up some configuration definitions from the mysql package anymore. And as such, the types are not defined anymore and it fails. (In reply to h.habighorst from comment #13) > Narf. Confused myself brilliantly. Pain killer kills brain. > > The direction was right, the path was wrong. > > It's not an inclusion problem, but it seems as if some automagic disappeared > somewhere... > > I knew I have had seen the mentioned variables somewhere but was unable to > remember where. > > https://github.com/MariaDB/mariadb-connector-c/blob/master/cmake/CheckTypes. > cmake > > Found them. > > So I think the problem is rather simple - CMake doesn't pick up some > configuration definitions from the mysql package anymore. And as such, the > types are not defined anymore and it fails. MariaDB's Connector-C is not in portage. So unless you grabbed it from the mysql overlay, *and* enabled mysqlcompat (not recommended), this is a red herring. Nope. It should have been only an hint so that maybe someone else could pick up where I left. But the hint was correct. When installing mysql-5.6.24, the configure system checks for several more options and creates as such another /usr/include/x86_64-pc-linux-gnu/mysql/my_config.h as mysql-connector-c . The question is - how should this be handled? Is mysql-workbench the only package that relies on defines from my_config.h that are specific for mysql-server? Created attachment 409374 [details]
MYSQL Server generated /usr/include/x86_64-pc-linux-gnu/mysql/my_config.h
Created attachment 409382 [details]
MySQL Connector C generated /usr/include/x86_64-pc-linux-gnu/mysql/my_config.h
For example, the following defines are missing and seem to be crucial for mysql-workbench build:
#define HAVE_MEMMOVE 1
...
#define QSORT_TYPE_IS_VOID 1
#define RETQSORTTYPE void
#define SIGNAL_RETURN_TYPE_IS_VOID 1
#define RETSIGTYPE void
#define VOID_SIGHANDLER 1
#define STRUCT_RLIMIT struct rlimit
...
Created attachment 410528 [details]
Build log
Hmm.. I have 6.3.3 built, but no go for 6.3.4 Any info I can gather to help resolve this? Seems like USE flag "client-libs" adds missing defines to /usr/include/mysql/my_global.h but it conflicts with dev-db/mysql-connector-c whereas dev-db/mysql-connector-c++, it's binding, I believe, is a explicit dependency of the mysql-workbench. *** Bug 567242 has been marked as a duplicate of this bug. *** Found in the news change log:
> The client-libs USE flag turned out to be a failure and is being removed.
> There is nothing much for the user to be concerned with with that removal.
So, this can be resolved by upgrading to a version of mysql/mariadb/percona/galera/whatever that doesn't have the client-libs USE flag and rebuilding dev-db/mysql-connector-c++ against that. Then, dev-db/mysql-workbench should build successfully.
@grknight: should mysql-workbench block on dev-db/msyql-connector-c ? is this ever going fixed in forseeable future? I still get this error and cannot compile mysql-workbench. I tried the whole weekend to fiddle with versions of mariadb, mysql, gcc etc. I also did emerge -e @system and world and recompiled everything, according to https://wiki.gentoo.org/wiki/Upgrading_GCC The original solution (mentioned in comment #10) does not work anymore, because it was dated from 2015 and such versions are masked meanwhile. I even tried mysql-workbench version 8 (devel) but it is far from bug free right now, so no real option. I tried to compile with this gcc's [IP-] [ ] sys-devel/gcc-6.4.0-r1:6.4.0 [IP-] [ ] sys-devel/gcc-7.3.0-r3:7.3.0 [IP-] [ ] dev-db/mysql-5.6.40-r2:0/18 and with dev-db/mariadb:-10.0.35-r2 dev-db/mariadb:-10.1.34 All versions I have tried are currently marked as stable. Can someone please give me an idea. I cannot think of one anymore. The biggest problem with this, it always stops at 71% of compile process. That means, it takes about 3-4h before I know if it fails. That doesn't encourage to fiddle directly with the source code. I just emerged version 6.3.10 successfully. If you can live with a keyworded version, I think its worth a try. Closing since 6.3.10 is now the oldest, stable, version. |