[CMake] cmake shared library exported symbols on 64bit AIX XLC compiler

[Michael Hufer]

Hi,
We already supply the correct CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to the 
compiler and link flags for 64bit. So the issue is not with the compiler 
or linker but the "CreateExportList"- tool cmake invokes to generate the 
list of symbols to be exported by the shared library before linking it.

See the attached file for the link.txt, created by cmake for one of our 
libraries, to see what calls cmake generated to link it. The second step 
- to link the library -  (/usr/vacpp/bin/xlC_r    -q64 ...) has the 
correct flag to generate 64bit output (-q64), but the first step - to 
generate the exported symbols list -. (/usr/vacpp/bin/CreateExportList 
... ) is missing the "-X64" argument it needs to find the symbols for a 
64bit build. So the compile and link steps have the correct flags but 
the tool to create the list of exported symbols for the library has not.

The consequence is that the generated library does not export ANY symbol 
and this of course provokes the missing symbol errors wenn linking 
against it. A workaround I found is to set the shell environment 
variable "OBJECT_MODE" to "64" before invoking a (c)make. But I think 
this should be handled correctly by cmake, as cmake knows whether it 
creates a 32 or 64 bit library (sizeof(void*)) and can then set the flag 
for "/usr/vacpp/bin/CreateExportList" correctly.


Regards,
     Michael.

On 02/20/2015 03:34 AM, Roman Bolshakov wrote:
> If your project is supposed to be built 64-bit only on 64-bit build 
> host and 32-bit only on 32-bit one, you can just append proper flag 
> into CMAKE_CXX_FLAGS and CMAKE_C_FLAGS depending on the value of 
> CMAKE_SIZEOF_VOID_P 
> (http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SIZEOF_VOID_P.html).
>
> In the case of multi-lib OS (where you can build both 32-bit and 
> 64-bit app on the same 64-bit build host) you could specify something 
> like -DPLATFORM=32 -DPLATFORM=64 when you invoke CMake. The approach 
> would require you to have two separate build trees though.

-- 
Michael Hufer
Senior Software Developer
-------------------------------
Dion Global Solutions GmbH
Mainzer Landstr. 199  I  60322 Frankfurt am Main  I  Germany
phone: +49 69 50952 241
email:michael.hufer at dionglobal.com | web: www.dionglobal.com/de
HRB-Nr./Commercial Register No. 83397
Geschäftsführer / Managing Directors: Ralph James Horne, Joseph Nash

-------------- next part --------------
/usr/vacpp/bin/CreateExportList CMakeFiles/xmq_s.dir/objects.exp CMakeFiles/xmq_s.dir/Xmq.cpp.o CMakeFiles/xmq_s.dir/XmqMsgDump.cpp.o CMakeFiles/xmq_s.dir/xmq_s_version.cpp.o
/usr/vacpp/bin/xlC_r    -q64 -qthreaded -qalias=noansi -qhalt=e -qtwolink -qrtti=all -qinlglue -qnotemplateregistry -qnotempinc -qlanglvl=newexcp -g -L/home/xgbuild/xgen-trunk/lib/AIX_p64 -L/home/xgbuild/xgen-trunk/external/AIX_p64/libs/mqs-6.0/lib -qexpfile=export.symbols -q64 -bh:5 -lc -lm -G -Wl,-bnoipath -Wl,-bE:CMakeFiles/xmq_s.dir/objects.exp  -o libxmq_s.so CMakeFiles/xmq_s.dir/Xmq.cpp.o CMakeFiles/xmq_s.dir/XmqMsgDump.cpp.o CMakeFiles/xmq_s.dir/xmq_s_version.cpp.o  -L/home/xgbuild/xgen-trunk/lib/AIX_p64 ../libxgencore/libxgencore.so -lmqm_r -lmqmxa64_r -lACE -lexpat -lpcre -Wl,-blibpath:/home/xgbuild/xgen-trunk/build/pitbull/src/libxgencore:/home/xgbuild/xgen-trunk/lib/AIX_p64:/usr/lib:/lib