Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2548 Error messages with latest Linux glibc

obsolete: 8.4.5
closed-fixed
Mo DeJong
8
2004-01-09
2003-12-01
Anonymous
No

Programs compiled in older version of Linux print the
following message when running under latest glibc

"Incorrectly built binary which accesses errno, h.errno
or _res directly.
Needs to be fixed."

For more info:
http://www.mail-archive.com/debian-
glibc@lists.debian.org/msg07666.html

This could be solved by ifdefing out the reference to

extern int errno

in the Tcl sources when the OS is Linux, and just using
include <errno.h>

Discussion

  • Logged In: NO

    s/Programs/Tcl interpreters and Tclkits/

     
  • Logged In: YES
    user_id=79902

    Ugh. Why can't the different Unix vendors break their
    systems *consistently*?

    Current declarations are in:
    compat/tclErrno.h
    generic/tclCompExpr.h
    generic/tclParseExpr.h
    tools/man2tcl.c
    unix/tclUnixPort.h

    The code in compat/tclErrno.h is hopefully not being used
    anyway in Linux! The two files in generic that declare it
    only do so if configure can't find <errno.h>, so that's not
    a problem (though I don't know why they don't just rely on
    tclPort.h). man2tcl.c is possibly a problem, but it isn't
    normally built and installed so it is a low priority. That
    leaves tclUnixPort.h which is just plain wrong (why does it
    include <errno.h> *and* provide a declaration for it?!)

    Fixing for random old versions of Tcl so they work against
    random combinations of build and run libs? Only if Linux
    vendors (or glibc authors; I don't care who) pay someone to
    do it, as they're the nitwits who broke things in the first
    place.

     
  • Logged In: NO

    Donald: Trust me, I am as frustrated as you are if not
    more by this :/
    I am trying to build an application binary that runs in as
    many Linux versions as possible. I run into this using
    latest TclKit, so I guess people will run into this
    eventually when use of new Kernel/glibc starts becoming
    widespread.
    Given Red Hat track record with respect to Tcl, we will
    likely need to fix or work around this ourselves

     
  • Logged In: YES
    user_id=79902

    FYI, Donald is someone else. :^)

    There are a few problems here. The first is that some parts
    of Tcl (I've not checked Tk) are declaring 'errno' for
    themselves instead of using the portability layer. That's
    wrong. The second is that the portability layer is always
    declaring 'errno' as well as including <errno.h>. That's
    also wrong (though perhaps we need to develop a configure
    test that detects when this is necessary nonetheless.)

    Finally, we need to make sure that this is fixed in
    appropriate versions of Tcl. Currently active maintenance
    happens for the 8.4 series (core-4-4-branch in CVS) and the
    development series leading to 8.5 (HEAD in CVS). But anyone
    building against old versions of Tcl will still have the
    problem; getting fixes against 8.3 will take commercial
    support/requests and getting those fixes distributed into
    the likes of RH and Debian is even more out of our hands.
    Fixing is one thing, getting the fixes used is another.

     
  • Logged In: NO

    Oops, I meant Donal (without the 'd' :)
    Just to mention that after removing the "extern int errno;"
    from tclUnixPort.h and tkUnixPort.h the problems go away

     
  • Logged In: YES
    user_id=79902

    That's not portable. Apparently, some UNIXes don't declare
    errno in <errno.h>; we're going to need a test in
    configure.in to resolve this, but I can't hack that part of
    the core (I have autoconf 2.13 on all my dev machines and no
    reasonable prospect of upgrading.)

    I've done what fixes I can; referring to a portability
    maintainer for the remaining bits (i.e. a test in
    configure/configure.in which defines NO_ERRNO when <errno.h>
    doesn't declare/define it.)

     
    • priority: 5 --> 8
     
  • Joe English
    Joe English
    2003-12-10

    Logged In: YES
    user_id=68433

    I suspect the current patch is good enough. Any system
    nowadays that doesn't declare 'errno' in <errno.h> is
    sufficiently broken that (re-)porting Tcl to it will be a
    significant amount of effort. No sense worrying about it
    now; wait until someone spots such a system in the wild first.

     
  • Mo DeJong
    Mo DeJong
    2003-12-18

    Logged In: YES
    user_id=90858

    So, what exactly needs to be done in configure.in as part of
    this
    bug report? Is there a patch attached to some other bug report
    that implements the changes discussed here? I am just unsure
    what exactly needs to be done.

     
  • Logged In: YES
    user_id=79902

    Detect whether <errno.h> provides errno (it should, but
    perhaps somewhere doesn't) and if not, #define NO_ERRNO

    Currently, we only detect the presence of the header files
    <errno.h> and <net/errno.h> but not whether they provide the
    errno symbol/#def. The test needs to be a little bit
    careful in that we don't know whether errno is a real symbol
    or not (in glibc, it is a #def that points to a thread-local
    variable, which is where this bug report came from in the
    first place.)

     
  • Logged In: YES
    user_id=79902

    The best fix might be an update to tcl.m4 to add some extra
    checking to SC_MISSING_POSIX_HEADERS since there is a high
    probability that any extension using Tcl will need errno
    (and thus hit this mess) at some point.

     
  • Joe English
    Joe English
    2003-12-22

    Logged In: YES
    user_id=68433

    I suggest not doing anything at this time. Instead, wait
    until someone comes across an actual platform that does not
    declare 'errno' in <errno.h>.

    It's impossible to port to a platform you haven't even seen.
    And any platform that fails to declare 'errno' will be
    sufficiently nonstandard that porting Tcl to it will take
    significant effort; there's no sense worrying about it
    preemptively.

     
  • Logged In: NO

    Any update on when the fix will make it?

     
  • Joe English
    Joe English
    2004-01-09

    Logged In: YES
    user_id=68433

    > Any update on when the fix will make it?

    It's fixed in CVS.

    Can I close this issue?

     
  • Logged In: YES
    user_id=79902

    No, because I'm closing it instead. :)

    (Fixes will be available in all future releases of Tcl.
    There is no definite date for the next one, since it depends
    on when Jeff feels that enough things have been changed to
    warrant another patch release. At a guess, it'll be within
    a few months.)

     
    • status: open --> closed-fixed