#3128 NULL undefined in strstr.c

obsolete: 8.4.9
closed-invalid
Kevin B KENNY
5
2005-11-04
2005-05-04
Anonymous
No

The function strstr() in compat/strstr.c uses NULL as a
return value but NULL is not defined, neither locally nor
by inclusion of an appropriate header file.
I discovered this when cross-compiling the latest
tcl8.4.9 source code on a Linux x86 platform targetting
an embedded PowerPC 60x running Linux. The
configure script correctly detected that the strstr()
function needed to be build for this platform, but the
subsequent compilation failed because of the undefined
NULL. Fixing is trivial.

Discussion

  • Jeffrey Hobbs
    Jeffrey Hobbs
    2005-05-30

    • assigned_to: mdejong --> kennykb
     
  • Ivan Daniluk
    Ivan Daniluk
    2005-05-30

    Logged In: YES
    user_id=902311

    I've got the same when crosscompiling tcl8.4.9 on x86 with
    uClibc.
    Just added "#include <unistd.h>" to compat/strstr.h.

     
  • Logged In: YES
    user_id=79902

    Is this relating to Linux From Scratch? Apparently there are
    problems elsewhere in the toolchain that are causing
    troubles here; this is the subject of current issue reports
    elsewhere (LFS bugzilla?) and is not actually the result of
    real bugs in Tcl we believe.

     
  • Kevin B KENNY
    Kevin B KENNY
    2005-05-31

    • status: open --> open-duplicate
     
  • Kevin B KENNY
    Kevin B KENNY
    2005-05-31

    Logged In: YES
    user_id=99768

    I am seriously contemplating removing compat/strstr.c entirely.

    This problem is indicative of a broken toolchain. No
    compiler that supports the basic ISO C89 functionality
    requires compat/strstr.c - the configurator has incorrectly
    detected the need for it because either a compilation step
    is failing entirely or else it is totally unable to link with
    the standard library.

    This module always appears to be the "lightning rod"
    for this problem - which, as I understand it, is reported
    earlier in "configure" - can you please check from
    "make distclean" and report back with what error
    messages came out of the "configure" step?

    By the way, most people reporting this problem are
    running afoul of an error in the instructions for
    Linux From Scratch. The Tcl core team is working with
    the Linux From Scratch developers to resolve
    the issue. See
    http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/2595523
    for further details.

     
  • Ivan Daniluk
    Ivan Daniluk
    2005-05-31

    Logged In: YES
    user_id=902311

    2 dkf:
    I has been crosscompile tcl with toolchain, builded by
    buildroot(http://buildroot.uclibc.org), it has very strict
    makefiles standart.
    Many other packages build perfectly.

    2 kennykb:
    There were no error by configure, just warning:
    --- from config.log ---
    configure:4174: checking for strstr
    configure:4202:
    /home/divan/builddir/buildroot/build_i386/staging_dir/bin/i386-linux-uclibc-gcc
    -pipe -o conftest -Os -pipe -march=pentium3
    -Wl,--export-dynamic conftest.c 1>&5
    configure:4186: warning: conflicting types for built-in
    function 'strstr'
    ------

     
    • status: open-duplicate --> closed-duplicate
     
  • Logged In: YES
    user_id=79902

    Dup of bug 1175161 (fixed in HEAD)

     
  • Kevin B KENNY
    Kevin B KENNY
    2005-05-31

    Logged In: YES
    user_id=99768

    Donal, let's not close this one just yet.

    It appears that we have a couple of problems with the
    configurator here.

    First, cross-compiles are universally detected as "broken".
    This causes a conflict because compat/strtod.c and
    compat/fixstrtod.c will both be included, and they're
    incompatible.

    Second, there's an apparent issue where unix/configure is
    including system headers in the AC_TRY_RUN, and the
    declaration of strstr at line 219 of unix/configure.in
    causes a type conflict (and potential failure). I still
    contend that the best fix for this problem is to take it out
    entirely - what compiler lacks strstr nowadays?

     
  • Kevin B KENNY
    Kevin B KENNY
    2005-05-31

    • status: closed-duplicate --> open
     
  • Kevin B KENNY
    Kevin B KENNY
    2005-11-04

    Logged In: YES
    user_id=99768

    Since the underlying problem was a broken toolchain in LFS,
    I'm closing out this incident. No functioning toolchain
    encounters
    this error.

     
  • Kevin B KENNY
    Kevin B KENNY
    2005-11-04

    • status: open --> closed-invalid