Unfortunately, we can't completely remove or skip include/execvpe.h
and cbits/execvpe.c, because they also contain pPrPr_disableITimers(),
which is called from the Haskell code.
- Switch back to GhcThreaded=YES (default). It's stupid, it's not
required by GHC (IIRC it was required a long time ago back when
ghci used libreadline), but it may help finding rthread bugs.
Until now, I did run four complete builds of GHC and all Haskell
ports with dpb without any problems.
routines from Perl6-like code. The key feature of NQP is that it's
designed to be a very small compiler (as compared with, say, perl6
or Rakudo) and is focused on being a high-level way to create
compilers and libraries for virtual machines (such as the Parrot
Virtual Machine). Unlike a full-fledged implementation of Perl 6,
NQP strives to have as small a runtime footprint as it can, while
still providing a Perl 6 object model and regular expression engine
for the virtual machine.
ok landry@
- backporting a fix for the ppc backend from upstream
- telling libgo configure not to try to link to libffi_convenience on ppc
issue brought up and fix tested by ajacoutot@, "go ahead" kettenis@
This is a devel version but 0.16.0 is just around the corner and it will
ease dealing with the big batch of g* updates (glib, gtk, gnome-* ...)
that are due in the upcoming weeks.
itself using the non-threaded rts. This doesn't fix the real problem,
but it makes it possible to build hs-* ports without filling up
dpb's build slots with stuck ghc processes.
ok naddy@ espie@
Note: I'll re-run the testsuite with this diff and hope to get some
reasonable results that may help us to identify the real problem.
function name to __stack_smash_handler. Only supported for "c-family"
languages at the moment.
- enable it per default on archs where FRAME_GROWS_DOWNWARD
- remove obsolete comment about adastrap needing a specific libc
- -java actually needs a runtime dep on -main for -lgcc
ok espie@
fix for CVE-2011-4885 included in PHP 5.3.9
Note that the Suhosin extension (which is enabled by default in our packages)
mitigates against this problem
ok robert@ ajacoutot@
This solves some nasty 5.0 -> current update problems.
Up to 5.0, lots of php-using packages were depending on php-mysql-5.2.
So the dependencies would update to php-mysql-5.2 from current.
BUT the php-using packages are now depending on 5.3 -> internal conflict !
With this change, things work again. After the update, you end up with
php-mysql-5.2 AND php-mysql-5.3, you can then try pkg_delete -a to weed
out "unneeded" php*-5.2
okay sthen@, ajacoutot@
- deal with ldconfig shitz being run at fake install everywhere
- fix sprintf/strcpy usage in libestdc++ so we don't get a warning every time
we compile a C++ program
Everything brought up by espie@.
Stack overflow, only affects a very specific and unusual non-default
configuration: transparent cookie encryption enabled, HTTP response
splitting protection disabled, *and* a PHP application must allow
unfiltered user input to header() in order to be affected.
Good write-up at http://seclists.org/fulldisclosure/2012/Jan/295
ok robert@
CONFIG_SITE even if the FSF says no.
Also, finally get rid of the stage3 build/comparison, since apart from
taking build time, it's not really THAT useful unless you're specifically
debugging gcc.
libc.so from OpenBSD 5.0, and tweaks the ada scripts to LD_LIBRARY_PATH
the bundled library.
That way, we should be able to get away by providing a new bootstrap ways
less often (preferably every release, but things won't break if we do it
even LESS often).
- uncomment a couple of lines in the default php-fpm.conf so you
don't have to make any changes before it will start up
- add missing crypt_blowfish.h header to PLIST-main
ok robert@
matching the requirements of haskell-platform-2011.4.0.0.
Moving the xhtml library back to a separate port (www/hs-xhtml)
would be nice but it causes too much headache (like dependency
cycles with devel/haddock).
(from OpenBSD 5.0-release), thanks ajacoutot@ for hosting the distfile.
- check that the bootstrap egcc can actually run; the reason for failure
due to missing libs is now clear (previously it was a cryptic "C compiler
cannot create executables" type message during configure).
Suspending multithreaded programs built with ghc (including ghc
itself) should just work[tm] now. (Except for the bootstrapping
compiler which of course still uses the old code)
- fix conflict with speech-dispatcher
- fix gen-versions target
- i386 ethread compat
update to R14B04 from dlg@, rest by piotr sikora and me
tested with rabbitmq and ejabberd on amd64; sparc64 is still happy too
maintainer timed-out
Also include the compiler standard libraries under compiler-libs/, as this
is the convention adopted by other packaging (Debian, FreeBSD), and is used
by various utility software such as the Lwt interactive toplevel and some
of the graphical IDEs.
CoffeeScript is a little language that compiles into JavaScript.
Underneath all those awkward braces and semicolons, JavaScript has
always had a gorgeous object model at its heart. CoffeeScript is an
attempt to expose the good parts of JavaScript in a simple way.
The golden rule of CoffeeScript is: "It's just JavaScript". The code
compiles one-to-one into the equivalent JS, and there is no
interpretation at runtime. You can use any existing JavaScript library
seamlessly from CoffeeScript (and vice-versa). The compiled output is
readable and pretty-printed, passes through JavaScript Lint without
warnings, will work in every JavaScript implementation, and tends to run
as fast or faster than the equivalent handwritten JavaScript.
Feedback and OK jasper@
without any modifications to PATH. To run an ruby program that is
installed in jruby's bin directory (which no longer needs to be in the
PATH), use jruby -S program.
I don't know why it doesn't find it, but it looks like the tmp inst
is supposed to get it...
so work around until eventually robert fixes this mess for real...
builtins.c:
Allow MD backend to prevent the optimization of a bcopy() or memmove() of
size 1 (the size being known at compile-time) into an inline mempcpy()
expansion, which will in turn expand into a byte load and store operation.
This expansion loses precious address alignment information at some point
(because everybody knows that you can read a byte from any address, right?),
and this loses bigtime on strict alignment platforms which lack the ability
to accesse bytes directly, such as alpha (unless compiling with -mbwx and
runnning on a BWX-capable cpu).
config/alpha:
Require alignment of local arrays on word boundaries, and enable
the builtins.c `one-byte memcpy' workaround.
ok espie@
is not set, but only for gem, extconf, and setup based ports. Other
ports could be using the lang/ruby module and still have a standard
make-based regression test suite.
