[CMake] Cross Compile MySQL Connector/C for Linux/PowerPC architecture using CMake - Failure

[Niranjan M]

Hi,
    This problem is now resolved, my tool chain already had a definition
for RINT which was causing the problem, but cmake was unable to detect it.
I commented out this part from my_global.h file which solved the problem.

With Regards,
Niranjan

On Wed, Mar 20, 2013 at 6:03 PM, Niranjan M <studywireless at gmail.com> wrote:

> Hi Brad,
>            I figured out the problem. I was passing some compilation flags
> for my C compiler via CMAKE which was preventing the .bin from being
> generated. Now I have a new problem but I am not sure if this is the
> correct forum to discuss it as its related to application (mysqlclient).
>
> After CMAKE is done, I do a make and below is the error.
>
> *[  0%] Building C object vio/CMakeFiles/vio.dir/vio.c.o
> In file included from DIR/mysql-connector-c-6.0.2/vio/vio_priv.h:19,
>                  from **DIR/mysql-connector-c-6.0.2/vio/vio.c:23:
> **DIR/mysql-connector-c-6.0.2/include/my_global.h:1583: error: static
> declaration of 'rint' follows non-static declaration
> make[2]: *** [vio/CMakeFiles/vio.dir/vio.c.o] Error 1
> make[1]: *** [vio/CMakeFiles/vio.dir/all] Error 2
> make: *** [all] Error 2
> *
> There is a single declaration of the function rint as shown below
>
> #ifndef HAVE_RINT
>
> /**
>   All integers up to this number can be represented exactly as double
> precision
>   values (DBL_MANT_DIG == 53 for IEEE 754 hardware).
> */
>
> #define MAX_EXACT_INTEGER ((1LL << DBL_MANT_DIG) - 1)
>
> /**
>   rint(3) implementation for platforms that do not have it.
>   Always rounds to the nearest integer with ties being rounded to the
> nearest
>   even integer to mimic glibc's rint() behavior in the "round-to-nearest"
>   FPU mode. Hardware-specific optimizations are possible (frndint on x86).
>   Unlike this implementation, hardware will also honor the FPU rounding
> mode.
> */
>
> static inline double rint(double x)    --> line 1583
> {
>   double f, i;
>   f = modf(x, &i);
>
>   /*
>     All doubles with absolute values > MAX_EXACT_INTEGER are even anyway,
>     no need to check it.
>   */
>   if (x > 0.0)
>     i += (double) ((f > 0.5) || (f == 0.5 &&
>                                  i <= (double) MAX_EXACT_INTEGER &&
>                                  (longlong) i % 2));
>   else
>     i -= (double) ((f < -0.5) || (f == -0.5 &&
>                                   i >= (double) -MAX_EXACT_INTEGER &&
>                                   (longlong) i % 2));
>   return i;
> }
> #endif /* HAVE_RINT */
>
> With Regards,
> Niranjan
>
>
> On Wed, Mar 20, 2013 at 2:18 PM, Niranjan M <studywireless at gmail.com>wrote:
>
>> Hi Brad,
>>            Thanks for the help. I uninstalled my older CMAKE 2.8.7 ans
>> installed the latest CMAKE which is 2.8.10.2.
>>
>> I am still getting the same error. I think the executable is not being
>> generated as shown by the below lines
>>
>> *
>> -- Detecting C compiler ABI info
>> CMake Error at
>> /net/dslabfs/dsl01/users/nmahabaleshwar/NewDataBaseStuff/cmake/cmake-2.8.10.2-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31
>> (try_compile):
>>
>>
>> Cannot copy output executable
>>     ''
>>   to destination specified by COPY_FILE:
>> .
>> .
>> .
>> *Below is the line where the problem occurs in the file
>> CMakeDetermineCompilerABI.cmake line 31
>>
>> *try_compile(CMAKE_${lang}_ABI_COMPILED*             * --> ERROR*
>>       ${CMAKE_BINARY_DIR} ${src}
>>       CMAKE_FLAGS "${CMAKE_FLAGS}"
>>                   "-DCMAKE_${lang}_STANDARD_LIBRARIES="
>>                   # We need ignore these warnings because some platforms
>> need
>>                   # CMAKE_${lang}_STANDARD_LIBRARIES to link properly and
>> we
>>                   # don't care when we are just determining the ABI.
>>                   "--no-warn-unused-cli"
>>       OUTPUT_VARIABLE OUTPUT
>>       COPY_FILE "${BIN}"
>>       )
>>
>> Does it mean the file is not being compiled. I checked in a couple of
>> other posts and found that if a custom compiler is used *try_compile*uses information provided in CMakePlatformTests.txt file to get more
>> information about the custom compiler to generate the executable. Should I
>> provide additional information ? When I setup my tool chain the compiler is
>> available at shell (ppc_4xx-gcc and ppc_4xx-g++). This problem is specific
>> to my tool chain, cmake works fine for gcc and g++ in my environment.
>>
>> Another thing to note is that the problem is only for *ppc_4xx-gcc*which is my C compiler, I am not getting similar problem for
>> *ppc_4xx-g++* which is my C++ compiler.
>>
>> I am attaching the new build file.
>>
>> With Regards,
>> Niranjan
>>
>>
>> On Wed, Mar 20, 2013 at 1:24 PM, Brad King <brad.king at kitware.com> wrote:
>>
>>> On 3/19/2013 5:51 PM, Niranjan M wrote:
>>> > --debug-trycompile
>>> ...
>>> > -- Detecting C compiler ABI info
>>> >   Unable to find the executable at any of:
>>> >
>>> >     DIR/mysql-connector-c-6.0.2/CMakeFiles/CMakeTmp/cmTryCompileExec
>>> >
>>> DIR/mysql-connector-c-6.0.2/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec
>>> >
>>> DIR/mysql-connector-c-6.0.2/CMakeFiles/CMakeTmp/Development/cmTryCompileExec
>>>
>>> This means CMake cannot find any executable produced by the
>>> compiler after building a small test project.  CMake wants
>>> to find the executable to read information about its ABI as
>>> produced by the compiler toolchain.
>>>
>>> The problem is either that the executable really isn't being
>>> produced or that the toolchain names it something other than
>>> what CMake thinks.  Before we spend too much time on this
>>> please test with a more recent CMake version.
>>>
>>> -Brad
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130327/1630fb43/attachment.htm>