/*
Check whether erfl and isnanl can be linked.
*/

#include <stdio.h>
#include <math.h>

int main(void) {
 long double rop, op = 0.6L;
 int ret;

 rop = erfl(op);
 ret = isnanl(op);

 return 0;
}
[download]

my $out = `$cc $opt -o try.exe -x c try.in -lm 2>&1`;
[download]

my $diag = $^O =~ /mswin32/i ? `try.exe 2>&1` : `./try.exe 2>&1`;
[download]

try.in:12:8: warning: incompatible implicit declaration of built-in fu
+nction 'erfl'
[download]

However, it's just occurred to me that the executable actually doesn't do anything.
Could it be that success is achieved only because the problem I'm trying to expose is being optimised away ?

So, I made the test executable actually do something, and uploaded a new version (0.14) of Math::LongDouble.
Unfortunately, I still get the same failure reports from Bingos' NetBSD smoker(s), and the test executable works fine.

I guess the next thing is to try compiling the test executable using the same cflags ($Config{ccflags}) as are used during the module build.
So, I'll try that.
Should I also include $Config{ldflags} in the build of the test executable ?
Any other ideas ? (Any other flags to include ?)

Cheers,
Rob

Let ExtUtils::Embed help, ccopts, ldopts

These functions are gcc builtins. They are optimised away. On linux, too. (Compile with -save-temps to see what is produced, or check the disassembly with objdump -d.)

To do a proper test, use separate compilation units.

/* test_isnanl.c */
#include <math.h>
int test_isnanl(long double x) { return isnanl(x); }
[download]

And link: cc main.o test_isnanl.o -lm && ./a.out || FAIL
However, the above is not entirely future-proof either—it's defeated with link-time optimisation (-flto).
So perhaps it would be better to

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(int argc, char *argv[]) {
 long double x = strtold(argv[1], NULL);
 printf("%d", isnanl(x));
 printf("%Lf", erfl(x));
 return 0;
}
[download]

Finally, if you limit your scope to the usual gcc/clang, then there is the -fno-builtin option that will make your original test work as is. This might be the best option of all.

Compile with -save-temps to see what is produced, or check the disassembly with objdump -d

Christ !! ... this is starting to look very difficult to understand.
What sort of fuck-brained system allows the use of erfl() in a C file, but not in an XS file ?

I'm also starting to worry that even if I get it working right for Bingos' smoker, I'll get it wrong elsewhere ... to the extent that the Makefile.PL will abort the build, even though the build would have succeeded had it been allowed to continue. This would be unforgivable, IMO. (My intention is simply to abort the build if erfl is not available.)

I *think* there's an option to ban certain smokers (and/or testers) from testing modules, or something like that ... so I might investigate that path instead.
I've really got better things to do than spend my time trying to figure out how Bingos' NetBSD systems work (for some questionable meaning of "work").

Thanks for the responses, guys - they're all appreciated and any hostility detected in this post is not directed towards any of them.

Cheers,
Rob