diff options
-rw-r--r-- | README | 7 | ||||
-rw-r--r-- | configure.ac | 16 | ||||
-rw-r--r-- | src/memory.c | 14 |
3 files changed, 21 insertions, 16 deletions
@@ -28,10 +28,11 @@ Others might work as well. Linux, FreeBSD, Windows (MinGW 32/64) ~~and [Haiku](https://www.haiku-os.org/) (gcc4)~~ are tested and supported. +Mac OS X is built during Continuous Integration but is otherwise untested +and packages also cannot be provided. +(I am looking for a Mac OS X maintainer!) SciTECO compiles with both GCC and Clang. -SciTECO should compile just fine on other UNIX-compatible platforms, -like Mac OS X - however I cannot test it regularily and there is currently no -Mac OS X maintainer. +SciTECO should compile just fine on other UNIX-compatible platforms. However UNIX-compatibility is not strictly required: Since SciTECO primarily depends on [glib](https://developer.gnome.org/glib/) and some implementation of Curses, it should be easy to port to even more exotic platforms. diff --git a/configure.ac b/configure.ac index cca1cd3..2d272c0 100644 --- a/configure.ac +++ b/configure.ac @@ -79,17 +79,14 @@ AC_CHECK_TOOL(AR, ar) # Whether $CC is Clang AM_CONDITIONAL(CLANG, [$CC --version | $GREP -i clang >/dev/null]) -# Check for Windows resource compiler and define -# WIN32 conditional +# Platform-specific tools and conditionals case $host in *-mingw*) LT_LANG([Windows Resource]) - AM_CONDITIONAL(WIN32, [true]) - ;; -*) - AM_CONDITIONAL(WIN32, [false]) + HOST_WIN32=yes ;; esac +AM_CONDITIONAL(WIN32, [test x$HOST_WIN32 = xyes]) # Changing the EXEEXT on emscripten ensures that we don't # need a special Makefile rule to generate Javascript files. @@ -314,7 +311,6 @@ gtk) esac AM_CONDITIONAL(INTERFACE_GTK, [test x$INTERFACE = xgtk]) -AM_CONDITIONAL(GTK_FLOW_BOX_FALLBACK, [test x$GTK_FLOW_BOX_FALLBACK = xtrue]) AC_ARG_WITH(teco-integer, AS_HELP_STRING([--with-teco-integer=SIZE], @@ -345,10 +341,10 @@ AC_ARG_ENABLE(malloc-replacement, [Replace the libc malloc() [default=check]]), [malloc_replacement=$enableval], [malloc_replacement=check]) if [[ $malloc_replacement = check ]]; then - # We currently do not support dlmalloc on Windows. + # We currently do not support dlmalloc on Windows and Mac OS. case $host in - *-mingw*) malloc_replacement=no;; - *) malloc_replacement=yes;; + *-*-darwin* | *-mingw*) malloc_replacement=no;; + *) malloc_replacement=yes;; esac fi AM_CONDITIONAL(REPLACE_MALLOC, [test $malloc_replacement = yes]) diff --git a/src/memory.c b/src/memory.c index 302939b..9846753 100644 --- a/src/memory.c +++ b/src/memory.c @@ -273,7 +273,7 @@ * malloc_trim(). * Malloc overriding can be disabled at compile time to aid in memory * debugging. - * On Windows, we never even try to link in dlmalloc. + * On Windows and Mac OS, we never even try to link in dlmalloc. * If disabled, we try to directly measure memory consumption using * OS APIs. * Polling of the RSS takes place in a dedicated thread that is started @@ -434,7 +434,15 @@ teco_memory_get_usage(void) * * FIXME: Benchmark whether polling in a thread really * improves performances as much as on Linux. - * Is this even critical or can we link in dlmalloc? + * FIXME: There is no malloc_trim() natively on Mac OS - can + * we recover from OOMs? + * FIXME: We cannot simply overwrite weak malloc() functions + * like on Linux since this does not affect shared libraries + * unless $DYLD_FORCE_FLAT_NAMESPACE is set. + * It should be possible to change the default malloc zone, though. + * First experiments have been unsuccessful. + * But see https://github.com/gperftools/gperftools/blob/master/src/libc_override_osx.h + * https://chromium.googlesource.com/chromium/src/base/+/refs/heads/main/allocator/allocator_interception_mac.mm */ static gsize teco_memory_get_usage(void) @@ -444,7 +452,7 @@ teco_memory_get_usage(void) if (G_UNLIKELY(task_info(mach_task_self(), MACH_TASK_BASIC_INFO, (task_info_t)&info, &info_count) != KERN_SUCCESS)) - return 0; // FIXME + return 0; return info.resident_size; } |