Date: Thu, 16 Oct 2003 12:47:37 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Garance A Drosihn <drosih@rpi.edu> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: time_t on sparc64 (it seems to work) Message-ID: <20031016123335.L57857@beagle.fokus.fraunhofer.de> In-Reply-To: <p06002006bbb358ebfea2@[128.113.24.47]> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031015045429.Q41837@gamplex.bde.org> <20031015090422.M57857@beagle.fokus.fraunhofer.de> <20031015075111.GA52914@rot13.obsecurity.org> <20031015190951.GA638@ns1.xcllnt.net> <p06002006bbb358ebfea2@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Oct 2003, Garance A Drosihn wrote: GAD>At 12:09 PM -0700 10/15/03, Marcel Moolenaar wrote: GAD>>On Wed, Oct 15, 2003, Garance A Drosihn wrote: GAD>> > GAD>>> I agree it would be better if we had 64-bit time_t's for GAD>>> 5.x-STABLE. I would really really like to see that. However, GAD>>> we are hoping to make 5.x turn into 5.x-stable with a release GAD>>> of 5.2 in December. GAD>> GAD>>In fact, 5-stable happens no sooner than 5.3 in Feb 2004. Make GAD>>the switch before 5.2 and you have enough time to deal with GAD>>ports that suddenly start to break. GAD> GAD>Oh. I thought it was going to be 5.2. Well, I'm still uneasy GAD>about making the change, but I don't object quite as much if GAD>we aren't shooting for -stable in 5.2. Well, I tried to get a first impression on how hard this change would be. I have a ultra-10 to play with. The only thing I did (after a couple of greps in sys/sparc64) was to change __time_t to __int64_t. I then recompiled everything and installed the new kernel. Just for fun I booted the kernel and - hey - it works. It comes even in multiuser mode, albeit without NFS file systems. I then rebooted the old kernel and did a make installworld. I expected this to fail at some place, because it would use the new tools (which expect 64bit time_t from the kernel) on the old kernel. It goes quite far - the stopper is zic which enters an endless loop. I stopped the install and rebooted the new kernel into single user, mounted my NFS file systems (my src and obj are on a server) by hand and tried the make install again. This time it stopped in include, probably because it was now using the old make which couldn't correctly resolve the file times anymore. I installed the new make handish and tried the installworld again. This time it stopped in sendmail, because the old find doesn't work as expected. Installing the new find did the trick. After a mergemaster and a reboot everything seems to be just fine. Of course you need to recompile all ports (unless you know which port won't used stat() or gettimeofday(). So given that things are quite simple I would argue to do the move now, before the sparc port will really be used as -stable in production systems. With a little help from the build infrastructure people it may be possible to ensure that the above will work more automatically. Also the sparc gurus should probably have a look at the MD parts, whether there is something that needs to be changed. So when will we do it? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031016123335.L57857>