in reply to Re^3: [C Question] Determine if gcc provides erfl() function
in thread [C Question] Determine if gcc provides erfl() function

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
  • Comment on Re^4: [C Question] Determine if gcc provides erfl() function

Replies are listed 'Best First'.
Re^5: [C Question] Determine if gcc provides erfl() function
by Anonymous Monk on Jun 03, 2015 at 18:59 UTC

    ... so I might investigate that path instead.
    Why? From what I see, the smoker is working as intended. The functions are not available on that platform and trying to use them ends in failure.

    Standard C gives the specification for many functions; this allows the compiler to make optimizations. Such as replacing a memcpy() with immediate moves. Or replacing a printf() by puts(), etc. Or eliminating a function call that has no effect...

    What you need to test is the presence of a function *in the system library*. Thus, for the purpose of said test, you can (a) make a sufficiently complicated test, avoiding constants; (b) disable the compilers awareness of those functions by disabling c99 mode, or by using -fno-builtin.

    Gcc defines its internal builtins with the expectation that fallback is available. But if the libm is deficient... Using gnu tools on a non-gnu platform, you may run into problems like that.

[reply]
      (a) make a sufficiently complicated test, avoiding constants

      Ok - I'll start with that, keeping the other options in mind.
      I'll reply to this post, giving details of the solution I used when I find that solution.

      Thanks for your input.

      Cheers,
      Rob
[reply]
        I'll reply to this post, giving details of the solution I used when I find that solution.

        Avoiding constants in the test-executable seems to have done the trick, and I can understand how that would have worked.
        At least, there have been no FAIL reports from any NetBSD machines (and only one FAIL all up.).

        However, I was expecting that the NetBSD FAIL reports should have been replaced with UNKNOWN NetBSD reports.
        The Makefile.PL should be doing an "exit 0;", and an "exit 0;" from the Makefile.PL is supposed to result in an UNKNOWN report, isn't it ? But there have been *no* reports at all from NetBSD.

        So, I don't really know that my current version of the module has even been looked at by a NetBSD machine. (In the past, the NetBSD reports have begun filtering through within 24 hours, but that doesn't really count for much.)

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom