Re: HEADS UP: I will be merging christos-time_t by the end of the week

[christos%zoulas.com@localhost (Christos Zoulas)]

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) 
wrote:
| > -- Subject: Re: HEADS UP: I will be merging christos-time_t by the end of 
the
| > 
| > | 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.

christos