(I believe I got this right, but since this PLIST is actually
processed in scripts/conifgure, I am not 100% sure that I have traced
its entire path. If the maintainer can check, it will be greatly
appreciated.)
FWIW, checkout of these things took 5+hrs, staying on the local
.freebsd.org net w/o hitting the 'net at all.
As promised,
$ time cvs ci
real 67m51.701s
user 0m1.250s
sys 0m5.345s
all the way to diffing yorick/pkg/PLIST and then died with a
"bad hostname freefall.freebsd.org" .... Hopefully that's not bad... ;-)
Hmm.. Maybe I'll try doing this from beast, next! kickme's a boring
machine, and bento is busy.
segmentation violations and assertion failures occur. Support
several system calls not supported previously.
PR: This is part of the fix for ports/3572.
not thread safe at all. This commit repairs the damage.
This changes the minor version numbers of the Modula-3 shared
libraries. The packages that depend on modula-3-lib will need to
be rebuilt:
net/cvsup
print/virtualpaper
This eliminates the malloc warnings brought about by the recent
merging of calloc into malloc.c in -current's libc.
This changes the minor version numbers of the Modula-3 shared
libraries. The packages that depend on modula-3-lib will need to
be rebuilt:
net/cvsup
print/virtualpaper
names, e.g., "m3build-4" and "m3build-4.0". This makes it possible for
ports that depend on this one to require a specific version. Since the
shared libraries have been moved into a separate port, their version
numbers can no longer be used for that purpose.
the new "modula-3-lib" port. The split allows one to save a lot of
disk space by installing only the shared libraries needed for executing
programs. The full "modula-3" port is needed only if you want to
compile programs as well.
sure that they are executable. On at least one user's system, the
copies taken from /usr/src/contrib did not have their execute bits
set.
Suggested by: max@wide.ad.jp
Use new custom distfiles which are MUCH smaller than the ones from
DEC.
Use the gcc-2.7.2.1 sources on the system if they are found in
/usr/src/contrib, to avoid having to fetch that distfile.
Use an existing Modula-3 compiler to bootstrap the new one, if
there happens to be one installed on the system. Again, this
eliminates the need to fetch one of the distfiles.
Update the built-in thread-safe malloc to the latest version of
phkmalloc.
Use new custom distfiles which are MUCH smaller than the ones from
DEC.
Use the gcc-2.7.2.1 sources on the system if they are found in
/usr/src/contrib, to avoid having to fetch that distfile.
Use an existing Modula-3 compiler to bootstrap the new one, if
there happens to be one installed on the system. Again, this
eliminates the need to fetch one of the distfiles.
Update the built-in thread-safe malloc to the latest version of
phkmalloc.
Helmet on!
Flameproof vest?
Deployed, Sir!
Heat resistant carbon-fiber cup?
In place!
All defensive systems armed and ready?
Armed and ready, Sir!
Fine, then. Let's get on with it. Reduce shared library version numbers!
Uh, Sir, with all due respect ...
DO YOU HEAR ME??? REDUCE SHARED LIBRARY VERSION NUMBERS!!!
Reducing shared library version numbers! ... <*whirr click*> Done!
All right, soldier, let's get the hell out of here... Soldier? ... Soldier??
First, change the port so that it builds a much smaller subset of
the SRC distribution. This eliminates the enormous swap space
requirements of the earlier port, greatly reduces the footprint of
the installed tree, and cuts the size of the package in half.
Second, include many important new patches. Among them is a slightly
modified version of phkmalloc that is thread-safe for Modula-3.
It eradicates some rare and baffling core dumps that cropped up
from time to time in the previous version of the port. The Modula-3
runtime itself is careful to use mutual exclusion around calls to
malloc. But there remained some sneaky backdoor paths into it from
external libraries.
Confession: In the original version of the Modula-3 port, I used
a major version number of 353 for the shared libraries, to correspond
with the SRC version number 3.5.3. That was a dumb move -- I should
have used 1. The current update is incompatible at the shared
library level, requiring me to increment the major version number
to 354, even though this is still based on SRC release 3.5.3. This
is bound to confuse some folks, unfortunately. I weighed a number
of alternatives, such as (a) cheating and going back to 1, and (b)
using a 4-digit major version such as 3531. But in the end I
decided that 354 would be the best solution, even though it's
confusing.
