Re: HEADS-UP: Planning on deprecating libc_r for 6.0

From: Scott Long (scottl_at_samsco.org)
Date: 04/13/05

  • Next message: Scott Long: "Re: HEADS-UP: Planning on deprecating libc_r for 6.0" 
    Date: Wed, 13 Apr 2005 10:39:36 -0600
To: Giorgos Keramidas <keramida@freebsd.org>

    Giorgos Keramidas wrote:
    > On 2005-04-13 08:43, Scott Long <scottl@samsco.org> wrote:
    >
    >>Poul-Henning Kamp wrote:
    >>
    >>>>How about modifying the dynamic linker to print a warning to stderr,
    >>>>much like mktemp(3), but let the user disable it by setting an
    >>>>environment variable, like LD_WARN_LIBC_R_DISABLE or similar?
    >>>
    >>>The user can disable it by adding a line in libmap.conf so let us not
    >>>invent more handles to tweak but point the user at the right one.
    >>
    >>Well, the worry is that there are legacy apps out there that rely on
    >>features/bugs only found in libc_r, therefore the user can't just
    >>switch.
    >
    >
    > Exactly the reason why I like the idea of deprecation messages but also like
    > being able to disable them. It's not really impossible or unthought of that
    > it may take a stupidly long amount of time for a vendor to fix their broken
    > application that depends on a bug of a deprecated library *and* misbehaves
    > because of a message sent to stderr by the linker.
    >
    > Having said that, since this is being deprecated in 6.X, which is pretty much
    > "current" and people aren't really expected to jump on the FreeBSD-current
    > wagon if they use FreeBSD for production, how many people use libc_r now that
    > may be bitten by the deprecation messages?
    >

    Well, 6-CURRENT will turn to 6-STABLE in just a few months. It's not
    years in the future =-)

    Scott
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Scott Long: "Re: HEADS-UP: Planning on deprecating libc_r for 6.0"