[sdcc-devel] [RFC] Flexible linking strategy for Unicode support libraries

[周 子益 <z12...@ou...>]

Hello SDCC developers,
Following the ongoing discussion about Unicode support and library dependencies, I'd like to propose a flexible approach to linking that balances multiple concerns: binary size, distribution reliability, and user choice.
The Challenge
As we consider integrating libraries like libu8ident for Unicode identifier support, we face the classic static vs dynamic linking dilemma:

  *
Static linking provides reliability and self-contained binaries
  *
Dynamic linking offers smaller binaries and shared library benefits

Rather than choosing one approach exclusively, I believe we can support both.
Proposed Solution: Build-time Configuration
I suggest implementing a flexible build system that supports:

# Default: static linking (reliability first)
./configure --with-u8ident=static

# Alternative: dynamic linking (size optimization)
./configure --with-u8ident=shared

# Disable entirely (for minimal builds)
./configure --without-u8ident

Benefits of This Approach
For End Users

  *
Default static linking ensures SDCC "just works" without external dependencies
  *
Advanced users can choose dynamic linking to optimize binary size
  *
Embedded developers can completely disable Unicode support for minimal builds

For Package Maintainers

  *
Linux distros can use dynamic linking and proper dependency declarations
  *
Windows binary distributions can use static linking to avoid DLL hell
  *
Source builds let users decide based on their specific needs

Technical Implementation
The build system could work like this:

# Detect library availability and user preference
ifdef HAVE_U8IDENT
  ifeq ($(U8IDENT_LINKING),shared)
    LIBS += -lu8ident
    CFLAGS += -DHAVE_U8IDENT_SHARED
  else
    LIBS += $(U8IDENT_STATIC_PATH)/libu8ident.a
    CFLAGS += -DHAVE_U8IDENT_STATIC
  endif
endif

And in the code:
#ifdef HAVE_U8IDENT_STATIC
// Use static library features
#elif defined(HAVE_U8IDENT_SHARED)
// Use shared library features
#else
// Fallback to basic Unicode support
#endif
Addressing Size Concerns
While dynamic linking reduces binary size, we can further optimize through:

  *
Strip debugging symbols in release builds
  *
Link Time Optimization to eliminate unused code
  *
Function-level linking to include only necessary components
  *
Conditional compilation to exclude Unicode support entirely when disabled

Distribution Strategy
Different platforms have different needs:
Platform
Recommended Default
Rationale
Windows binaries
Static
Avoids DLL deployment issues
Linux packages
Dynamic
Leverages package management
macOS
Either
Both work well with homebrew
Source builds
User's choice
Maximum flexibility
Next Steps

  1.
Implement the configure options for linking strategy
  2.
Add fallback code paths when libraries are unavailable
  3.
Document the options for different user scenarios
  4.
Gather feedback from package maintainers

This approach gives us the best of both worlds: reliability for casual users and optimization power for advanced users. It also respects the diverse deployment environments where SDCC is used.
I'm interested in hearing thoughts on this flexible linking strategy, particularly from package maintainers and those with experience in cross-platform library distribution.
Best regards,
zhouziyi