Build failures on Linux about slim

[bhaller]

Ah, I see. OK, well. On your spiffy machine, "long long" is longer than 64 bits, and so Eidos ought to be using a different version of these built-in functions. All part of the endless annoyance of C's platform-dependent types. So what I want to do is detect which type (int, long int, long long int) corresponds to int64_t on the target machine, and use the corresponding built-in functions. I'm not sure how to do that, but I imagine some googling will provide the answer...

[molpopgen]

The first of the errors is due to missing an #include .

On Wed, Apr 6, 2016 at 4:47 AM Ben Haller [email protected] wrote:

Ah, I see. OK, well. On your spiffy machine, "long long" is longer than 64
bits, and so Eidos ought to be using a different version of these built-in
functions. All part of the endless annoyance of C's platform-dependent
types. So what I want to do is detect which type (int, long int, long long
int) corresponds to int64_t on the target machine, and use the
corresponding built-in functions. I'm not sure how to do that, but I
imagine some googling will provide the answer...

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1 (comment)

[bhaller]

Yep. Funny how different C++ compilers have different include requirements. The missing include was not a problem on our Linux cluster, nor with clang on my OS X machine. It would be nice if compilers were more consistent about this sort of thing; it really makes it hard to write portable code. Ah well.

[molpopgen]

It is always required: http://en.cppreference.com/w/cpp/language/typeid

I'm guessing it was included as a side-effect of other includes on your
other systems. That happens, and is annoying.

On Wed, Apr 6, 2016 at 4:50 AM Kevin Thornton [email protected] wrote:

The first of the errors is due to missing an #include .

On Wed, Apr 6, 2016 at 4:47 AM Ben Haller [email protected]
wrote:

Ah, I see. OK, well. On your spiffy machine, "long long" is longer than
64 bits, and so Eidos ought to be using a different version of these
built-in functions. All part of the endless annoyance of C's
platform-dependent types. So what I want to do is detect which type (int,
long int, long long int) corresponds to int64_t on the target machine, and
use the corresponding built-in functions. I'm not sure how to do that, but
I imagine some googling will provide the answer...

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1 (comment)

[bhaller]

Right, exactly. :->

[bhaller]

I believe this bug is now fixed. I'm not sure what the etiquette is regarding closing bugs. Do I close it now? Do I wait for you to confirm that the bug is fixed on your end, and then close it? Do you close it?

[molpopgen]

Go ahead and close--it does seem to be fixed.

BTW, when making a commit, you can refer to issue numbers. For example:

git commit -am "fix for #1"

Online, those comments will show up in the Issues thread, which is handy.

On Wed, Apr 6, 2016 at 4:50 AM Kevin Thornton [email protected] wrote:

The first of the errors is due to missing an #include .

On Wed, Apr 6, 2016 at 4:47 AM Ben Haller [email protected]
wrote:

Ah, I see. OK, well. On your spiffy machine, "long long" is longer than
64 bits, and so Eidos ought to be using a different version of these
built-in functions. All part of the endless annoyance of C's
platform-dependent types. So what I want to do is detect which type (int,
long int, long long int) corresponds to int64_t on the target machine, and
use the corresponding built-in functions. I'm not sure how to do that, but
I imagine some googling will provide the answer...

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1 (comment)

[bhaller]

Aha, yes, I was wondering if there was a way to do that. OK, thanks!