I'm writing a Windows user interface from scratch but using winelib so that I can develop in Linux where the development of the program's library is taking place.
I'm linking to libwine, libkernel32.dll and libuser32.dll but there doesn't seem to be an implementation of main() anywhere so I get a "undefined reference to `main'" from "_start".
Currently I just have the WinMain function, no other code yet.
What am I doing wrong?
The winelib user's guide is no good for answering this sort of thing, by the way. It assumes you're porting rather than writing from scratch.
Thanks
Chris Seaton
On February 12, 2004 06:39 am, Chris Seaton wrote:
I'm linking to libwine, libkernel32.dll and libuser32.dll but there doesn't seem to be an implementation of main() anywhere so I get a "undefined reference to `main'" from "_start".
If you are building your app using winegcc (you should!), make sure you pass it -mwindows. If it still doesn't work, please let me know.
Dimitrie O. Paun wrote:
If you are building your app using winegcc (you should!), make sure you pass it -mwindows. If it still doesn't work, please let me know.
Hmmm... I wasn't aware of winegcc (the tutorial doesn't mention it). Do I have to use winegcc? The script it generates seems to use wine, but I thought winelib could be used independantly of wine.
Is it not possible to generate a normal, single file binary that simply uses winelib to provide the Windows API functions?
Using winegcc -mwindows did solve my problem, but now I can't use GDB on my program because it's in a DLL that I can't start in GDB, that's why I don't like the wrapper script.
Chris Seaton
On Thu, 12 Feb 2004, Chris Seaton wrote:
Hmmm... I wasn't aware of winegcc (the tutorial doesn't mention it). Do I have to use winegcc? The script it generates seems to use wine, but I thought winelib could be used independantly of wine.
You don't have to use winegcc, but you only gain complexity if you don't. Your winelib app will still have to use wine, it can't be made independant of wine ATM.
Is it not possible to generate a normal, single file binary that simply uses winelib to provide the Windows API functions?
No. This is a long discussion, please search the archives. Bottom line is that you can't, and this will likely not change in the near future.
Using winegcc -mwindows did solve my problem, but now I can't use GDB on my program because it's in a DLL that I can't start in GDB, that's why I don't like the wrapper script.
It generates a shell script that launches the .exe.so that it creates. Use winegdb on this one instead.
Chris Seaton wrote:
Using winegcc -mwindows did solve my problem, but now I can't use GDB on my program because it's in a DLL that I can't start in GDB, that's why I don't like the wrapper script.
You can still use GDB (or kdevelop or ddd): - check out what wine is running on your machine run a wine app and see in ps if you have wine-pthread or wine-kthread - run above under GDB - put yourapp.exe.so as the command line parameter in GDB Example: (gdb) set args -debugmsg err+all,warn+all -- /home/Wine/MyApp/MyApp.exe.so - set environment to match wine execution: Example: (gdb) set environment WINEDLLPATH=/home/Wine/wine/dlls:/home/Wine/wine/programs See your "test" script for exact details of environment used. - happy debugging under GDB
On February 15, 2004 03:26 am, Boaz Harrosh wrote:
You can still use GDB (or kdevelop or ddd):
- check out what wine is running on your machine run a wine app and see
in ps if you have wine-pthread or wine-kthread
- run above under GDB
- put yourapp.exe.so as the command line parameter in GDB Example: (gdb) set args -debugmsg err+all,warn+all --
/home/Wine/MyApp/MyApp.exe.so
- set environment to match wine execution: Example: (gdb) set environment
WINEDLLPATH=/home/Wine/wine/dlls:/home/Wine/wine/programs See your "test" script for exact details of environment used.
- happy debugging under GDB
This is a nice explanation, it should find it's way into some of our documentation (we already have a Winedbg section in the Devel Guide). Speaking of which, we don't have a man page for winedbg, do we need one?
Dimitrie O. Paun wrote:
Speaking of which, we don't have a man page for winedbg, do we need one?
Yes we need one! I need one :) in theory, it should be cut and paste from man gdb, right?
And if some winedbg guru could see if we can run under DDD or kdevelop. I know the later can accept a different path and name for the debugger and I know that winedbg is command compatible to gdb. So as long as winedbg Just silently accepts gdb commands it does not support and returns "no error". than we can give Windows developers (like me) a nice IDE with integrated debugger for both PE and "built in" code.
And one more Question does winedbg supports Mingw / Cygwin PE debug info?
Free Life Boaz
Boaz Harrosh a écrit :
Dimitrie O. Paun wrote:
Speaking of which, we don't have a man page for winedbg, do we need one?
Yes we need one! I need one :) in theory, it should be cut and paste from man gdb, right?
in depends which mode you run. in --gdbproxy, man gdb will do otherwise, you get a subset of (somehow modified) gdb commands
And if some winedbg guru could see if we can run under DDD or kdevelop.
that's documented... http://www.winehq.com/site/docs/wine-devel/dbg-others
And one more Question does winedbg supports Mingw / Cygwin PE debug info?
this used to work a couple of months ago, but I didn't check lately
A+
-
Boaz Harrosh -
Chris Seaton -
Dimitrie O. Paun -
Dimitrie O. Paun -
Eric Pouech