MantisBT - CMake
View Issue Details
0008937CMakeCTestpublic2009-04-28 05:292016-06-10 14:30
Michael Haubenwallner 
Bill Hoffman 
normalminoralways
closedmoved 
CMake-2-6 
 
0008937: compiler error with Large File Support and pthread on AIX (gcc-4.4.0)
On AIX, "cm_curl.h" does include system headers listening to _LARGE_FILES macro, which eventually is defined in <cmsys/Configure.h>, included via "cmCTest.h" lateron in "cmCTest.cxx".

When using '-pthread' compiler flag with gcc-4.4.0, this results in:
/usr/include/unistd.h:171: error: declaration of C function 'off64_t lseek64(int, off64_t, int)' conflicts with
/usr/include/unistd.h:169: error: previous declaration 'off_t lseek64(int, off_t, int)' here

What happens here:
  * When compiling C++, gcc defines _ALL_SOURCE, which implies _LARGE_FILE_API.
  * "cm_curl.h" includes <sys/types.h> somehow.
  * <sys/types.h> declares 'off64_t' due to _LARGE_FILE_API.
  * <sys/types.h> declares 'off_t' as 32bit, as _LARGE_FILES is not yet defined.
  * "cmsys/Configure.h" defines _LARGE_FILES.
  * Due to '-pthread', <pthread.h> gets included somehow.
  * <unistd.h> gets included by <pthread.h> due to _ALL_SOURCE.
  * <unistd.h> defines lseek to lseek64 with _LARGE_FILES defined, but still
    declares 'lseek(off_t)' and 'lseek64(off64_t)', resulting in
    'lseek64(off_t)' and 'lseek64(off64_t)' due to redefinition of lseek.

When _LARGE_FILES were defined early enough even for <sys/types.h>, off_t would be 64bit, and 'lseek(off_t)' would be the same as 'lseek64(off64_t)'.

This does not depend on Bug#7933 - as it does happen either with or without that patch, when using gcc-4.4.0, or another gcc built with the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366 [^]

So in Source/cmCTest.cxx, "cm_curl.h" has to be included _after_ "cmCTest.h", to define _LARGE_FILES early enough for <sys/types.h> to correctly declare 'off_t' as 64bit, when Large File Support is available.
To reproduce this, install gcc-4.4.0, and bootstrap cmake-2.6.3 using these commands:
$ CC=/gcc-prefix/bin/gcc \
  CXX=/gcc-prefix/bin/g++ \
  CFLAGS=-pthread \
  CXXFLAGS=-pthread \
  LIBPATH=/gcc-prefix/lib/pthread:/gcc-prefix/lib \
  ./bootstrap
$ gmake

Why to use '-pthread': On AIX, '-pthread' is a gcc multilib criterion, and needs different runpath (hence the LIBPATH setting). So I do have a wrapper script around gcc/g++, always adding '-pthread' (or a gcc with multilib disabled, but patched to default to '-pthread'), as mixing libraries built with and without '-pthread' does not work, even when the final application itself does not use threads. So I always use '-pthread', as it is required by threading libraries, and does not hurt non-threading libraries.
No tags attached.
Issue History
2009-04-28 05:29Michael HaubenwallnerNew Issue
2009-04-28 05:47Michael HaubenwallnerNote Added: 0016210
2009-09-14 14:04Bill HoffmanNote Added: 0017455
2009-09-14 14:04Bill HoffmanStatusnew => assigned
2009-09-14 14:04Bill HoffmanAssigned To => Bill Hoffman
2016-06-10 14:27Kitware RobotNote Added: 0041548
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0016210)
Michael Haubenwallner   
2009-04-28 05:47   
Including curl has been moved to first line in cvs version 1.224 by andy with comment "ERR: Fix Windows build":
http://public.kitware.com/cgi-bin/viewcvs.cgi/Source/cmCTest.cxx?root=CMake&r1=1.223&r2=1.224 [^]
(0017455)
Bill Hoffman   
2009-09-14 14:04   
Is this still an issue?
(0041548)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.