gmtime_r - Kerberos

This is a discussion on gmtime_r - Kerberos ; Hey folks, I'm compiling 5-1.4.1 on Solaris 9 and I get: WARNING: Some functions that are needed for library thread WARNING: safety appear to be missing. WARNING: missing thread-safe function: gmtime_r WARNING: Without these functions, the installed libraries WARNING: may ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: gmtime_r

  1. gmtime_r

    Hey folks,

    I'm compiling 5-1.4.1 on Solaris 9 and I get:

    WARNING: Some functions that are needed for library thread
    WARNING: safety appear to be missing.
    WARNING: missing thread-safe function: gmtime_r
    WARNING: Without these functions, the installed libraries
    WARNING: may not be thread-safe.

    This is _really_ strange since:

    1. gmtime_r() is part of time.h
    2. This didn't happen on 1.3.3, I just went back and checked.

    The config.log doesn't give any sort of useful information on how it arrived
    at this decision, it just says:

    configure:8373: checking for gmtime_r
    configure:8435: result: no
    ...
    configure:8456: WARNING: Some functions that are needed for library thread
    configure:8458: WARNING: safety appear to be missing.
    configure:8461: WARNING: missing thread-safe function: gmtime_r
    configure:8464: WARNING: Without these functions, the installed libraries
    configure:8466: WARNING: may not be thread-safe.

    I did notice, however, that configure in 1.3.3 doesn't appear to look for
    gmtime_r....

    I'm not keen on my KDC crashing due to lack of thread saftey.

    Thoughts?


    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCg9og7lkZ1Iyv898RAonjAJ90zehA5ACRfES6TVsuph 8NyH8ihwCeOI51
    lZLu3IL1QwiwThM7W1YhHGc=
    =Bjkx
    -----END PGP SIGNATURE-----


  2. [PATCH] Re: gmtime_r

    On Thu, May 12, 2005 at 03:35:12PM -0700, Phil Dibowitz wrote:
    > Hey folks,
    >
    > I'm compiling 5-1.4.1 on Solaris 9 and I get:


    I was able to fix this:

    --- configure.orig Thu May 12 18:13:10 2005
    +++ configure Thu May 12 18:13:34 2005
    @@ -8380,6 +8380,7 @@
    cat >conftest.$ac_ext <<_ACEOF
    #line $LINENO "configure"
    #include "confdefs.h"
    +#include
    /* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char $ac_func (); below. */
    #include



    You need to include time.h in order to find gmtime_r().

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCg//Y7lkZ1Iyv898RAoxpAJoCDGXvI1ImLti/j3a+wPina0rSUwCfRWaN
    o+RK05RI8K0KiPrdS2idqHE=
    =NtU6
    -----END PGP SIGNATURE-----


  3. Re: [PATCH] Re: gmtime_r

    On Thu, May 12, 2005 at 06:16:08PM -0700, Phil Dibowitz wrote:
    > On Thu, May 12, 2005 at 03:35:12PM -0700, Phil Dibowitz wrote:
    > > Hey folks,
    > >
    > > I'm compiling 5-1.4.1 on Solaris 9 and I get:

    >
    > I was able to fix this:


    BTW, I realizes this is a hack... but I havn't figured out how to fix
    this in configure.in, so I just did that in the meantime... I figured I'd pass
    this on as it at least tells you what the problem is.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFChAMP7lkZ1Iyv898RArGKAJ48LaP0aSS4A2YGxGvtWW d3q16gxACfbKfT
    kaJPIxrp1gKn/C83JhYWhno=
    =iHBk
    -----END PGP SIGNATURE-----


  4. Re: gmtime_r

    On May 12, 2005, at 18:35, Phil Dibowitz wrote:
    > Hey folks,
    >
    > I'm compiling 5-1.4.1 on Solaris 9 and I get:
    >
    > WARNING: Some functions that are needed for library thread
    > WARNING: safety appear to be missing.
    > WARNING: missing thread-safe function: gmtime_r
    > WARNING: Without these functions, the installed libraries
    > WARNING: may not be thread-safe.
    >
    > This is _really_ strange since:
    >
    > 1. gmtime_r() is part of time.h
    > 2. This didn't happen on 1.3.3, I just went back and checked.


    > The config.log doesn't give any sort of useful information on how it
    > arrived
    > at this decision, it just says:
    >
    > configure:8373: checking for gmtime_r
    > configure:8435: result: no


    If that's all it shows, that probably means that on this invocation of
    configure, it picked up a setting of ac_cv_func_gmtime_r from
    config.cache, and thus didn't attempt to find it again.

    It gets a bit more complicated:

    The top-level configure script uses AC_CHECK_FUNCS, which uses its own
    declaration of the function it's testing (and in fact goes out of its
    way to *hide* any declaration in the few system headers it uses, in
    case they conflict), so it's testing for the availability of a symbol
    by that name in the current set of libraries, not for a header-file
    declaration or macro.

    However... gmtime_r on different systems has different return types.
    On some systems it returns a pointer, and on some it returns an int.
    If we're going to use it, we need to figure out the type it returns.
    There's some code in include/configure(.in) that tries compiling a
    couple of different declarations of gmtime_r, while including time.h.
    If exactly one of them compiles, then we know which type it returns;
    otherwise, I have it setting ac_cv_func_gmtime_r to "no", and we
    pretend the function isn't there. So that may be how the "no" setting
    wound up in the cache. (I just ran a test on my Solaris system, using
    gcc as the compiler, and both versions compiled without complaint.
    That means the test failed to determine the return type.)

    I admit, the wording of the messages could better handle this case...
    and it would probably be good to do the return-type tests before
    printing out the messages from the top-level configure script, and
    maybe even do all the testing in one place instead of two...

    As for the reason it's failing to determine the return type, it looks
    like gmtime_r is only declared if _REENTRANT is defined. With our
    current configuration framework, causing that to be defined would be
    easy; causing it to happen without forcing the pthread library to be
    linked into every Kerberos program may be hard. But as a workaround,
    you could try (in a fresh tree):

    configure --prefix=... CPPFLAGS=-D_REENTRANT

    and I think that'll probably fix the gmtime_r return type problem.

    > I'm not keen on my KDC crashing due to lack of thread saftey.


    The KDC itself -- in fact, all of the programs we ship -- is
    single-threaded. The thread safety issues are for programs like web
    browsers or ldap or imap servers that might be linked against the
    Kerberos and GSSAPI libraries.

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: gmtime_r

    On Thu, May 12, 2005 at 10:08:32PM -0400, Ken Raeburn wrote:
    > As for the reason it's failing to determine the return type, it looks
    > like gmtime_r is only declared if _REENTRANT is defined. With our
    > current configuration framework, causing that to be defined would be
    > easy; causing it to happen without forcing the pthread library to be
    > linked into every Kerberos program may be hard. But as a workaround,
    > you could try (in a fresh tree):
    >
    > configure --prefix=... CPPFLAGS=-D_REENTRANT


    It's not too hard to determine if gmtime_r needs -D_REENTRANT and then
    define GMTIME_R_NEEDS__REENTRANT and then:
    #ifdef GMTIME_R_NEEDS__REENTRANT
    #define _REENTRANT
    #endif
    where needed in .c files.

    We've done something similar in KDE's configure.ac for HP-UX which
    needs _REENTRANT for some functions.

    --
    albert chin (china@thewrittenword.com)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: gmtime_r

    On Thu, May 12, 2005 at 10:08:32PM -0400, Ken Raeburn wrote:
    > On May 12, 2005, at 18:35, Phil Dibowitz wrote:
    > >Hey folks,
    > >
    > >I'm compiling 5-1.4.1 on Solaris 9 and I get:
    > >
    > > WARNING: Some functions that are needed for library thread
    > > WARNING: safety appear to be missing.
    > > WARNING: missing thread-safe function: gmtime_r
    > > WARNING: Without these functions, the installed libraries
    > > WARNING: may not be thread-safe.
    > >
    > >This is _really_ strange since:
    > >
    > >1. gmtime_r() is part of time.h
    > >2. This didn't happen on 1.3.3, I just went back and checked.

    >
    > >The config.log doesn't give any sort of useful information on how it
    > >arrived
    > >at this decision, it just says:
    > >
    > > configure:8373: checking for gmtime_r
    > > configure:8435: result: no

    >
    > If that's all it shows, that probably means that on this invocation of
    > configure, it picked up a setting of ac_cv_func_gmtime_r from
    > config.cache, and thus didn't attempt to find it again.




    OK, I followed, erm, most of that. I think.

    So, um, with my patch I get this:

    $ grep gmtime configure.output.log
    checking for gmtime_r... yes
    checking for gmtime_r... (cached) yes
    checking whether gmtime_r returns int... unknown -- ignoring gmtime_r
    $

    But, I no longer get the warning. It's completely unclear to me if I'm
    threadsafe in this circumstance, and in fact it seems like I _should_ get the
    warning in this case - can you explain why I don't?

    Also note that I'm not using gcc, I'm using the Forte SparCompilers from Sun -
    version 7.

    Anyway, reversing the patch and trying your CPPFLAGS idea, I solve that
    problem:

    $ grep gmtime_r configure.output.log
    checking for gmtime_r... yes
    checking for gmtime_r... (cached) yes
    checking whether gmtime_r returns int... no

    But I also get a lot of this type stuff:

    configure: WARNING: sys/ptyvar.h: present but cannot be compiled
    configure: WARNING: sys/ptyvar.h: check for missing prerequisite headers?
    configure: WARNING: sys/ptyvar.h: proceeding with the preprocessor's result
    ...
    configure: WARNING: regexp.h: present but cannot be compiled
    configure: WARNING: regexp.h: check for missing prerequisite headers?
    configure: WARNING: regexp.h: proceeding with the preprocessor's result

    which I assume could be fixed with a CFLAGS=-D_REENTRANT, but that seems to be
    if that's the case then none of this stuff was being "found" before (or rather
    it was found but didn't work right without -D_REENTERANT so autoconf treated
    it as if it wasn't there.

    So is the best bet to configure with CFLAGS and CPPFLAGS? Or to use a patch
    such as the one I made (of which I still don't understand the output from),
    or... ?

    Thanks.
    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFChEZm7lkZ1Iyv898RAiQ7AJ9K5cOn38X+eepDDUdK9Y EMw3XbkwCgjL8G
    GcirhjCpLWYertqRT96fsvQ=
    =bnp2
    -----END PGP SIGNATURE-----


  7. Re: gmtime_r

    On May 13, 2005, at 02:17, Phil Dibowitz wrote:
    > So, um, with my patch I get this:
    >
    > $ grep gmtime configure.output.log
    > checking for gmtime_r... yes
    > checking for gmtime_r... (cached) yes
    > checking whether gmtime_r returns int... unknown -- ignoring gmtime_r
    > $
    >
    > But, I no longer get the warning. It's completely unclear to me if I'm
    > threadsafe in this circumstance, and in fact it seems like I _should_
    > get the
    > warning in this case - can you explain why I don't?


    We've got multiple configure scripts. The top-level one prints the
    warnings you were referring to originally, and then it runs the
    configure scripts in subdirectories. The one in the include directory
    has the check for the return type, and alters the setting of the
    variable in the cache that says whether gmtime_r is available. So, if
    you were to re-run configure from the top level in that tree, with the
    config.cache file present, it should give you the warning the next
    time, because it picks up the override value from the cache instead of
    running the test again. Kind of screwy, huh? :-(

    I'm working on some changes right now to try to clean that up a bit,
    but they probably won't get into any 1.4.x releases we might yet do.

    > Also note that I'm not using gcc, I'm using the Forte SparCompilers
    > from Sun -
    > version 7.
    >
    > Anyway, reversing the patch and trying your CPPFLAGS idea, I solve that
    > problem:
    >
    > $ grep gmtime_r configure.output.log
    > checking for gmtime_r... yes
    > checking for gmtime_r... (cached) yes
    > checking whether gmtime_r returns int... no


    That's good news...

    > But I also get a lot of this type stuff:
    >
    > configure: WARNING: sys/ptyvar.h: present but cannot be compiled
    > configure: WARNING: sys/ptyvar.h: check for missing prerequisite
    > headers?
    > configure: WARNING: sys/ptyvar.h: proceeding with the preprocessor's
    > result
    > ...
    > configure: WARNING: regexp.h: present but cannot be compiled
    > configure: WARNING: regexp.h: check for missing prerequisite headers?
    > configure: WARNING: regexp.h: proceeding with the preprocessor's
    > result


    Those come up sometimes ... I think it's usually when we test for one
    header file being present, but it requires that another one be included
    first, which the usual autoconf tests don't do. I haven't been
    worrying about it myself...

    > So is the best bet to configure with CFLAGS and CPPFLAGS? Or to use a
    > patch
    > such as the one I made (of which I still don't understand the output
    > from),
    > or... ?


    For the long term, it's good to fix up the configure scripts, but
    setting CFLAGS or CPPFLAGS should be good enough for the short term.

    Ken

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: gmtime_r

    On Fri, May 13, 2005 at 03:50:49AM -0400, Ken Raeburn wrote:
    > >But I also get a lot of this type stuff:
    > >
    > > configure: WARNING: sys/ptyvar.h: present but cannot be compiled
    > > configure: WARNING: sys/ptyvar.h: check for missing prerequisite
    > >headers?
    > > configure: WARNING: sys/ptyvar.h: proceeding with the preprocessor's
    > >result
    > > ...
    > > configure: WARNING: regexp.h: present but cannot be compiled
    > > configure: WARNING: regexp.h: check for missing prerequisite headers?
    > > configure: WARNING: regexp.h: proceeding with the preprocessor's
    > >result

    >
    > Those come up sometimes ... I think it's usually when we test for one
    > header file being present, but it requires that another one be included
    > first, which the usual autoconf tests don't do. I haven't been
    > worrying about it myself...


    Well, sort of. What's actually happening is that the cc -E runs fine because
    it has the -D_REENTERANT flag, but then the cc doesn't compile because it
    doesn't have that flag.

    I run into the opposite problem a lot when I set CFLAGS but not CPPFLAGS on
    something and it autoconf will spit out "xxxx works but is not present" which
    always cracks me up.

    OK, one more compile with CFLAGS and CPPFLAGS... ok.

    Which leaves me with a few final questions:
    1. Why doesn't this happen with 1.3.x?
    2. Am I really the first person to run into this?

    Thanks for your help.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFChGSE7lkZ1Iyv898RAlFfAKCeb80h58A8MvlAm/G1XYIQPtcXEgCePgAq
    Qk5S3KHUTRuzeCvaoWyPKFo=
    =QcvJ
    -----END PGP SIGNATURE-----


  9. Re: gmtime_r

    On Fri, May 13, 2005 at 01:25:41AM -0700, Phil Dibowitz wrote:
    > On Fri, May 13, 2005 at 03:50:49AM -0400, Ken Raeburn wrote:
    > > >But I also get a lot of this type stuff:
    > > >
    > > > configure: WARNING: sys/ptyvar.h: present but cannot be compiled
    > > > configure: WARNING: sys/ptyvar.h: check for missing prerequisite
    > > >headers?
    > > > configure: WARNING: sys/ptyvar.h: proceeding with the preprocessor's
    > > >result
    > > > ...
    > > > configure: WARNING: regexp.h: present but cannot be compiled
    > > > configure: WARNING: regexp.h: check for missing prerequisite headers?
    > > > configure: WARNING: regexp.h: proceeding with the preprocessor's
    > > >result

    > >
    > > Those come up sometimes ... I think it's usually when we test for one
    > > header file being present, but it requires that another one be included
    > > first, which the usual autoconf tests don't do. I haven't been
    > > worrying about it myself...

    >
    > Well, sort of. What's actually happening is that the cc -E runs fine because
    > it has the -D_REENTERANT flag, but then the cc doesn't compile because it
    > doesn't have that flag.


    Hmmm... maybe I'm wrong. Setting CFLAGS still yields these errors... but it's
    not a big deal, ti's using the preprocessors results. Strange, though.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFChGaW7lkZ1Iyv898RAq26AKCGFzUDNvCHxngAO657m6 QNYrFziACfZFyo
    aEEWMYMBf7KrDRrBoYh6T+c=
    =UxZn
    -----END PGP SIGNATURE-----


  10. Re: gmtime_r

    On Fri, May 13, 2005 at 01:25:41AM -0700, Phil Dibowitz wrote:
    > 1. Why doesn't this happen with 1.3.x?


    Ken?

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 174 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCkoXS7lkZ1Iyv898RAh9sAJ9zHlvZEP2MJzOqUmhF1l GReF+wnwCgyiRs
    5Jy+tyPH4dktxFoF1Is9NYE=
    =kfeB
    -----END PGP SIGNATURE-----


+ Reply to Thread