Thanks for the update. No rush. It sounds like you have some good ideas.
By the way, David Dawes made a comment to another developer today about possibly revisiting the design of linking static libraries into the X Server after 4.4.0 is released. This may be accepted as a general patch for all platforms if that ends up happening (or at least as a general mechanism that other platforms could use).
Harold
Alexander Gottwald wrote:
Alexander Gottwald wrote:
Harold L Hunt II wrote:
Okay, do you want to look into why XWin.exe crashed on startup with the shared version of the Xfont library? Or, are you willing to let me handle that? :)
First should be xfs working with the shared lib. I've tried the shared linked xfs and it failed. Relinking it with the static Xfont solved the problem. So there must be a big difference in the way how the libs are build.
Results of my closer look:
The stub library (libfntstubs) is required because the libXfont design requires undefined symbols, which are defined in the program (eg ErrorF). libfntstubs provides the functions as non-functional ones. the only consist of the prototype and an return.
Some of the functions initalize global structures (RegisterFPEFunctions). RegisterFPEFunctions is not defined in libXfont but in xfs. Unfortunatly the dlls do not allow undefined symbols and the stub library is used, but now the required initialisation of the global structures is not done.
As a fix I think of changing the stubs to use an indirect call:
func_type *_RegisterFPEFunctions = NULL; int RegisterFPEFunctions(...) { if (_RegisterFPEFunctions == NULL) return 0; else _RegisterFPEFunctions(...); }
and set it with code added to libXfont.dll.a which is linked staticly into the program:
extern func_type *_RegisterFPEFunctions;
void __init() { _RegisterFPEFunctions = RegisterFPEFunctions; }
But this still requires some days. I'm away for the next weekend.
bye ago
NP: Terminal Choice - Flesh in Chains
