On 2013/05/08 11:04, Lars Engblom wrote:
> How are other distros/OS doing? Do we really need to bootstrap each
> time? Could not the old working binary be saved to some kind of
> semiofficial porttools.tgz used on the computer for building all the
> ports?
This is what we do at present, the port uses binaries saved in a
bootstrap tgz in the build. Same for some others e.g. gnats,
freepascal, jdk.
Moving time_t, tv_sec and ino_t to 64-bit is a flag day change -
everything will need to be updated - there will not be an old working
binary. All bootstraps need to be rebuilt.
In some cases this can be done via a temporary kernel which wraps
enough of the old system calls to work for *some* software, but this
is only done to get across the bump. It doesn't work for everything
requiring a bootstrap, and other changes are needed for software
which access system calls directly by number (e.g. freepascal, go)
or software which has a hardcoded definition of struct timeval,
struct stat, etc.
For reference this is what I'm currently aware of that has problems
devel/jdk/1.6 bootstrap
lang/fpc bootstrap + other changes
lang/go asm
lang/sbcl hangs during build on i386, amd64 seems ok
misc/findutils current alpha works, but not releases
multimedia/mediatomb call of overloaded 'quote(time_t)' is ambiguous
net/socat HAVE_BASIC_TIME_T is out of range (probably also
HAVE_TYPEOF_ST_INO)
net/spectrum call of overloaded 'addAttribute(const char [6], long
long int)' is ambiguous
productivity/taskjuggler has sanity tests during build which fail (wrong times)
x11/blackbox no matching function for call to 'max(long int, long
long int)'
x11/nx/opennx no matching function for call to
'wxConfigBase::Read(const wchar_t [18], time_t*, int)'
call of overloaded 'Write(const wchar_t [18], time_t&)'
is ambiguous
