I've got the impression that during program building (clock, notepad etc.) a spec file for them is created on the fly, can someone confirm/dispute this? Ivan.
Is it the spec file that determines whether wine looks for main or WinMain? The only info about spec files I could find was on page 20 of the winelib guide (section 3.4.2), it says that it is very outdated and doesnt currently describe winebuild and spec files. Besides that, it doesnt have enough information about what to call the file, or how to link it into my project. Im thinking that this is why Im getting an unresolved reference to main when I compile using winelib. Maybe not, since earlier in the document, it implies that winemaker performs all the steps required for make to build an executable. This is all I need to get my half a million lines of code to run on Solaris. Thanks in advance for any help Rob Done At 11:19 AM 3/3/2005, Ivan Leo Puoti wrote:
I've got the impression that during program building (clock, notepad etc.) a spec file for them is created on the fly, can someone confirm/dispute this?
Ivan.
Le ven 04/03/2005 à 19:41, Rob D a écrit :
Is it the spec file that determines whether wine looks for main or WinMain?
No. If WinMain exists, it'll be used, even in the presence of main().
The only info about spec files I could find was on page 20 of the winelib guide (section 3.4.2), it says that it is very outdated and doesnt currently describe winebuild and spec files. Besides that, it doesnt have enough information about what to call the file, or how to link it into my project.
I don't think spec files for .exe are supported right now (sorry Ivan).
Im thinking that this is why Im getting an unresolved reference to main when I compile using winelib.
I guess you can't share the whole app. Could you then provide us with a simple Makefile/.c file exhibiting the same problem? I don't see any difference between using main() and WinMain() for a "Hello, world!"-type app, on Linux. The .o in which main() is compiled is on the final linking list, right? Try modifying your Makefile so you pass -save-temps to winegcc while building the final .so, that way it won't erase temp files (mainly .spec.c, and .spec.i, .spec.s, .spec.o). Also play with -v (verbosity level, can be additive). Vincent
Le sam 05/03/2005 à 04:46, Ivan Leo Puoti a écrit :
Vincent Béron wrote:
I don't think spec files for .exe are supported right now (sorry Ivan).
That must be fixed, in windows .exe files can export functions.
In Windows, .exe and .dll are basically the same thing (same file format, very similar sections, etc.). I don't know if building ntoskrnl.exe as a Wine dll would enable you to do what you want it to do (export functions). Vincent
On 05 Mar 2005 10:07:39 -0500, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote:
Le sam 05/03/2005 à 04:46, Ivan Leo Puoti a écrit :
Vincent Béron wrote:
I don't think spec files for .exe are supported right now (sorry Ivan).
That must be fixed, in windows .exe files can export functions.
In Windows, .exe and .dll are basically the same thing (same file format, very similar sections, etc.).
could that help with this problem? I installed Dragon NS4 and got around a set up problem by running the training util gentrain.exe from wineconsole The new version I just installed now has this as gentrain.dll Is there a way to run that from console? TIA -- Using Opera e-mail on Gentoo Linux
I have attached 2 Makefiles that give me the unresolved main error on Solaris10. AEP Makefile is supposed to make an executable from a few files and some libraries. Netclient is supposed to make a static lib, and it works good, but it complains about missing main also. Im not sure why I am having so many problems with this, but I tried compiling the same source and Makefiles on a Debian Linux machine, but got an error about ONLY_IN_WINELIB macro called without parameters or something. Then... I installed the 20050211 binary package on ANOTHER Debian machine, but it couldnt find the windows includes, so I manually added a path, then it complained about could not find -lwine lib. I assumed this was referring to libwine.so.1 found in /usr/lib, so I tried adding /usr/lib to the LIBRARIES_PATH in the makefile, but then it complained about /usr/lib file not found. Aaaaahh. At 06:24 PM 3/4/2005, Vincent Béron wrote:
Le ven 04/03/2005 à 19:41, Rob D a écrit :
Is it the spec file that determines whether wine looks for main or WinMain?
No. If WinMain exists, it'll be used, even in the presence of main().
The only info about spec files I could find was on page 20 of the winelib guide (section 3.4.2), it says that it is very outdated and doesnt currently describe winebuild and spec files. Besides that, it doesnt have enough information about what to call the file, or how to link it into my project.
I don't think spec files for .exe are supported right now (sorry Ivan).
Im thinking that this is why Im getting an unresolved reference to main when I compile using winelib.
I guess you can't share the whole app. Could you then provide us with a simple Makefile/.c file exhibiting the same problem?
I don't see any difference between using main() and WinMain() for a "Hello, world!"-type app, on Linux.
The .o in which main() is compiled is on the final linking list, right?
Try modifying your Makefile so you pass -save-temps to winegcc while building the final .so, that way it won't erase temp files (mainly .spec.c, and .spec.i, .spec.s, .spec.o). Also play with -v (verbosity level, can be additive).
Vincent
Le sam 05/03/2005 à 16:17, Rob D a écrit :
I have attached 2 Makefiles that give me the unresolved main error on Solaris10.
AEP Makefile is supposed to make an executable from a few files and some libraries.
I've only looked at the netclient one for now, I'll get to the other one soon.
Netclient is supposed to make a static lib, and it works good, but it complains about missing main also.
(I had to add explicit paths to your Makefile for Wine tools/libs/includes as my Wine is run from it's compile tree, and my ar didn't like -r -v and preferred rcv) See the attached main.cpp (I don't have yours). The output from a simple make is then (paths removed for clarity): winebuild -o netclient.dbg.c --debug -C. main.cpp winegcc -c -o netclient.dbg.o netclient.dbg.c wineg++ -c -o main.o main.cpp wineg++ -mwindows -o netclient.so main.o netclient.dbg.o -lodbc32 -lole32 -loleaut32 -lwinspool -lws2_32 -luuid ar rc netclient.a main.o r - main.o No error in the end. Could you try my main.cpp and report if it works or not? The whole ARCH part doesn't come from winemaker, right? It'd be much simpler to change the .a rule to: $(netclient_MODULE).a: $(netclient_OBJS) $(ARCH) $@ $(netclient_OBJS) No need to build a .so and then the .a. Anyway, it still doesn't point me in the right direction for your main() problem...
Im not sure why I am having so many problems with this, but I tried compiling the same source and Makefiles on a Debian Linux machine, but got an error about ONLY_IN_WINELIB macro called without parameters or something.
Then... I installed the 20050211 binary package on ANOTHER Debian machine, but it couldnt find the windows includes, so I manually added a path, then it complained about could not find -lwine lib. I assumed this was referring to libwine.so.1 found in /usr/lib, so I tried adding /usr/lib to the LIBRARIES_PATH in the makefile, but then it complained about /usr/lib file not found.
If you add a dir to LIBRARY_PATH/netclient_LIBRARY_PATH, you need to also add the -L prefix, else ld in the end will think it's a file you want to link. Vincent
Le sam 05/03/2005 à 16:17, Rob D a écrit :
I have attached 2 Makefiles that give me the unresolved main error on Solaris10.
AEP Makefile is supposed to make an executable from a few files and some libraries.
Now I've had time to look at this one. I simplified it a bit (only kept ../netclient/netclient.a and main.cpp), and did the same thing about paths. Again, I've attached the main.cpp file (Main.rc is empty). Here's the output: winebuild -o aep.exe.dbg.c --debug -C. main.cpp.o aep.exe.so aep winegcc -c -I. -o aep.exe.dbg.o aep.exe.dbg.c wineg++ -c -I. -o main.o main.cpp wrc -I. -foMain.res Main.rc wineg++ -mwindows -o aep.exe.so main.o Main.res aep.exe.dbg.o ../netclient/netclient.a -lodbc32 -lole32 -loleaut32 -lwinspool -lws2_32 -lcomctl32 -luuid The resulting .exe.so does run correctly, showing 12 in a MessageBox. Could you also try with the same files on your end, and report if it works? Vincent
Thank you VERY much. I changed alot of things, including reinstalling Debian to get rid of 3 different source installs, and some gcc tweaks I had done before I learned muc about it, but I am sure the suggestions you gave resulted in perfectly clean builds on Debian Sarge. After some tweaking of my source code, and reformatting of some text mode data files, I was able to get my half a million lines of code to run more than well enough for my presentation. I have renewed confidence in the Wine project now. I am still having a few issues with compiling on Solaris, but they are probably just environment related, and my main issue of getting my presentation by today was VERY successful and will probably result in migrating our entire development team off the dreadful Windows platform!!! I just want to stress how pivotal yours and Boaz's help was in me getting this project completed on time. I never would have been able to do it without your help. Thank you again. I dont know how much help Ill be able to contribute to this list right away, since I have very little Linux/Unix experience, but I should be able to help with issues that come up on the list that require intricate knowledge of Windows API, since I have been programming on the "Dark Side" for over a decade now. Ok, Ill shut up now. Thanks again, Boaz and Vincent. Rob Done At 05:36 PM 3/6/2005, Vincent Béron wrote:
Le sam 05/03/2005 à 16:17, Rob D a écrit :
I have attached 2 Makefiles that give me the unresolved main error on Solaris10.
AEP Makefile is supposed to make an executable from a few files and some libraries.
Now I've had time to look at this one. I simplified it a bit (only kept ../netclient/netclient.a and main.cpp), and did the same thing about paths.
Again, I've attached the main.cpp file (Main.rc is empty).
Here's the output: winebuild -o aep.exe.dbg.c --debug -C. main.cpp.o aep.exe.so aep winegcc -c -I. -o aep.exe.dbg.o aep.exe.dbg.c wineg++ -c -I. -o main.o main.cpp wrc -I. -foMain.res Main.rc wineg++ -mwindows -o aep.exe.so main.o Main.res aep.exe.dbg.o ../netclient/netclient.a -lodbc32 -lole32 -loleaut32 -lwinspool -lws2_32 -lcomctl32 -luuid
The resulting .exe.so does run correctly, showing 12 in a MessageBox.
Could you also try with the same files on your end, and report if it works?
Vincent
Hi, On Mon, Mar 07, 2005 at 11:01:49PM +0000, Rob D wrote:
Thank you VERY much. I changed alot of things, including reinstalling Debian to get rid of 3 different source installs, and some gcc tweaks I had done before I learned muc about it, but I am sure the suggestions you gave resulted in perfectly clean builds on Debian Sarge. After some tweaking of my source code, and reformatting of some text mode data files, I was able to get my half a million lines of code to run more than well enough for my presentation. I have renewed confidence in the Wine project now. Reinstalling Debian!? Boy, I haven't done that in 9 years!
There are tools like cruft or others to deal with indicating which parts aren't coming from a package, or tools to register source-installed files properly (the name of such tools escapes me). But OTOH this might still be too much work to figure out in case of a thoroughly source-installed (read: messed-up ;-) system.
I am still having a few issues with compiling on Solaris, but they are probably just environment related, and my main issue of getting my presentation by today was VERY successful and will probably result in migrating our entire development team off the dreadful Windows platform!!! Congrats on that one!
I dont know how much help Ill be able to contribute to this list right away, since I have very little Linux/Unix experience, but I should be able to help with issues that come up on the list that require intricate knowledge of Windows API, since I have been programming on the "Dark Side" for over a decade now. To be fair, that probably doesn't matter too much. The main point is that you can continue here, whether you contribute very much or a little is less important than that IMHO. Still, all contributions welcome :)
Andreas Mohr
participants (5)
-
Andreas Mohr -
Ivan Leo Puoti -
peter＠piments.com -
Rob D -
Vincent Béron