[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HEADS UP: I will be merging christos-time_t by the end of the week
On Jan 4, 9:10pm, erh%nimenees.com@localhost (Eric Haszlakiewicz) wrote:
-- Subject: Re: HEADS UP: I will be merging christos-time_t by the end of the
| On Sun, Jan 04, 2009 at 10:02:23PM -0500, Christos Zoulas wrote:
| > On Jan 5, 2:59am, dholland-current%netbsd.org@localhost (David Holland)
| > -- Subject: Re: HEADS UP: I will be merging christos-time_t by the end of
| > | On Mon, Jan 05, 2009 at 02:57:00AM +0000, Christos Zoulas wrote:
| > | > >What about structures that have inline time_t members? Otherwise
| > | > >this is a serious issue waiting to be hit. Just consider two different
| > | > >libraries, one old, one new, both using stat(2).
| > | >
| > | > All have been versioned. Including rpc, etc.
| > |
| > | Are we going to do a mass revbump in pkgsrc?
| > I think we'll have to. On the positive side, existing packages will work.
| > Compiling new ones will need complete rebuild (dependencies and packages).
| Does this mean that, as pkgsrc currently stands, a package built against
| the new system (w/ 64-bit time_t) will use a package built against an old
| system but fail at runtime? yuck.
| If so, it sounds like it would be nice to have an explicit dependency on
| something like libc, so we don't need to bump every other dependent package.
| (but then we'd need an implied dependency on the old libc if one isn't
| explicitly specified? hmm...)
It will fail at link time.
Main Index |
Thread Index |