For what it's worth, GCC 4.5 does not have this problem, as the gnulib stdint.h
tests pass, so it is not replaced. But this is specific to GCC 4.5, which is
not supported by Apple...
Jarno
On Apr 26, 2010, at 8:37 AM, Jarno Rajahalme wrote:
>
> On Apr 24, 2010, at 8:58 PM, ext Jarno Rajahal
On Apr 24, 2010, at 8:58 PM, ext Jarno Rajahalme wrote:
>
> On Apr 23, 2010, at 3:04 PM, ext Paul Eggert wrote:
>
>> Jarno Rajahalme writes:
>>
>>> So it seems that the aim is for the gnulib/stdint.h types and the
>>> macros be consistent with the system versions. If so, why not use the
>>> s
On Apr 23, 2010, at 3:04 PM, ext Paul Eggert wrote:
> Jarno Rajahalme writes:
>
>> So it seems that the aim is for the gnulib/stdint.h types and the
>> macros be consistent with the system versions. If so, why not use the
>> system versions for defining them, if they exist?
>
> Because the sys
Jarno Rajahalme writes:
> So it seems that the aim is for the gnulib/stdint.h types and the
> macros be consistent with the system versions. If so, why not use the
> system versions for defining them, if they exist?
Because the system versions are often wrong. gnulib/m4/stdint.m4
contains a fai
This in the gnulib stdint.h:
/* Get those types that are already defined in other system include
files, so that we can "#define int8_t signed char" below without
worrying about a later system include file containing a "typedef
signed char int8_t;" that will get messed up by our macro. Ou
On 04/17/2010 12:12 AM, Jarno Rajahalme wrote:
With this patch the ABI compatibility is maintained, and linking
succeeds.
It would likewise start to fail on Linux, though.
maybe a configure time check for int64_t is needed.
Yes. Already defined types should not be redefined.
Paolo
P.S.: Unfortunately my lack of C++ skill do not allow me to produce a simple
test case that would reproduce this error. The symbol has too many levels of
templates for me.
Jarno
On Apr 16, 2010, at 3:12 PM, ext Jarno Rajahalme wrote:
> Sorry for posting this same issue multiple times, but I
Sorry for posting this same issue multiple times, but I have a possibly better
proposal for fixing this this time.
I faced the following linking error trying to link octave on OSX with the stock
Apple GCC 4.2 (Xcode 3.2.2) -m64:
dyld: Symbol not found:
__ZNSt15basic_stringbufIcSt11char_traitsI
