|
From: 周 子益 <z12...@ou...> - 2025-10-29 03:28:22
|
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
|