IABSD.fr/ports/math/octave

Branch :


Log

Author Commit Date CI Message
0c3a6f03 2025-08-26 16:08:31 sync WANTLIB for ngtcp2_crypto_libressl
07b4925a 2025-08-08 10:40:03 bump; header-only library rapidjson updated
55a6c077 2025-07-12 12:37:38 octave: apply usual fix for build with opaque __sFILE: Patch gnulib/fseeko.c. gnulib is doing this to make fflush() behaivour to match what they expect. It accesses internal of __sFILE to change behavior of fseeko(), but we are hiding internal of __sFILE and our fseeko() is compatible with what gnulib expects already. Then the patch is to just use our fseeko().
9ac228b0 2025-05-18 18:41:21 math/octave: Update to 10.1.0 ok steven@
5a9600c7 2025-01-10 18:03:43 Mark ports using lang/gcc/8,-f95 on arm64 as not BTI compliant To be reconsidered when we move to lang/gcc/11 or newer, which supports -mbranch-protection. The fix isn't complete since some ports may use BTI-incompatible fortran code through shared libraries. ok tb@ phessler@ pascal@ sthen@
de0a05be 2025-01-08 16:43:37 update to 9.3.0 ok volker@
e9407b84 2024-12-09 18:58:50 math/octave: Update to 9.2.0 While here, also rename GNU_ARCH to GNU_HOST and remove reference to OSREV. ok steven@
3a43d602 2024-09-15 18:15:17 Poison the threads.h header by default in gnu.port.mk This will avoid threads.h from devel/libstdthreads being picked up by gnulib's threadlib.m4, potentially breaking due to dpb junking in bulk builds. The header is included and some weak symbol magic is performed, but it doesn't bring any useful feature as it doesn't even link against libstdthreads.so. That gnulib module already falls back to a pthreads-based implementation anyway. Ultimately it probably makes sense for C11 threads support to go into the base system, as already discussed several times by matthieu@ and others. But now isn't the right time as we're approaching release. ok ajacoutot@ sthen@
6ba90eaf 2024-09-04 07:30:39 Picks up devel/libstdthreads (BDEP).
6d35ad9f 2024-08-07 20:52:03 bump for plist changes 7.5 -> 7.6