MySQL Bugs: #68884: CMake on OpenIndiana userland can't compile 64 bit

Bug #68884	CMake on OpenIndiana userland can't compile 64 bit
Submitted:	8 Apr 2013 4:01	Modified:	21 Apr 2018 20:24
Reporter:	Adam Stylinski	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.6.16	OS:	Other (OpenIndiana 151a7)
Assigned to:	Tor Didriksen	CPU Architecture:	Any

Description:
A large enough portion of my day was spent trying to get Solaris Studio to compile MySQL 5.6.10 as a 64 bit binary in OpenIndiana.  For whatever reason the CMake tests for CHARP and VOIDP were continuously reporting 4 byte sizes instead of 8 byte, despite me setting compiler flags everywhere to -m64.  I even tried forcing in CMakeLists.txt the CMAKE_REQUIRED_FLAGS to contain -m64 but to no avail, the types were still being detected as 4 bytes long.  In the end I solved the problem by modifying manually the autogenerated my_config.h to have CHARP, VOIDP, and SIZEP as 8 bytes.  This obviously is not the ideal or clean way of doing things and this may actually have some unforseen bugs, I still have to test this.  

Can there please be a supported way to build a 64 bit package of mysql on OpenIndiana and friends?  I tried looking through the spiderweb of config files and generated code via CMake but got pretty frustrated.

How to repeat:
1.) ccmake .
2.) set compilers to /opt/SUNWspro/bin/cc and CC
3.) set compilers flags to include -m64
4.) set linker flags to include -m64 -L/lib/64 -L/usr/sfw/lib/64
5.) generate
6.) make

Ends up with a compiler error stating:
"/code/mysql-server/mysql-5.6/mysys/my_atomic.c", line 30: zero or negative subscript

This is due to a compiler assert statement at that line comparing the intptr type with sizeof(void*).  There are also several various preprocessor statements that index into arrays with size definitions related to this.  

Suggested fix:
Have a "64 bit" CMake option that will ignore the default tests or make the default tests check sizeof() outputs from binaries compiled with the set CMAKE_C_FLAGS.

how did you invoke cmake?
On sparc I do:
cmake -DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64  

which works for both sun studio, and gcc.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Having the same on  Solaris 10 server when compiling 5.6.11 build:

[ 18%] Building C object mysys/CMakeFiles/mysys.dir/my_atomic.c.o
"/udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/mysys/my_atomic.c", line 30: zero or negative subscript
cc: acomp failed for /udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/mysys/my_atomic.c
*** Error code 2
The following command caused the error:
cd /udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/mysys && /opt/SolarisStudio12.3-solaris-sparc-bin/solarisstudio12.3/bin/cc  -DHAVE_RWLOCK_T -DHAVE_CONFIG_H -m64 -xO3 -g -Xa -xstrconst -mt -xarch=sparc -DDBUG_OFF -I/udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/include -I/udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/zlib -I/udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/mysys -KPIC -o CMakeFiles/mysys.dir/my_atomic.c.o   -c /udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11/mysys/my_atomic.c
make: Fatal error: Command failed for target `mysys/CMakeFiles/mysys.dir/my_atomic.c.o'
Current working directory /udir/rooijenp/ams_wc/ams_perl/src/shlibs/mysql-5.6.11

Still having this issue with 5.6.16.  I'm setting the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS via the "advanced" toggle in the curses based CMake dialog (ccmake).  It should also be noted that this same issue occurs for me while trying to build a 64 bit build for x86 (using OpenIndiana and Solaris Studio).  Manually fixing the compiler preprocessor statements in the one header that seems to affect the memory sizes seems to fix it, but obvious modifying autogenerated headers is probably at best a band-aid and at worst results in incorrect code if I'm missing other autogenerated files.

Wonder if currently it is still an issue?. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".