www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 24389] New: importC: Building zlib in Phobos with importC

https://issues.dlang.org/show_bug.cgi?id=24389

          Issue ID: 24389
           Summary: importC: Building zlib in Phobos with importC fails on
                    FreeBSD 14
           Product: D
           Version: D2
          Hardware: x86_64
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: issues.dlang jmdavisProg.com

This is not an issue on the latest release of dmd - 2.070 - but it is an issue
on master. It looks like with 2.070, we're still building zlib in Phobos
without importC, whereas with master, it's currently set up to use importC.
Presumably, that works on some systems, but it does not work on FreeBSD 14. The
relevant error in the Phobos build is

---
/tmp/building_dmd/bin/dmd -c -conf= -I../dmd/druntime/import  -w -de
-preview=dip1000 -preview=dtorfields -preview=fieldwise -m64 -fPIC -O -release
-P=-Ietc/c/zlib -P=-DHAVE_UNISTD_H -ofgenerated/freebsd/release/64/zlib.o
etc/c/zlib/adler32.c etc/c/zlib/compress.c etc/c/zlib/crc32.c
etc/c/zlib/deflate.c etc/c/zlib/gzclose.c etc/c/zlib/gzlib.c
etc/c/zlib/gzread.c etc/c/zlib/gzwrite.c etc/c/zlib/infback.c
etc/c/zlib/inffast.c etc/c/zlib/inflate.c etc/c/zlib/inftrees.c
etc/c/zlib/trees.c etc/c/zlib/uncompr.c etc/c/zlib/zutil.c
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
gmake[1]: *** [Makefile:328: generated/freebsd/release/64/zlib.o] Error 1
---

From looking at stdlib.h, I'm pretty sure that this is not a problem in FreeBSD
13 (and it looks like the current dlang CI stuff tests FreeBSD 13.2), but it is a problem in FreeBSD 14 (FreeBSD 14.0 currently being the latest release of FreeBSD). The FreeBSD 13 version of stdlib.h can be seen here: https://cgit.freebsd.org/src/tree/include/stdlib.h?h=stable/13 The FreeBSD 14 version of stdlib.h can be seen here: https://cgit.freebsd.org/src/tree/include/stdlib.h?h=stable/14 The section that's causing a problem does not exist in the FreeBSD 13 version, and it's --- /* * In FreeBSD 14, the prototype of qsort_r() was modified to comply with * POSIX. The standardized qsort_r()'s order of last two parameters was * changed, and the comparator function is now taking thunk as its last * parameter, and both are different from the ones expected by the historical * FreeBSD qsort_r() interface. * * Apply a workaround where we explicitly link against the historical * interface, qsort_r FBSD_1.0, in case when qsort_r() is called with * the last parameter with a function pointer that exactly matches the * historical FreeBSD qsort_r() comparator signature, so applications * written for the historical interface can continue to work without * modification. */ #if defined(__generic) || defined(__cplusplus) void __qsort_r_compat(void *, size_t, size_t, void *, int (*)(void *, const void *, const void *)); __sym_compat(qsort_r, __qsort_r_compat, FBSD_1.0); #endif #if defined(__generic) && !defined(__cplusplus) #define qsort_r(base, nel, width, arg4, arg5) \ __generic(arg5, int (*)(void *, const void *, const void *), \ __qsort_r_compat, qsort_r)(base, nel, width, arg4, arg5) #elif defined(__cplusplus) __END_DECLS extern "C++" { static inline void qsort_r(void *base, size_t nmemb, size_t size, void *thunk, int (*compar)(void *, const void *, const void *)) { __qsort_r_compat(base, nmemb, size, thunk, compar); } } __BEGIN_DECLS #endif --- Specifically, it's this line --- __sym_compat(qsort_r, __qsort_r_compat, FBSD_1.0); --- __sym_compat is a macro that comes from cdefs.h, which can be seen here: https://cgit.freebsd.org/src/tree/sys/sys/cdefs.h?h=stable/14 Specifically, the macro can be found in this block of code --- #if defined(__GNUC__) #define __strong_reference(sym,aliassym) \ extern __typeof (sym) aliassym __attribute__ ((__alias__ (#sym))) #ifdef __STDC__ #define __weak_reference(sym,alias) \ __asm__(".weak " #alias); \ __asm__(".equ " #alias ", " #sym) #define __warn_references(sym,msg) \ __asm__(".section .gnu.warning." #sym); \ __asm__(".asciz \"" msg "\""); \ __asm__(".previous") #define __sym_compat(sym,impl,verid) \ __asm__(".symver " #impl ", " #sym " " #verid) #define __sym_default(sym,impl,verid) \ __asm__(".symver " #impl ", " #sym " " #verid) #else #define __weak_reference(sym,alias) \ __asm__(".weak alias"); \ __asm__(".equ alias, sym") #define __warn_references(sym,msg) \ __asm__(".section .gnu.warning.sym"); \ __asm__(".asciz \"msg\""); \ __asm__(".previous") #define __sym_compat(sym,impl,verid) \ __asm__(".symver impl, sym verid") #define __sym_default(impl,sym,verid) \ __asm__(".symver impl, sym verid") #endif /* __STDC__ */ #endif /* __GNUC__ */ --- I don't know if __GNUC__ is being defined when zlib.c is being compiled, but if it is, then the macro is --- #define __sym_compat(sym,impl,verid) \ __asm__(".symver " #impl ", " #sym " " #verid) --- whereas if it isn't, then it's --- #define __sym_compat(sym,impl,verid) \ __asm__(".symver impl, sym verid") --- However, I'm not sure that it really matters which version is being used with regards to importC's complaint. It seems to dislike how __asm__ is being used, but I don't know enough about __asm__ to really comment on what could be wrong here. But regardless of what importC needs to do here, until it's fixed, zlib in Phobos cannot be built with importC on FreeBSD 14, and while that may not be a problem with the CI at the moment, it will be eventually once it's testing FreeBSD 14, and it's certainly a problem for me, since that's what I currently run on my main machine. And since this is a macro that FreeBSD uses periodically to deal with backwards compatibility issues, I'd expect it to pop up again at some point - and it can probably be hit with FreeBSD 13 as well, just with a different function somewhere that doesn't affect building zlib. --
Feb 11