Claus Fischer wrote:
Since I'm not familiar with the Wine debugger, it would have been very helpful to be able to use gdb on the resulting executable. However, gdb reported that it didn't know the file format.
==> Wishlist to Wine:
- Make gdb work on Winelib programs
http://www.winehq.org/site/docs/winedev-guide/dbg-others
- Document Winelib and the build process better (the documentation is outdated, though the tools are good).
All in all a reasonably successful endeavour, and the application runs stable and looks fine except for the font (that probably can be configured better).
BUT: ... BIG SHOCK: That's not a single ELF executable, it's a weird mixture of PE and ELF and a .so file and a wrapper program that apparently starts wine in the background ...
http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_%2eexe%2eso
That doesn't fulfill my goals of building a native Linux exe with no dependencies except libc.
Maybe your goals are wrong.
It's also quite slow when loading.
Have you tried using oprofile? Is it the Wine code that is slow or the libc dynamic loader?
- What is needed
What would be needed to support static linking against Winelib (if that's decided to be a supportworthy goal):
- Infrastructure to build static libs
- separate out DllMain
- separate out some 16 bit functions
The isn't going to work for any application which needs COM or that needs multimedia, due to their dependence on using DLLs as function tables.
- Possibility to provide heap based allocation
through straight malloc()
What does this give you?
- Infrastructure for proper initialization of modules
e.g. through one setup function for each DLL and one common setup function that calls the others in some natural order The overall initialization function should be configurable so that programs that need only a few DLL's (user, gdi, crtdll, kernel, ntdll) don't need to link everything
- Infrastructure to allow faking registry calls
for those calls initiated by Winelib internal stuff (and possibly also ATL/WTL internal stuff)
- Infrastructure to handle Window class registration
etc. (i.e. reduced Wine server support in the app)
You really don't want to try without wineserver support. Nearly everything depends on at least one feature that the wineserver provides. If you try to make your own version of wineserver that is somehow statically linked into the application you will have to completely change how it works and maintain that version on your own.
You're doing a noble thing in trying to get your Winelib application easy to deploy, but I think you're going about it the wrong way.
For maintainability, take a look at using the WINEPREFIX environment variable and use dynamic libraries. That way you can deploy upgrades of your application in a small installer, whilst not needing to update the Wine libraries. If you need a bug fix in a Wine library, then you can just update the one dynamic library that has changed. If the startup speed isn't good enough for you, you can use oprofile (or some other profiling framework) to work out which functions are taking up time. We would welcome any fixes to improve the startup speed. Optionally, you could comment out functions do things that you don't need.