src/xpdev wrapdll.h 1.7 1.8
Update of /cvsroot/sbbs/src/xpdev
In directory cvs:/tmp/cvs-serv32122/xpdev

Modified Files:
wrapdll.h
Log Message:
Use default calling convention (__cdecl) for DLL funcs in Borland builds.

Fix age-old bug with Borland/C++Builder built executables (Windows):
to achieve compatibility with the default __cdecl symbol naming rules of Visual C++, we were using __stdcall convention for DLL functions when
building code with Borland/C++Builder tools and using the default (__cdecl) convention when building with Microsoft (Visual C++) tools. Although this allowed symbols to be located when linking, the calling convention mismatch caused a stack cleanup issue that very rarely manifested itself in a bug
(e.g. exception of some kind in sbbsctrl.exe, usually). Mismatching
the calling conventions was unintentional (I thought the default for MSVC
DLL functions was __stdcall) - but since the calls to MSVC-Built DLL functions worked 99% of the time, I didn't realize there was an underlying issue. So I now work-around the DLL symbol naming mismatch using a command-line option (-a) passed to implib in src/sbbs3/ctrl/makelibs.bat

I had previously worked-around exceptions when calling MSVC DLL functions in sbbsctrl.exe by calling the problematic DLL functions from a timer tick handler rather than a user control (e.g. button) event handler. Those work-arounds can now be removed.

The erroneous "DLLCALL" definition design pattern was replicated (copy/pasted) to many other projects' header files in cvs.synchro.net. In the future, we may want to just remove all instances of *CALL since they now serve no purpose and appear as useless "Kruft" (but do allow us to more-easily globally change DLL function calling conventions if/when necessary in the future).



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ea63a7844ac80992fa6862d8
Modified Files:
src/xpdev/wrapdll.h
Log Message:
Add ELF visibility("default") attribute to DLLEXPORT on GCC/Clang

On Windows, DLLEXPORT expands to __declspec(dllexport) or __declspec(dllimport), controlling which symbols are exported from
DLLs. On non-Windows, it previously expanded to nothing.

This adds __attribute__((visibility("default"))) for GCC and Clang,
which is the ELF equivalent of dllexport Ä it marks a symbol for
export from shared libraries.

Currently this is a no-op: ELF defaults to "default" visibility for
all symbols, so the attribute is redundant. It would only take effect
if code were compiled with -fvisibility=hidden, which flips the
default so that only explicitly-marked symbols are exported.

Unfortunately, -fvisibility=hidden cannot be enabled project-wide
because the gmake build system shares library CFLAGS variables (XPDEV-MT_CFLAGS, CIOLIB-MT_CFLAGS, etc.) across consumers. Adding
the flag to any library's CFLAGS bleeds into sbbs3 and other
projects, hiding symbols that lack DLLEXPORT annotations and breaking
shared library linking. Scoping it to only shared library targets
would require separate output directories for objects destined for
.so files vs static archives Ä doubling the existing single/multi-
thread directory split (obj.release, obj.release-mt,
obj.release-shlib, obj.release-mt-shlib, and again for debug).

In the meantime, the attribute documents export intent in the source
and is ready to take effect when visibility control is enabled
per-target.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net