- Change LOCALBASE with _RUBY_BASE
- Set _RUBY_BASE=PREFIX if defined _RUBY_PORT_TEST
_RUBY_BASE=LOCALBASE otherwise for easy ports testing.
lang/ruby18:
- Update to 1.8.3
Grant maintainership to submitter.
While I'm here:
- Add _RUBY_PORT_TEST=yes to lang/ruby16 port too.
(lang/ruby1[68] must set it for right install).
PR: ports/87332
Submitted by: Alexander Novitsky
${PTHREAD_CFLAGS} and ${PTHREAD_LIBS} include in the build to kill the
headache of old '_r' and can't run with something like ruby-opengl, ruby-sdl,
ruby-gtk2 and etc on FreeBSD 4.x or older 5.x. With this commit should solve
those issues. It is recommend you to rebuild any apps that depend on
lang/ruby18, so see the UPDATING for detail.
Remove the 'BROKEN' on the other ports that knu has added them few weeks ago.
Some of them have been tested, so if one of them is still broke then please
let us know and one of us will re-add the 'BROKEN'.
This changes was worked by lofi and me. lofi did everything on FreeBSD 4.x
and I did others. lofi, thanks for help!
Tested by: many people
Tested on: i386 (FreeBSD 4.x, 5.x and 6.x), amd64 (FreeBSD 5.x and 6.x),
and sparc64 (FreeBSD 5.x and 6.x)
Not test on: ia64 and alpha
Approved by: portmgr (kris)
dropped and the lang/ruby16_r and lang/ruby18_r ports have been
removed, since no one seems to appreciate the partially working
solution.
Good news is that the pthread support of lang/ruby18 is now enabled by
default for newer systems, which means the ruby interpreter is linked
with libpthread. This will allow threaded extension libraries to run
and work properly on those systems.
The --march=cputype flag is disabled because it gets ruby to
malfunction and fail to build. I don't know if the problem is in
libpthread or in gcc.
(It really makes me wonder if they had actually tested before asking
me to do this somewhat risky change ;-)
* 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.
