OSX vs Linux: how to deal with unsigned long and uint64_t?
<p>The following code</p>

<pre><code>#include &lt;cstdio&gt;
#include &lt;cstdint&gt;
#include &lt;type_traits&gt;

int main()
{
    static const char* b2s[] = { "no", "yes" };
    printf( "%s\n", b2s[std::is_same&lt;unsigned long, uint64_t&gt;::value] ); 
}
</code></pre>

<p>returns <code>yes</code> when compiled on Linux, and <code>no</code> when compiled on OSX.</p>

<p>I read while trying on understand why that this was <a href="https://stackoverflow.com/a/11617699/472610">apparently normal</a>. 
How can I deal with this if I am developing a library and that I want it to be portable? Will I have to deal with each OS's preference?</p>

<p>Here is an example:</p>

<p><strong>foo.h</strong></p>

<pre><code>#include &lt;cstdint&gt;

template &lt;class T&gt;
struct Foo
{
    static const char id;
};
</code></pre>

<p><strong>foo.cpp</strong></p>

<pre><code>#include "foo.h"
#define DEFINE_FOO(type_,id_)                           \
    template &lt;&gt; const char Foo&lt;type_&gt;::id = id_;        \
    template &lt;&gt; const char Foo&lt;const type_&gt;::id = id_;

DEFINE_FOO(    bool,'a')
DEFINE_FOO(  int8_t,'b')
DEFINE_FOO( uint8_t,'c')
DEFINE_FOO( int16_t,'d')
DEFINE_FOO(uint16_t,'e')
DEFINE_FOO( int32_t,'f')
DEFINE_FOO(uint32_t,'g')
DEFINE_FOO( int64_t,'h')
DEFINE_FOO(uint64_t,'i')
DEFINE_FOO(   float,'j')
DEFINE_FOO(  double,'k')

// OSX requires this, but Linux considers it a re-definition
// DEFINE_FOO(unsigned long,'l')
</code></pre>

<p>As part of my library, the previous is compiled and then linked when I need to create an executable (say <code>main.cpp</code>). Typically, this looks like:</p>

<pre><code>$(CC) -c -Wall -std=c++0x -o foo.o foo.cpp
$(CC) -Wall -std=c++0x -o main main.cpp foo.o
</code></pre>

<p>That will work on one platform but fail in the other; if I uncomment <code>DEFINE_FOO(unsigned long,'l')</code> in <code>foo.cpp</code> then OSX is happy, but Linux says <code>Foo&lt;uint64_t&gt;</code> is being redefined. And vice-versa.</p>

<p>How can that be normal? Is there a "portable" way to deal with this?</p>