Since the new bootstrapper has a new name (ghc-6.12.2.20100530),
the ABI of some libraries included in GHC will change, possibly
breaking all other libraries, so expect some additional bumps soon.
Yes, this *is* ridiculous. If you want to live in peace, don't use
GHC.
paraemters to ghc-pkg. Remove the (now obsolete) patch for Register.hs.
Ports that build ghc libraries should now use the following
@exec/@unexec magic (('ve already diffs for all the hs-* ports in
my tree):
lib/${DISTNAME}/register.sh
@exec /usr/bin/env HOME=/nonexistent %D/lib/${DISTNAME}/register.sh -v0
@unexec /usr/bin/env HOME=/nonexistent %D/lib/${DISTNAME}/unregister.sh -v0 --force
lib/${DISTNAME}/unregister.sh
for unregister.sh in all the new ghc libraries (which leads to bogus
registered ghc packages after updates).
You can use the command
ghc-pkg check
to check ghcs internal package list. If it reports missing files
for some package (like hashed-storage-0.4.11), you can forcibly
unregister it by running (as root) something like
ghc-pkg unregister hashed-storage-0.4.11
ok dcoppa@
- obstack.h uses casts as lvalues, fix those
- hack standard includes to avoid tons of strlen/malloc warnings (may
even fix bootstrap on other things than i386)
- remove non-standard assert.h that requires an eprintf in libgcc.
- bump pkgname, just in case...
verified to work with both gcc3 and gcc4.
just setting MODGHC_SETUP_CONF_ARGS (which is now empty by default).
Add dblatex-created documentation.
While here, use our INSTALL* macros where possible to get correct
permissions (noticed by dcoppa@). This does *not* fix the permissions
of libraries and interface files installed by Cabal-based tools,
because the permissions are hard-coded in Cabal, and I'm not going
to touch and fix Cabal ever, because IMHO it's completely broken
by design. (If you want to read some of this madness, have a look
at libraries/Cabal/Distribution/Compat/CopyFile.hs or even
libraries/Cabal/Distribution/Simple/Install.hs)
Expect some breakage of depending ports (at least of devel/darcs) and
some necessary WANTLIB changes, which will be fixed soonish.
the APIs of GHCs libraries depend on the version of the bootstrapping
compiler (and probably on the output of pom(6) and the amount of
active vulcanos in iceland).
See http://hackage.haskell.org/trac/ghc/ticket/4012#comment:3 for
details.
THIS ALSO MEANS THAT IF YOUR BUILD FAILS, YOU WILL HAVE TO MAKE
CLEAN AND START FROM SCRATCH! NEVER EVER TRY TO RESTART THE BUILD
OR THE LIBRARY ABIS WILL CHANGE! (Sorry for yelling)
Bump PKGNAME-main, since people may already have built ghc with
native_bootstrap.
Many thanks to Darrin Chandler and dcoppa@ for testing, reporting about
broken stuff, missing dependencies here and in ports depending on ghc.
Notes and rants:
- Bootstrapping is done using precompiled binaries, since .hc
bootstrapping still doesn't work. I really hate this.
THIS MEANS THAT GHC IS NOW AND WILL STAY LEGACY-ONLY (i386 and amd64)
At least until someone fixes it. I tried for more than two year
(well, only in my spare time and during my vacations) and failed.
- libgmp is currently disabled, because I didn't yet hack the GHC build
system to use the system libgmp instead of the patched one included
in GHC.
- The haddock ncluded in the ghc distfile is replaced by the version
of haddock found in devel/haddock. Haddock itself is @commented
in the ghc PLIST. Unfortunately, this needs an ugly hack that
introduces an otherwise useless pseudo flavor `no_deps' in
devel/haddock.
- CLDouble has been removed from GHC some time ago, because it was
an alias for double (AFAIK there's now support for long double
in GHC). As this isn't a really big problem, it currently breaks
c2hs, which I'll mark broken temporarily before committing the
ghc update.
- The external codeset defaults to latin1 (suggested by Simon Marlow)
and can be overridden by setting the HS_ENCODING to any codeset
supported by libiconv.
- ghc.port.mk still needs some love, especially for letting a port add
additional parameters to certain invocations of ${MODGHC_SETUP_PROG}.
get process informations. Remove the mkbundle.cs patch and replace it
with one that uses configure.in so the libgc dependency ends up in the
pkg-config file. Move disabled features to configure.in from our Makefile
Zoltan Varga from the mono team helped me to debug the problem we
were having. So the correct problem description is that on OpenBSD,
ctx can be NULL if we are interrupting poll().
The upstream diff also fixes the issue where we are interrupting
unmanaged code.
it up before having my morning coffee.
So it turns out that sometimes the context on openbsd can be 0. This will
lead to problems. I suspect that this is because of our fantastic pthread
library. With the following diff we just skip doing some JIT stuff if the
context is 0 because the thread probably exited before.
Anyways this way everything *seems* to work fine and almost all regression
tests are passing now except for 2 out of 380.
Pepole understanding pthreads are welcome to look at it and come up with
something that is not a tripe XXX hack.
so work around by tricking it to write into WRKINST through a symlink.
keep this here, so that affected ports need minimal modifications, and we
can work out a better fix long term.
Agreed with wcmaier...
by jasper@'s fixes to the libffi port.
Mark mips64 (aka, sgi) as BROKEN, as the build fails. We'll look closer
at this after unlock.
OK jasper@
ports is unlocked for a while only for those who have been informed.
breaking cd /usr/ports && SUBDIR=some/path make something for
category makefiles. While there, also put spaces around += uniformously.
okay naddy@, jasper@
gcj only needs the internal libffi copy to build and links statically against
it. so there is no point in installing the libffi headers and libraries from
the gcc tree.
discussed with espie@ kurt@ and upstream libffi maintainer
ok espie@ kurt@
While beeing a development release, this is the most stable version I
used on OpenBSD for now. Several patches are removed as they went
upstream. Thanks to jolan@ for pointing me at this release and cooking a
couple of patches.
Fix build on powerpc and add it to ONLY_FOR_ARCHS ; slightly tested on
macppc.
A similar port was successfuly tested by jolan@ on amd64.
no objection alek@ (maintainer)
ok jolan@ ok jasper@
- fix a use after free
- disable tls since we don't support it yet
- BSD endian fix from author Robert Lougher <rob.lougher at gmail.com>
testing and okay MANTAINER Frederick C. Druseikis <fdruseikis at sc.edu>
progress, largely based on the gcc port in ports/lang/gcc/4.2.
Requested by jsg@.
It's somewhat usable on i386 (shared lib versions not yet properly
under control). Build on amd64 currently fails with -fPIC problems.
-- --
lvm-gcc is the LLVM C front end. It is a modified version of gcc
that compiles C/C++/ObjC programs into native objects, LLVM bitcode or
LLVM assembly language, depending upon the options.
By default, llvm-gcc compiles to native objects just like GCC does.
If the -emit-llvm option is given then it will generate LLVM bitcode
files instead. If -S (assembly) is also given, then it will generate
LLVM assembly.
Being derived from the GNU Compiler Collection, llvm-gcc has many of
gcc's features and accepts most of gcc's options. It handles a number
of gcc's extensions to the C programming language.
<sthen@zephyr:/usr/ports/mystuff/lang/llvm-gcc4:9>$CVS: ----------------------------------------------------------------------
all secondary compilers were relocated to separate projects so we need a
rakudo port to get the perl6 binary back.
this update also addresses the recent bulk fallout noticed by naddy@
testing by sthen@ and ajacoutot@, thanks!
ANTLR, ANother Tool for Language Recognition, (formerly PCCTS) is a
language tool that provides a framework for constructing recognizers,
compilers, and translators from grammatical descriptions containing
Java, C#, Python, or C++ actions.
Currently installing the precompiled jar since this is needed for
classpath 0.98 as a BUILD_DEPEND and RUN_DEPEND.
From MAINTAINER: Frederick C. Druseikis <fredd@engr.sc.edu>
people from screwing themselves by using libstdc++-3.x which will fail
only in bizarre ways (embarassing how long it took me to debug this)
ok robert@
"finally! ok" todd@
place to change if you need to use a different Tcl/Tk version.
- provide MODTCL_LIB and MODTK_LIB (avoids a possible messy
construct in an individual port's Makefile when they are needed,
allows use of "LDFLAGS=-L${MODTCL_LIBDIR} -l${MODTCL_LIB}").
ok steven@, Stuart Cassoff
Lots of python ports already do this, so better factorize. It will also
help mitigate some build breakages when several python versions are
installed.
Related ports cleanup coming in a few...
"looks ok" wcmaier@
"makes sense" sthen@
"no objection" djm@
with Chez Scheme but uses high-speed threaded interpreter technology in
place of Chez Scheme's incremental native-code compiler. Petite Chez
Scheme may be used without license, fee or royalty for any purpose,
including for resale as part of a commercial product.
Submitted by (a very patient) Aaron W. Hsu <arcfide at sacrideo dot us>
with license help and sanity checking from sthen@.
a few patches to deal with shared libraries.
there is lisp code to deal with recognizing .so, so until someone dives
in and adapts it for OpenBSD, keep a libecl.so...
work on OpenBSD, and exceptions are hevaily used by OpenOffice.Org.
Backport PR libstdc++/31481 from GCC repository because this fix is needed
by openoffice:
PR libstdc++/31481
* include/ext/type_traits.h (__numeric_traits): Move...
* include/ext/numeric_traits.h: ... here; fix type of
__max_digits10.
* include/ext/pb_ds/detail/type_utils.hpp: Include
<ext/numeric_traits.h> too.
* include/tr1/random: Likewise.
Tested with both openoffice and webkit. bump needed PKGNAMEs;
2.4.4 => 2.4.8
2.5.2 => 2.5.4
2.6 => 2.6.1
Python 2.4 and 2.5 lose their build knobs to match 2.6.
Removes no longer needed Python 2.5 security patches backported
from the release25-maint SVN branch.
Remove the -bz2 subpackage from all three versions. It is silly
to make a subpackage to avoid depending on something tiny and
compatibly licensed.
Python 2.4 and 2.5 lose their -expat subpackages; expat has been
in base for some time.
Python 2.5 loses its sqlite subpackge. Again, sqlite is tiny,
compatibly licensed and is depended upon by more and more
applications. This brings it into line with the 2.6 version.
Rework all three version's handling of setup.py. Rather than regex
replacing LOCALBASE and X11BASE into setup.py post-configure, these
are passed in though environment variables. Will save hours of
frustrated cursing familiar to anyone who has accidently used the
update-patches target after configure and had to go back and redo
all the substitutions.
Rework the patching of setup.py for 2.4 and 2.5 to be more like
what we do for 2.6. I.e. keep the diff minimal and avoid deleting
huge blocks of code, so the diff has a chance of applying without
massive hand-editing each patch release.
Fix .py paths in installed .pyc files (patch from eric@)
feedback from several, particularly eric@, ajacoutot@ and Ingo
Schwarze; "get it in" ajacoutot@
