will be used to support SOCKS operation in the soon-to-be-released next
version of CVSup.
A tip of the hat to: Darryl Okahata, who developed the patches
necessary to make the SOCKS library work with Modula-3's multithreaded
I/O system.
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.
"modula-3-lib". It installs only the shared libraries needed for
executing Modula-3 programs. This saves a lot of disk space for
people who need to run Modula-3 programs but don't need to build
them. The original "modula-3" port now depends on this one, and
uses it to install the compiler and the rest of the development
system.
Also, everything is now built with optimization. I have been
testing this for at least a month, and haven't seen any problems
from it. It makes the libraries and executables substantially
smaller.
This new port also includes some hooks that will make SOCKS support
possible in the near future.
(The license agreement is similar to GPL and, thus, there should be
no problem with redistributing the original archive as long as we put no
restriction.)
all the COMMENTs! No package names, no version numbers, no "this is
absolutix-3.1.2" type comments that have zero information contents.
Now, without any bad examples to follow, nobody has an excuse to import
a port with those kind of comments. :)
Phew! 238 ports modified!
Closes PR ports/1728.
(But I don't know how to actually change the state of PR.
Could someone do this for me? Or tell me how?)
Submitted by: shanee@rabbit.augusta.de
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.
-n to, really happened. That's kind of weird. Anyways, I
forgot to add the patches directory and a new patch.
Oh, I specified -n now too, hope this doesn't work.
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.
From: wjm@best.com (William J. Middleton)
Newsgroups: comp.lang.perl.announce,comp.lang.perl.misc
Subject: PATCH: perltrap.pod <- 425traps
Date: 1 Jul 1996 14:49:58 GMT
Approved: merlyn@stonehenge.com (comp.lang.perl.announce)
Message-ID: <4r8oim$e5q@nadine.teleport.com>
NNTP-Posting-Host: julie.teleport.com
[The rush to 5.003 couldn't integrate this, so here it is]
The following is a patch for perltrap.pod, from 5.003 (also 5.002).
It integrates the latest version of my simple 425traps
document. 425traps demonstrated, with examples, all of the traps
which have been discovered and sent to me, which have bitten
folks making the transition from perl4 to perl5. It also gave
an example for each one, including all of the existing perl4
traps in perltrap.pod.
As always, if you discover something that isn't documented in
one form or another in here, and isn't an official (or at least
reported) bug, drop me a line with it. Also, when or if any
of these is ever formally declared a bug, I'll take it out.
tcl/tk even if they are properly found by LIB_DEPENDS. Make it
only extract in that case.
While I'm here, make expect and expectk link with shared tcl/tk libs.
expectk used to be a 1/2 MB binary! (now it's 136KB)
I'd also rather change `-g' to whatever CFLAGS defined in
/etc/make.conf, but the author of expect has an explicit comment in
the Makefile about him not trusting compilers' optimization. Well,
if you say so.
master site for elk.
- Add official patch #1.
- Use dl*() for dynamic loading. This still has its quirks, but
it's usable. Plus, invoking global ctors when loading C++
object files now works; it didn't with the old incremental
loading.
before) and cvs still sent an empty log! :<
Anyway, what I was trying to say in the commit messages of patch-[ab] was
to run ldconfig right after installation of the shared libraries, so that
they can be found by subsequent runs of shared binaries.
Also, take ldconfig out of this Makefile's post-install rule.
post-install:
pkg_add -m ${PREFIX}/lib
to Makefiles and
@exec ldconfig -m %D
to packing lists of ports that install shared libraries.
This should get rid of a huge chunk of confusion for novice users!
All hail Paul Kranenburg! :)
=====
# Id line
#
# RESTRICTED: restricted_port_1 (comment1)
# RESTRICTED: restricted_port_2 (comment2)
#
# BROKEN: broken_port_3 (comment3)
# BROKEN: broken_port_4 (comment4)
# BROKEN: broken_port_5 (comment5)
#
SUBDIR= good_port_1 good_port_2 ...
=====
Basically, the idea is to make it easy to find restricted or broken
ports by doing a "grep".
needed as for the g77 port, except this time since a new compiler
exectuable isn't getting produced (and I wonder why its that way)
one will need to use -B${PREFIX}/libexec/ every time they wish to
compile ada sources, since gcc doesn't look in /usr/local/libexec/.
It seems to work... I ran it on the examples directory. Someone
who knows ada well should test it I suppose.
-josh
got the version number wrong which was because Jordan got the version
number wrong, it had 7.3 instead of 3.1, kind of far off (can anyone say
Tcl?) anyways, I also noticed that it didn't even work to begin with
because there was
a) no install target
b) it ignored ${PREFIX}
so I fixed it up and added myself as MAINTAINER, unless anyone minds,
I didn't do this originally, but I see bh (the implementor) three tines
a week so I can probably deal with problems pretty well.
not found a quick way to do that with a environment variable in
string constant. So this ports works in the moment only with XFree3.x
(X11R6) and not with XFree2.x (X11R5 <-> X386).
there's something a little weird about this port, I had to make a
FreeBSD specific distfile, using two of the official distfiles. I
included a description of what I had done, but it is much easier
(and saves downloading about 3 megs) to use this distfile.
So, how do I get the distfile I've made into the right place without
faking it out by first putting a real site and then changing it
to always use freebsd.cdrom.com? the distfile is in
freefall.cdrom.com:~jmacd/scheme-microcode+dist-7.3-freebsd.tgz
(1) Took out INSTALL_MANPAGES (not necessary anymore, porter should
set NO_INSTALL_MANPAGES for not calling "make install.man")
(2) Replaced most of DEPENDS with EXEC_DEPENDS and LIB_DEPENDS. These
are the entries I used:
EXEC_DEPENDS:
unzip:${PORTSDIR}/archivers/unzip
gmake:${PORTSDIR}/devel/gmake
wishx:${PORTSDIR}/lang/tclX
xli:${PORTSDIR}/graphics/xli
gs:${PORTSDIR}/print/ghostscript
gunshar:${PORTSDIR}/archivers/gshar+gunshar
hfs:${PORTSDIR}/utils/hfs
rman:${PORTSDIR}/utils/rman
LIB_DEPENDS:
tiff\\.3\\.:${PORTSDIR}/graphics/tiff
jpeg\\.5\\.:${PORTSDIR}/graphics/jpeg
Xpm\\.4\\.:${PORTSDIR}/graphics/xpm
tcl\\.7\\.:${PORTSDIR}/lang/tcl
tk\\.3\\.:${PORTSDIR}/x11/tk
xview\\.1\\.:${PORTSDIR}/x11/xview-lib
Xaw3d\\.:${PORTSDIR}/x11/Xaw3d
mpeg\\.1\\.:${PORTSDIR}/graphics/mpeg-lib
xview\\.3\\.:${PORTSDIR}/x11/xview-lib
BLT\\.1\\.:${PORTSDIR}/x11/blt
There are still some dependencies I can't figure out what exactly
is needed. If your port still has DEPENDS in it, please check it out!
themselves are still there, but don't get made from a top level make.
In another couple of days, I will remove the ports as well if people
don't fix them.
