Re: __fpclassifyd problem

From: Peter Wemm (peter_at_wemm.org)
Date: 10/23/03

  • Next message: Bruce Evans: "Re: warnings while kernel build" 
    To: deischen@freebsd.org
Date: Wed, 22 Oct 2003 21:15:44 -0700

    Daniel Eischen wrote:
    > On Mon, 20 Oct 2003, M. Warner Losh wrote:
    >
    > > In message: <3F92FC99.8010802@freebsd.org>
    > > Scott Long <scottl@freebsd.org> writes:
    > > : We need to resolve this before 5.2 in some fashion. It looks like the
    > > : easiest thing to do is bump libm. Is this advisable?
    > >
    > > The problem with bumping libm is that we also need, strictly speaking,
    > > to bump all libarires that depend on libm, and that can be very ugly.
    > > This moves the bump the major version from the trivial fix class to
    > > something that we have to think real hard about. In general one
    > > cannot bump the major version of 'base' libaries like this w/o careful
    > > thought and planning. While we've done that in the past with libc, I
    > > think we were wrong to do so in some classes of symbol tampering.
    > >
    > > Warner _______________________________________________
    > > freebsd-current@freebsd.org mailing list
    > > http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
    > > send any mail to "freebsd-current-unsubscribe@freebsd.org"
    > >
    >
    > If it's just __fpclassifyd(), can you just add a compatability
    > hack to libm so it works with both libc 4.0 and 5.x? You
    > can make __fpclassifyd a weak definition to the hack in libm.
    > I suppose you could also add __fpclassfyd() to libc 4.0.

    We tried this at usenix, but it still didn't work. Obviously there is more
    going on.

    Before anybody goes and bumps libraries etc, it would be useful to know if
    running a statically linked jvm will work on -current. If that does, then
    the next thing to try is using a complete exclusive set of 4.x libraries
    and ld-elf.so.1 somewhere and running in a chroot environment. The next
    step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and
    find the 4.x libraries in preference to the 5.x ones. And so on. If it
    still works at this point, then try switching the unbumped libraries one
    at a time until it breaks.

    Bumping the library versions is only useful IF it actually solves the
    problem.

    Cheers,
    -Peter 

    --
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Bruce Evans: "Re: warnings while kernel build"

    Relevant Pages

    • Re: HEADS UP: shared library bump, symbol versioning, libthr change
      ... > shared libraries themselves, so as long as libc sybols used by the ... > shared libraries will happily work with both. ... > they will start resolving to FBSD_1.0 symbols, but your bump will ... I certainly wouldn't mind you committing everything _but_ version bumping. ...
      (freebsd-current)
    • Re: libpthread shared library version number
      ... the line of what we have for other system libraries. ... We certainly should be bumping them ... would have to bump them again before a release, ... we should enable symbol versioning at ...
      (freebsd-current)
    • Re: HEADS UP: compat6x
      ... use -stable apps by doing the library bump at first breakage. ... why not just enable symbol versioning in current by default now ... change the way dependencies are recorded in shared libraries, ... only have to rebuild things once. ...
      (freebsd-current)
    • Re: libpthread shared library version number
      ... the line of what we have for other system libraries. ... We certainly should be bumping them ... would have to bump them again before a release, ... we should enable symbol versioning at ...
      (freebsd-current)