* Please upgrade sysutils/portupgrade prior to this one, or pkgdb(1)
may coredump with a double free() problem from a misuse of the DL
module. In that case, reinstall sysutils/portupgrade manually.
Always put a version suffix to the ruby name (no matter if ruby is the
default version) to avoid mess in future.
[Notes for i386 users]
If you are a ruby developer and still want to stick with ruby 1.6 as
default, please add RUBY_DEFAULT_VER=1.6 to /etc/make.conf.
If you are a ruby developer and want to keep ruby 1.6 as default,
please add RUBY_DEFAULT_VER=1.6 to /etc/make.conf. Otherwise, please
run the following series of commands to migrate to ruby 1.8:
1) Reinstall portupgrade manually (and ruby 1.8 will be installed)
pkg_delete portupgrade-\*
(cd /usr/ports/sysutils/portupgrade; make install clean)
2) Reinstall everything that depends on ruby 1.6 (to use ruby 1.8)
portupgrade -fr lang/ruby16
3) Reinstall ruby 1.8 (because the previous step kills symlinks)
portupgrade -f lang/ruby18
4) Deinstall ruby 1.6 stuff (if you are paranoia)
pkg_deinstall -ri lang/ruby16
The __libc_ia64_register_backing_store_base variable is defined on
Linux (in glibc) to allow processes to obtain the base of the RSE
backing store. On FreeBSD we do not have such a variable. We also
do not yet have a different interface for processes to use. So, for
now, hardcode the base address of the RSE backing store as it is
on FreeBSD. There's little chance this will change in the future,
so it's not that evil.
Approved by: portmgr (kris)
AMD64 ports still need some more testing and tweaking)
By this update, openssl, webrick and xmlrpc modules are now part of
the standard distribution.
Since this version should no longer be called -devel, I am planning on
repo-moving lang/ruby{,-devel} to lang/ruby{16,18}, respectively.
with gcc 3.3 with a -mcpu or -march flag (even -mcpu=pentiumpro, which
is the default CPU cflag that bsd.cpu.mk sets, leads ruby to coredump).
Although currently I'm not sure if gcc 3.3's optimization has a bug or
it is that it just exposed the dl module's hidden bug, disable those
flags to work around the problem for the moment.
disabling parallel build on sparc64. The INSTALLS_DEPENDS thing
probably comes from bsd.port.mk, but I wonder why it is regarded as a
target when it is only used as a boolean variable. I think make(1)
has some problem with parallel build (-jN) on that platform.
I could not really reproduce the error on panther, but a submitter [1]
says the build went fine if he commented the -jN option out as I
suggested.
Submitted by: Anders Andersson <anders@hack.org>,
Joao Pedras <jpedras@webvolution.net> [1],
kris
which now supports FreeBSD/sparc64.
Set ONLY_FOR_ARCHS to i386, alpha and sparc64. Ruby does not support
IA64 yet. It does not even build or install correctly. We need some
clue to the IA64 stack structure and handling of the IA64 register
windows.
- Update to the 1.6.8 final release. (which fixes a couple of
coredumping bugs)
- Update Oni Guruma (alternative BSDL regexp engine) to 20021210.
- Attach a small knob for debugging.
lang/ruby-devel
- Update to 1.8.0 preview 1 + errata patch. (fixes a couple of
coredumping bugs)
- Update Oni Guruma (alternative BSDL regexp engine) to 20021210.
- Fix pkg-plist nits.
lang/ruby16-shim-ruby18
- Update to 1.8.0 preview 1. (sync with 1.6.8 & 1.8.0 preview1)
- Fix pkg-plist nits.
Approved by: lioux (and self)
A Merry Christmas to: all of you
1.7.3.2002.12.11, and lang/ruby-devel to 1.7.3-2002.12.12.
- Fix a few bugs that lead to core dump, one in the ruby interpreter
and another in the syslog module.
Reported by: ume (net/dtcp was a victim)
- Fix an installation problem occasionally seen on bento. (a bug in
Makefile that caused race)
Submitted by: bento
- Fix a problem that irb(1) didn't work because the symlink was wrong.
Submitted by: Jos Backus <jos@catnook.com>
- Get rid of move & symlink spaghetti completely from the installation
process.
Discussed with: portmgr (will)
archiver/ruby-zlib with lang/ruby-devel in the correct way.
The cause of this problem is that FreeBSD's make(1) got a bit too
sensitive about a mixture of `target:' and `target::'.
