Professional Web Applications Themes

Portability of sinl() etc - with -lm present - PERL Modules

I get a lot of failing builds of Numeric::LL_Array since functions sinl() etc are not resolved - even when -lm is present on the link line. See, for example, http://www.nntp.perl.org/group/perl.cpan.testers/2009/04/msg3725590.html The whole failure matrix (color-coded) is in http://matrix.cpantesters.org/?dist=Numeric-LL_Array+0.04 AFAIK, all the failures are due to these functions (which are in C90 and C99) not found... And this is with gcc, not some "god-forgotten vendor-specific" compiler! :-( Anyone having an idea which additional libraries must be added? Puzzled, Ilya...

  1. #1

    Default Portability of sinl() etc - with -lm present

    I get a lot of failing builds of Numeric::LL_Array since functions
    sinl() etc are not resolved - even when -lm is present on the link line.

    See, for example,
    http://www.nntp.perl.org/group/perl.cpan.testers/2009/04/msg3725590.html

    The whole failure matrix (color-coded) is in
    http://matrix.cpantesters.org/?dist=Numeric-LL_Array+0.04

    AFAIK, all the failures are due to these functions (which are in C90
    and C99) not found... And this is with gcc, not some "god-forgotten
    vendor-specific" compiler! :-(

    Anyone having an idea which additional libraries must be added?

    Puzzled,
    Ilya
    Ilya Guest

  2. #2

    Default Re: Portability of sinl() etc - with -lm present

    On 2009-04-29, Ilya Zakharevich <org> wrote: 

    I got a conjecture: this is just a broken dynaloading model: the
    linker might ignore the -lm (i.e., do not store this flag into the
    ..so), and use ONLY the libraries linked against the `perl' executable.
    Is it viable?

    If so, would explicitly dynaloading `libm.so' (before loading the DLL
    for the module) help in this case?

    Thanks,
    Ilya
    Ilya Guest

  3. #3

    Default Re: Portability of sinl() etc - with -lm present

    Ilya Zakharevich <org> writes: 

    The sinl() function is defined in C99, but not in C90. C90 just has
    sin(); C99 has sin(), sinf(), and sinl(). A C90 implementation might
    provide sinl() as an extension (though it can't do so in conforming
    mode because "sinl" is in the user's namespace).

    You might need to play with the arguments you're passing to gcc.
    On my system, for example, if I invoke gcc with no arguments or with
    "-std=c99", it recognizes sinl(); with "-ansi", it doesn't.

    Note also that sinl() is implemented by the library, not by the
    compiler (gcc uses different libraries on different systems).

    (Yes, I know I'm responding to an article from several weeks ago.)

    --
    Keith Thompson (The_Other_Keith) org <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Guest

  4. #4

    Default Re: Portability of sinl() etc - with -lm present

    On 2009-06-17, Keith Thompson <org> wrote: [/ref]
     

    Well, AFAIU, nobody in a sane mood would use -ansi with any nontrivial
    program (on the other hand, the non-Perl part of my module IS
    extremely trivial...). Do I read it correct that your gcc has no
    problem with sinl() WITHOUT -ansi?

    And AFAICS, the compiler has no problem with sinl(); it is the dynamic
    linker which has problems... And the dynamic linker should not know
    about options of the compilers (or does BSD stores this info and
    passes it to dynalinker?)....

    Thanks anyway,
    Ilya
    Ilya Guest

  5. #5

    Default Re: Portability of sinl() etc - with -lm present

    Ilya Zakharevich <org> writes: [/ref]

    >
    > Well, AFAIU, nobody in a sane mood would use -ansi with any nontrivial
    > program (on the other hand, the non-Perl part of my module IS
    > extremely trivial...). Do I read it correct that your gcc has no
    > problem with sinl() WITHOUT -ansi?[/ref]

    I haven't tried all possible combinations of options. With the
    following trivial program:

    #include <stdio.h>
    #include <math.h>
    int main(void)
    {
    printf("%Lf\n", sinl(1.0L));
    return 0;
    }

    "gcc c.c -o c && ./c" prints "0.841471", whereas
    "gcc -ansi c.c -o c && ./c" gives me a bunch of error messages.

    Replacing "-ansi" with "-std=c99" prints "0.841471". Note that gcc
    does not fully conform to C99; see <http://gcc.gnu.org/c99status.html>
    for details. My system is Ubuntu 9.04 with gcc 4.3.3.

    I disagree with you about "-ansi", but that's probably a discussion
    for a different newsgroup.
     

    I don't know what BSD does. It appears that gcc's C90 mode treats
    "sinl" as an ordinary unreserved identifier. This means that, for
    example, it can be used as an identifier in ordinary user code. On
    the other hand, the C90 standard did reserve "sinl" and similar
    identifiers for future use. In any case, making the "sinl" function
    invisible unless you ask for either C99 support or gcc-specific
    extensions seems reasonable.

    Using "gcc -v" to show the commands that gcc executes, it appears that
    it includes the string "-ansi" in COLLECT_GCC_OPTIONS if you use "gcc
    -ansi". (The linker is /usr/lib/gcc/i486-linux-gnu/4.3.3/collect2;
    I'm not sure what the relationship between collect2 and ld is.)
    Probably the linker hides the C99-specific functions if it sees
    "-ansi" in COLLECT_GCC_OPTIONS.

    --
    Keith Thompson (The_Other_Keith) org <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Guest

  6. #6

    Default Re: Portability of sinl() etc - with -lm present

    [Joining comp.lang.c now... For context, see the failure stats of
    Numeric-LL_Array-0.04 on
    http://www.cpantesters.org/distro/N/Numeric-LL_Array.html#0.04
    (I remember seeing a color-coded version of the matrix given below; where?),
    or one report on
    http://www.nntp.perl.org/group/perl.cpan.testers/2009/04/msg3725590.html
    ]

    On 2009-06-17, Keith Thompson <org> wrote: 

    I found a BSD machine on the department network; it gives

    blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
    aa.c: In function 'main':
    aa.c:5: warning: implicit declaration of function 'sinl'
    aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
    /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
    Exit 1

    (of course, without -std=c99 one gets the same result)... So, does
    not BSD's gcc look completely broken?

    $ uname -a
    FreeBSD blue2.math.berkeley.edu 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Thu Feb 5 08:39:48 PST 2009 math.berkeley.edu:/math/blue4/FreeBSD/obj/math/blue4/FreeBSD/FreeBSD-7.1/src/sys/NETATALK i386
    $ gcc -v
    Using built-in specs.
    Target: i386-undermydesk-freebsd
    Configured with: FreeBSD/i386 system compiler
    Thread model: posix
    gcc version 4.2.1 20070719 [FreeBSD]

    ================================================== =====

    Perusing `-E -dD', I see that /usr/include/math.h is used; it has a
    lot of `#if 0':

    /*
    * long double versions of ISO/POSIX math functions
    */
    #if __ISO_C_VISIBLE >= 1999
    #if 0
    long double acoshl(long double);
    long double acosl(long double);
    long double asinhl(long double);
    long double asinl(long double);
    long double atan2l(long double, long double);
    long double atanhl(long double);
    long double atanl(long double);
    long double cbrtl(long double);
    #endif
    long double ceill(long double);
    long double copysignl(long double, long double) __pure2;
    ...

    Do not know whether they explain anything, or not...

    Thanks,
    Ilya
    Ilya Guest

  7. #7

    Default Re: Portability of sinl() etc - with -lm present

    On 2009-06-17, Ilya Zakharevich <org> wrote: 

    Aha, the colored matrix is on

    http://matrix.cpantesters.org/?dist=Numeric-LL_Array+0.04

    It makes the problem more clear...

    Ilya
    Ilya Guest

  8. #8

    Default Re: Portability of sinl() etc - with -lm present

    Ilya Zakharevich <org> writes: 
    >
    > I found a BSD machine on the department network; it gives
    >
    > blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
    > aa.c: In function 'main':
    > aa.c:5: warning: implicit declaration of function 'sinl'
    > aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
    > /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
    > Exit 1
    >
    > (of course, without -std=c99 one gets the same result)... So, does
    > not BSD's gcc look completely broken?[/ref]

    gcc is probably doing exactly what it should be doing. As I mentioned
    upthread (but not here in comp.lang.c), sinl() is provided by the
    runtime library, not by the compiler. It looks liike FreeBSD's
    runtime library doesn't provide sinl().

    [...]
     

    Well, the "#if 0" certainly explains why gcc complains about an
    implicit declaration of sinl, since the explicit declaration doesn't
    exist. I presume the math.h header file and the library are from the
    same source and are consistent with each other.

    As far as C is concerned, all that can really be said is the
    following:

    The C90 standard doesn't define the sinl function, but it does reserve
    the identifier for future use.

    The C99 standard does define the sinl function, so any conforming C99
    implementation must provide it. Note that an implementation includes
    both the compiler and the runtime library, which may be provided
    seaprately. Note also that there are not yet very many conforming C99
    implementations. (But gcc is perfectly able to use sinl if the
    library provides it.)

    I'd say this is a FreeBSD issue, not a C issue. Possibly whatever
    code you're working with needs to be configurable so it will work on
    systems that don't provide sinl.

    --
    Keith Thompson (The_Other_Keith) org <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Guest

  9. #9

    Default Re: Portability of sinl() etc - with -lm present

    On Jun 17, 4:46pm, Keith Thompson <org> wrote: 
    > [/ref]
    > [/ref]



    >
    > gcc is probably doing exactly what it should be doing. As I mentioned
    > upthread (but not here in comp.lang.c), sinl() is provided by the
    > runtime library, not by the compiler. It looks liike FreeBSD's
    > runtime library doesn't provide sinl().[/ref]

    Aside to the OP:
    You can fill out the missing functions with the Cephes library:
    http://www.moshier.net/#Cephes
    assuming that the long double type is suppored by the compiler as
    distinct from double.

    If sizeof(long double) == 8 then it won't help. If it's bigger than
    that, then it will.
    The Cephes library has support for {among other things} 80 and 128 bit
    long double.

    [snip]
    user923005 Guest

  10. #10

    Default Re: Portability of sinl() etc - with -lm present

    On 2009-06-17, Keith Thompson <org> wrote: 
    >
    > gcc is probably doing exactly what it should be doing. As I mentioned
    > upthread (but not here in comp.lang.c), sinl() is provided by the
    > runtime library, not by the compiler.[/ref]

    ??? What part of "builtin function" is not clear?
     

    Not surprising, if it is builtin (which, in turn, is not surprising if
    on i386, and long double is 80-bit). But somehow it is not 'activated'...
     

    I know no way to check for this...

    Thanks,
    Ilya
    Ilya Guest

  11. #11

    Default Re: Portability of sinl() etc - with -lm present

    Keith Thompson <org> writes: 
    >>
    >> I found a BSD machine on the department network; it gives
    >>
    >> blue2:/tmp/iz/Numeric-LL_Array-0.04->gcc -std=c99 -Wall -o c c.c -lm
    >> aa.c: In function 'main':
    >> aa.c:5: warning: implicit declaration of function 'sinl'
    >> aa.c:5: warning: incompatible implicit declaration of built-in function 'sinl'
    >> /var/tmp//ccXLekMc.o(.text+0x2c): In function `main': : undefined reference to `sinl'
    >> Exit 1
    >>
    >> (of course, without -std=c99 one gets the same result)... So, does
    >> not BSD's gcc look completely broken?[/ref]
    >
    > gcc is probably doing exactly what it should be doing.[/ref]

    ?!??!?!

    [...]
     

    So gcc, with the c99 switch, is *not* what doing what it should be
    doing then?

    Phil
    --
    Marijuana is indeed a dangerous drug.
    It causes governments to wage war against their own people.
    -- Dave Seaman (sci.math, 19 Mar 2009)
    Phil Guest

  12. #12

    Default Re: Portability of sinl() etc - with -lm present

    Phil Carmody wrote: 
    >> gcc is probably doing exactly what it should be doing.[/ref]
    >
    > ?!??!?!
    >
    > [...]

    >
    > So gcc, with the c99 switch, is *not* what doing what it should be
    > doing then?
    >
    > Phil[/ref]

    (1) gcc is always right.
    (2) If you find a bug in gcc then goto (1)

    jacob Guest

  13. #13

    Default Re: Portability of sinl() etc - with -lm present

    Phil Carmody <co.uk> writes: [/ref]
    [...] 
    >>
    >> gcc is probably doing exactly what it should be doing.[/ref]
    >
    > ?!??!?!
    >
    > [...]

    >
    > So gcc, with the c99 switch, is *not* what doing what it should be
    > doing then?[/ref]

    gcc is only part of the implementation. The combination of gcc and
    the FreeBSD library apparently is not a conforming C99 implementation,
    but given the library's failure to conform, gcc appears to be doing
    its job.

    --
    Keith Thompson (The_Other_Keith) org <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Guest

  14. #14

    Default Re: Portability of sinl() etc - with -lm present

    Phil Carmody said:
     
    <snip> 
    >
    > So gcc, with the c99 switch, is *not* what doing what it should be
    > doing then?[/ref]

    Since gcc doesn't claim to be a conforming C99 implementation, I
    don't see why it is obliged to do anything at all about sinl. On
    this occasion Jacob Navia is quite right (elsethread) - gcc is
    behaving correctly.

    If gcc claimed C99 conformance, that would be a different matter.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh
    Forged article? See
    http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Guest

  15. #15

    Default Re: Portability of sinl() etc - with -lm present

    Ilya Zakharevich <org> writes: 
    >>
    >> gcc is probably doing exactly what it should be doing. As I mentioned
    >> upthread (but not here in comp.lang.c), sinl() is provided by the
    >> runtime library, not by the compiler.[/ref]
    >
    > ??? What part of "builtin function" is not clear?[/ref]

    That would be the part where I didn't notice that phrase in the error
    message.
     
    >
    > Not surprising, if it is builtin (which, in turn, is not surprising if
    > on i386, and long double is 80-bit). But somehow it is not 'activated'...[/ref]

    A little more experimenting with gcc, particularly with the "-S"
    option to generate an assembly listing, shows that:

    sinl(1.0L) is replaced by a constant value.

    sinl(x), where x is a run-time value, generates an actual call to
    the sinl() function.

    But if I comment out the "#include <math.h>" to hide the declaration
    of sinl(), I get the same "incompatible implicit declaration of
    built-in function 'sinl'" even if the argument is a run-time value.
    I'm not sure what gcc means by "built-in" here, but it's not built
    into the compiler for all calls; it does depend on the run-time
    library.
     
    >
    > I know no way to check for this...[/ref]

    If adding your own declaration for sinl:

    long double sinl(long double);

    corrected the problem, that would indicate that the library provides
    the function but <math.h> doesn't declare it. But since you got a
    linker error ("undefined reference to `sinl'") as well as the
    compile-time error, it appears that <math.h> doesn't declare sinl
    *and* the library doesn't define it.

    I think you'll either have to do without sinl(), or provide your own
    implementation of it.

    --
    Keith Thompson (The_Other_Keith) org <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Guest

  16. #16

    Default Re: Portability of sinl() etc - with -lm present

    Keith Thompson <org> writes: [/ref]
    > [...] 
    >>
    >> ?!??!?!
    >>
    >> [...]
    >> 
    >>
    >> So gcc, with the c99 switch, is *not* what doing what it should be
    >> doing then?[/ref]
    >
    > gcc is only part of the implementation. The combination of gcc and
    > the FreeBSD library apparently is not a conforming C99 implementation,
    > but given the library's failure to conform, gcc appears to be doing
    > its job.[/ref]

    If you're prepared to draw that distinction, then yes. However,
    I don't view math.h to not be part of the compiler just because
    it was bundled in a different package from the compiler engine.
    Of course, by the time BSD have got their hands and mangled it,
    it's no longer GNU's gcc that is to blame, rather BSD's version
    in this instance. But I still view BSD's version of the imple-
    mentation being broken as the compiler being broken.

    Phil
    --
    Marijuana is indeed a dangerous drug.
    It causes governments to wage war against their own people.
    -- Dave Seaman (sci.math, 19 Mar 2009)
    Phil Guest

  17. #17

    Default Re: Portability of sinl() etc - with -lm present

    Richard Heathfield <sig.invalid> writes: 
    > <snip> 
    >>
    >> So gcc, with the c99 switch, is *not* what doing what it should be
    >> doing then?[/ref]
    >
    > Since gcc doesn't claim to be a conforming C99 implementation, I
    > don't see why it is obliged to do anything at all about sinl. On
    > this occasion Jacob Navia is quite right (elsethread) - gcc is
    > behaving correctly.
    >
    > If gcc claimed C99 conformance, that would be a different matter.[/ref]

    It claims to be aiming for C99 conformance. No compiler achieved
    its final goals with its first release, to imagine one would is
    to live in cloud cuckoo land.

    Phil
    --
    Marijuana is indeed a dangerous drug.
    It causes governments to wage war against their own people.
    -- Dave Seaman (sci.math, 19 Mar 2009)
    Phil Guest

  18. #18

    Default Re: Portability of sinl() etc - with -lm present

    Phil Carmody <co.uk> writes: 
    [...] 
    >
    > If you're prepared to draw that distinction, then yes. However,
    > I don't view math.h to not be part of the compiler just because
    > it was bundled in a different package from the compiler engine.
    > Of course, by the time BSD have got their hands and mangled it,
    > it's no longer GNU's gcc that is to blame, rather BSD's version
    > in this instance. But I still view BSD's version of the imple-
    > mentation being broken as the compiler being broken.[/ref]

    Then you're using the word "compiler" in a way that's entirely
    inconsistent with the way I use it.

    Personally, I find it very useful to have a word "compiler" that
    refers to a particular subset of an implementation, and another word
    "library" that refers to another subset. And I can use the word
    "implementation" to refer to the whole thing. Do you really consider
    these to be unimportant distinctions? And do you consider glibc, for
    example, to be part of a "compiler", even though it doesn't actually
    compile anything?

    --
    Keith Thompson (The_Other_Keith) org <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Guest

  19. #19

    Default Re: Portability of sinl() etc - with -lm present

    Ilya Zakharevich wrote: 
    >> gcc is probably doing exactly what it should be doing. As I mentioned
    >> upthread (but not here in comp.lang.c), sinl() is provided by the
    >> runtime library, not by the compiler.[/ref]
    >
    > ??? What part of "builtin function" is not clear?[/ref]

    The function definition is built in; the declaration for that function
    which should be provided by <math.h> is not built-in.
     
    >
    > Not surprising, if it is builtin (which, in turn, is not surprising if
    > on i386, and long double is 80-bit). But somehow it is not 'activated'...

    >
    > I know no way to check for this...[/ref]

    Use gcc -E to find out which file it is using for <math.h>. Examine that
    file to determine whether it provides a declaration for sinl().
    James Guest

  20. #20

    Default Re: Portability of sinl() etc - with -lm present

    Keith Thompson wrote: [/ref]
    > [...] 
    >> ?!??!?!
    >>
    >> [...]
    >> 
    >>
    >> So gcc, with the c99 switch, is *not* what doing what it should be
    >> doing then?[/ref]
    >
    > gcc is only part of the implementation. The combination of gcc and
    > the FreeBSD library apparently is not a conforming C99 implementation,
    > but given the library's failure to conform, gcc appears to be doing
    > its job.[/ref]

    With a bit of Googling about sinl() and FreeBSD, it appears that (as of
    the last reference I can find, several years old) FreeBSD's libc does
    not support long doubles well, and they're blaming it on bugs in GCC
    that prevent them from doing so. Apparently, GCC doesn't really
    understand the difference between double and long double, so sometimes
    variables end up with more or less precision, respectively, than they're
    supposed to have. With x87's 80-bit precision going away in x64 (which
    specified SSE math), though, it won't matter for much longer.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Isaac Jaffe
    Stephen Guest

Page 1 of 3 123 LastLast

Similar Threads

  1. Portability
    By Yomna el-Tawil in forum PERL Beginners
    Replies: 2
    Last Post: November 19th, 06:54 PM
  2. PHP Portability Tip
    By Google Mike in forum PHP Development
    Replies: 1
    Last Post: October 13th, 03:18 PM
  3. C library calls - portability
    By Miklos in forum UNIX Programming
    Replies: 3
    Last Post: September 3rd, 09:20 AM
  4. dlopen portability
    By Tobias Oed in forum UNIX Programming
    Replies: 3
    Last Post: August 5th, 02:11 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139