[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib stdint.h substitution of int64_t results in a linking error i
From: |
Jarno Rajahalme |
Subject: |
Re: gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX |
Date: |
Wed, 24 Nov 2010 14:44:56 +0200 |
Forced to use GCC 4.2 for a while, I notice this issue is still unresolved.
Has it been deemed proper that gnulib redefines int64_t as "long int", even
when the underlying platform (OSX) typedefs it as "long long", and this results
in linking errors due to C++ name mangling difference between "long int" and
"long long"?
The reason I have to step back from GCC 4.5 is that it does not have the
Objective-C 2.0 features that Apple uses in OSX, making it impossible to
include many of the system headers needed for GUI code.
Jarno
On Apr 15, 2010, at 23:03 , Jarno Rajahalme wrote:
> Anyone?
>
> This is still not addressed. I suspect my fix is not perfect, and similar
> consideration might be needed for the uint64_t.
>
> Jarno
>
> On Apr 8, 2010, at 8:24 PM, ext Jarno Rajahalme wrote:
>
>> I faced the following linking error trying to compile octave on OSX with GCC
>> 4.3 -m64:
>>
>> dyld: Symbol not found:
>> __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode
>> Referenced from:
>> /Users/rajahalm/testing/octave/src/.libs/liboctinterp-3.3.51+.dylib
>> Expected in: flat namespace
>> in /Users/rajahalm/testing/octave/src/.libs/liboctinterp-3.3.51+.dylib
>>
>> unmangled:
>>
>> std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char>
>> >::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode)
>>
>> /opt/local/lib/gcc43/libstdc++.6.dylib has an _almost_ matching entry:
>>
>> __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode
>>
>> unmangled:
>>
>> std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char>
>> >::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode)
>>
>> The difference is that the first parameter to seekoff() should be "long
>> long", but it is "long", as it is of type std::streamoff, which is defined
>> to be int64_t, if _GLIBCXX_HAVE_INT64_T is defined. This definition is
>> handled differently in GCC 4.4, which does not exhibit this linking problem.
>>
>> GCC 4.0 and 4.2 seem to have the same definition of std::streamoff as GCC
>> 4.3, so this problem exists with those versions as well.
>>
>> OSX /usr/include/stdint.h defines int64_t as "long long". As long as gnulib
>> stdint.h redefines this as "long int" there is going to be this linking
>> problem with GCC 4.3, even though both definitions result in the same size
>> of the std::streamoff :-)
>>
>> I tested this with the following change:
>>
>> *** lib/stdint.in.h~ Fri Apr 2 17:38:10 2010
>> --- lib/stdint.in.h Thu Apr 8 19:29:39 2010
>> ***************
>> *** 135,141 ****
>>
>> /* Do not undefine int64_t if gnulib is not being used with 64-bit
>> types, since otherwise it breaks platforms like Tandem/NSK. */
>> ! #if LONG_MAX >> 31 >> 31 == 1
>> # undef int64_t
>> typedef long int gl_int64_t;
>> # define int64_t gl_int64_t
>> --- 135,141 ----
>>
>> /* Do not undefine int64_t if gnulib is not being used with 64-bit
>> types, since otherwise it breaks platforms like Tandem/NSK. */
>> ! #if LONG_MAX >> 31 >> 31 == 1 && !(defined (__APPLE__) && defined
>> (__MACH__))
>> # undef int64_t
>> typedef long int gl_int64_t;
>> # define int64_t gl_int64_t
>> # define GL_INT64_T
>> #elif defined _MSC_VER
>> # undef int64_t
>> typedef __int64 gl_int64_t;
>> # define int64_t gl_int64_t
>> # define GL_INT64_T
>> #elif @HAVE_LONG_LONG_INT@
>> # undef int64_t
>> typedef long long int gl_int64_t;
>> # define int64_t gl_int64_t
>> # define GL_INT64_T
>> #endif
>>
>> (added lines above for reference)
>>
>> This change causes int64_t to be defined as "long long int", which seems to
>> be equivalent to "long long" for name mangling pusposes.
>>
>> With this change this linking error disappears. However, more fundamentally,
>> it seems that definition of int64_t based on a matching LONG_MAX is not
>> enough in any 64 bit C++ system, due to the name mangling difference between
>> long and long long. The proper thing would be to not redefine int64_t at all
>> if it is already defined as any type that is 64 bits long.
>>
>> Jarno
>>
>>
>>
>>
>>
>
- Re: gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX,
Jarno Rajahalme <=