Strange error happens when building G-Kermit on a Slackware 9.1 box - Protocols

This is a discussion on Strange error happens when building G-Kermit on a Slackware 9.1 box - Protocols ; Hello from Gregg C Levine The strangest error turns up when building G-Kermit on a Slackware 9.1 box. (Both this one, when running Linux, and my other one.) I've even seen it happen on a Slackware 8.0 laptop. Anyway I ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Strange error happens when building G-Kermit on a Slackware 9.1 box

  1. Strange error happens when building G-Kermit on a Slackware 9.1 box

    Hello from Gregg C Levine
    The strangest error turns up when building G-Kermit on a Slackware 9.1 box. (Both
    this one, when running Linux, and my other one.) I've even seen it happen on a
    Slackware 8.0 laptop. Anyway I made a script of the error message and I am
    posting it here:
    Script started on Thu Apr 29 00:49:32 2004
    root@who6:/usr/local/src/gku100# make
    cc -DPOSIX -O -c gwart.c
    cc -o gwart gwart.o
    ../gwart gproto.w gproto.c
    11 states, 20 actions
    cc -DPOSIX -O -c gproto.c
    cc -DPOSIX -O -c gkermit.c
    cc -DPOSIX -O -c gunixio.c
    cc -DPOSIX -O -c gcmdline.c
    cc -o gkermit gproto.o gkermit.o gunixio.o gcmdline.o
    gkermit.o(.text+0x59f): In function `sfile':
    : undefined reference to `errno'
    gkermit.o(.text+0x9be): In function `seof':
    : undefined reference to `errno'
    gkermit.o(.text+0x17be): In function `decode':
    : undefined reference to `errno'
    collect2: ld returned 1 exit status
    make: *** [gkermit] Error 1
    root@who6:/usr/local/src/gku100# exit
    exit
    Both of these machines run with the 3.2.3 version of gcc, and the 2.14.90.0.6
    20030820 of the binary utilities. The first group is the actual, the last part is the date
    code. I would appreciate some help. Incidentally the current release of C-Kermit,
    built perfectly on both boxes.
    Gregg C Levine drwho8 atsign att dot net
    "This signature disavows its existence."


  2. Re: Strange error happens when building G-Kermit on a Slackware 9.1 box

    On 2004-04-29, Gregg C Levine wrote:

    : The strangest error turns up when building G-Kermit on a Slackware 9.1
    : box. (Both this one, when running Linux, and my other one.) I've even seen
    : it happen on a Slackware 8.0 laptop. Anyway I made a script of the error
    : message and I am posting it here:
    : ...
    : undefined reference to `errno'
    : ...
    :
    Evidently it is newly necessary to replace:

    extern int errno;

    with:

    #include

    in gkermit.c, but of course only in cases where the undefined reference
    happens. This is apparently part of the trend to convert errno from an
    ordinary scalar variable to some kind of a per-thread object.

    Let's hear it for stability. G-Kermit was supposed to be a simple,
    straightforward, single-thread program, that would last forever,
    It looks like forever was four years.

    Btw, it still builds OK on Slackware 9.0.0.

    - Frank

  3. Re: Strange error happens when building G-Kermit on a Slackware 9.1box

    in comp.protocols.kermit.misc i read:

    >Evidently it is newly necessary to replace:
    >
    > extern int errno;
    >
    >with:
    >
    > #include


    that's been formally necessary since c was standardized, or perhaps more
    pragmatically when using a c89/c90 or c99 conforming implementation ...

    ,----
    | errno
    |
    | which expands to a modifiable lvalue that has type int , the value
    | of which is set to a positive error number by several library
    | functions. It is unspecified whether errno is a macro or an
    | identifier declared with external linkage. If a macro definition is
    | suppressed in order to access an actual object, or a program defines
    | an external identifier with the name errno , the behavior is
    | undefined.
    `----

    >This is apparently part of the trend to convert errno from an
    >ordinary scalar variable to some kind of a per-thread object.


    yes. the intersection of c and various threading standards tends to demand
    that errno be thread-specific and i'm not aware of any implementations that
    do so with some form of behind-the-scenes magic for the object, all seem to
    use a macro that expands to, essentially, (*__errno()) which dereferences a
    pointer to the thread specific object.

    --
    a signature

+ Reply to Thread