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 >> >> >> >> >> >
