GNU Smalltalk is at version 1.8.5 already, but it _keeps_ calculating
wrong values on FreeBSD (see the "make check" target output).
This happened for the versions 1.8.2-1.8.5 on my machine now.
Unfortunately, I don't have the time to find out what's going on here, I'm
sorry. Maybe someone with more time wants to maintain it.
While I'm here, change maintainer's (mine) email address to @FreeBSD.org,
and install the HTML documentation bundled with the PHP distribution
(conditionalized on NOPORTDOCS, of course).
Within the top-level Makefile of the distribution file, and as part of
the install target, this software decides to send, without warning,
a little "I've been installed" love note to its developers.
The doc/install.txt has the usual blurb about not using addresses
"acquired" in this manner etc.. etc..
It's also not entirely clear, and nor have the developers responded
(curiously, you think'd they'd be in to the email thang), whether
this can be automatically patched around.
Possibly worthy of a full-blown Ports Security Notification, I haven't
heard anything back from Bugtraq.
Submitted by: my laptop having a broken MTA :)
Discussed with: kris (a little tiny amount -- don't blame him, blame me)
Luckly our `ld' knows the name of our dynamic linker and DTRT.
* Remove the DECpaq shared libs from the standard search dir as linking
with them gives unresolved symbols. Thus we'll use the .a's for now.
* Add the symbols __errno_location, __ieee_get_fp_control, and
__ieee_set_fp_control (mapped to native interfaces) to the static
Compaq Portable Math Library. Thus all symbols are resolved.
This allows `CC=ccc' to build fully native FreeBSD Alpha binaries.
available on the Compaq Tru64 UNIX platform. The compiler produces excellent
optimized code for the Alpha architecture, particularly for floating-point
intensive applications.
I was able to compile simple test programs by:
ccc -c foo.c
cc -o foo foo.o
e<program_name> conflicts with the egcs port. I'm open to a better nameing
scheme.
Also change the shared libs configuring logic a little bit due to changed
way of doing it on libstdc++-v3, which this snapshot uses by default.
The gcc-2.95.2 bits have been repo copied to ports/lang/gcc295.
GCC 2.95.2 does not work for some people's code. GCC 3.0 will be even
worse. So it looks like we'll have to keep a port for each version of
GCC we've ever used.
