From 61c9204df4faa0769574e39ff0d7691bd785c654 Mon Sep 17 00:00:00 2001 From: Christoph Reiter Date: Tue, 9 Jul 2024 20:34:02 +0200 Subject: [PATCH] glib-private: fix build under Cygwin fb58d55187dfe1565d10c0c0ffdbaa85376cf0b8 added weak linking for ASAN, skipping it for MinGW because weak symbols are broken there. The same is true for Cygwin, so skip things there too. This fixes the following build error under MSYS2: /usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../../x86_64-pc-msys/bin/ld: glib/msys-glib-2.0-0.dll.p/gutils.c.o:gutils.c: (.rdata$.refptr.__lsan_enable[.refptr.__lsan_enable]+0x0): undefined reference to `__lsan_enable' --- glib/glib-private.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/glib/glib-private.h b/glib/glib-private.h index c24b59d6f..28ac63458 100644 --- a/glib/glib-private.h +++ b/glib/glib-private.h @@ -47,14 +47,14 @@ /* If GLib itself is not compiled with ASAN sanitizer we may still want to * control it in case it's linked by the loading application, so we need to * do this check dynamically. - * However MinGW doesn't support weak attribute properly (even if it advertises + * However MinGW/Cygwin doesn't support weak attribute properly (even if it advertises * it), so we ignore it in such case since it's not convenient to go through * dlsym(). * Under MSVC we could use alternatename, but it doesn't seem to be as reliable * as we'd like: https://stackoverflow.com/a/11529277/210151 and * https://devblogs.microsoft.com/oldnewthing/20200731-00/?p=104024 */ -#elif defined (G_OS_UNIX) && !defined (__APPLE__) && g_macro__has_attribute (weak) +#elif defined (G_OS_UNIX) && !defined (__APPLE__) && !defined(__CYGWIN__) && g_macro__has_attribute (weak) #define HAS_DYNAMIC_ASAN_LOADING