Fixes the following:
* 644465 undefined reference to `_usleep'
* 644552 g_timeout_add_seconds(1, ...) may have a latency...
* 644607 correct internal definition of C_()
we set MODPY_BUILDDEP=No, whilst providing PYTHON via CONFIGURE_ENV. this
lead configure to believe there actually was a python present on the system.
which wasn't, so set MODPY_BUILDDEP=Yes and adjust REGRESS_DEPENDS accordingly
ok aja@ landry@
Major update to glib2-2.26.0.
This starts a flood commit of several big updates (gtk+2 and GNOME 2.32).
Please note that there will be some WANTLIB/DEPENDS breakage probably,
this went into several bulks but it's impossible to catch everything.
Any gtk+2/glib2 related build failures, please talk to me or jasper@
The ports tree is expected to be in a unconsistent state for a couple of
days to give us time to fix everything we didn't spot or any runtime
issue with the latest GNOME.
We do this now so that we have packages with all the latest major bumped
libraries at p2k10.
Thanks to landry@ and his zomg!cluster for the bulks and reports.
ok jasper@
GIO Reference Manual:
gio-querymodules creates a giomodule.cache listing the implemented
extension points for each module that has been found. It is used by GIO
at runtime to avoid opening all modules just to find out which extension
points they are implementing.
Glib now enforces threads requirement. As a result, this commit will
break p5-Glib2 (as our perl is not threaded).
Decision was taken after a chat with naddy@ and jasper@ as patching our
current glib2 like hell to cope with newer packages requirements is
clearly not a good solution.
naddy is ok with this move.
This is required by newer GTK. We cannot just update Glib because it now
requires threads which will break p5-Glib2 dependent apps as our perl is
not threaded... solution to this is rthreads or ... <insert solution
here and send it to aja@>. Yes this means we are stuck with this version
for now.
- add missing REGRESS_DEPENDS
*remove previous version before trying to compile this*
Report any failure directly to me please.
tested by landry@ on a sparc64 bulk, thanks!
ok jasper@ on a previous diff