brain dump
- mulle-dlfcn is tricky because it needs dlfcn-win32 on windows
- mulle-stacktrace is tricky because it needs libbacktrace
- mulle-testallocator needs mulle-dlfcn and mulle-stacktrace
- mulle-core provides dlfcn (currently)
mulle-core should "just" work as a git submodule without any (major tricks) mulle-core used to provide mulle-stacktrace, but does no longer, due to libbacktrace not working cross platform
- mulle-core should be able to exist on its own
- its inconvenient to link a half dozen of little files with all-load
- all these need to be statically linked anyway except mulle-testallocator
Plan #
- move mulle-dlfcn out of mulle-core
- create mulle-core-allload (with atinit, atexit, stacktrace, dlfcn) which is always static
Ok named is mulle-core-startup, probably a mistake. Since "regular" code also needs to link against it. Especially the runtime needs dlsym. So back to allload...
Problem #
MulleObjC wants mulle-objc-list as a dependency. (its an executable though), this carries mulle-objc-startup (all-load) with it. This will squat mulle-dlfcn, which the runtime needs, As it comes in too late, then the runtime can't compile, because mulle-dlfcn won't be there yet.
There are like a hundred different ways to "fix" this
- make a very complicated algorithm to ensure that the amalgamation squatting is not disturbing the craftorder sequence
is not one of them
last updated: