Matthew Kille wrote:
> Hi Kevin,
>
> > A ".a" file is composed of a set of ".o" files. When linking with a
> > ".a" library, the linker will only pull in those ".o" files that
> > resolve an outstanding symbol. So, if the linker doesn't have WinMain
> > outstanding, it shouldn't try to pull in winmain_ce.o.
>
> Many thanks for answering this. I had really started to assume that the
> compiler was doing something special to handle this WinMain(). But now
> is it clear that is not the case, I have be able to try a different path.
>
> Does it pull in the entire object file even if it just wants to resolve
> a symbol that is only a part of that file? And can other symbols in that
> file affect the resolution of other symbols later on? (See below.)
>
> > Odd. Out of curiousity, does the following work:
> > $ arm-wince-mingw32ce-gcc -o output.exe main.c libmylib.a
> > if not, how about:
> > $ arm-wince-mingw32ce-gcc -o output.exe libmylib.a main.c
>
> Neither worked. But I have narrowed down the code to the absolute
> minimum and it seems I was chasing the wrong thing. I shouldn't have
> been looking at the library nor the WinMain() function it contained, but
> instead what that WinMain() function contained.
>
> Here is the complete single file minimum test program that causes the
> same error:
>
> #include <windows.h>
>
> int APIENTRY WinMain(HINSTANCE hInstance,
> HINSTANCE hPrevInstance,
> LPWSTR lpCmdLine,
> int nCmdShow)
> {
> return __argc;
> }
>
> When compiling:
>
> $ arm-wince-mingw32ce-gcc -o mytest.exe mytest.c
> [...]/arm-wince-mingw32ce/lib/libmingw32.a(winmain_ce.o): In function
> `WinMain':
> [...]/cegcc/src/mingw/winmain_ce.c:143: multiple definition of `WinMain'
> [...]/ccxFleEh.o:mytest.c:(.text+0x0): first defined here
> [...]/arm-wince-mingw32ce/lib/libmingw32.a(winmain_ce.o):winmain_ce.c:(.text+0x1e0):
> undefined reference to `main'
> collect2: ld returned 1 exit status
>
>
> (Am I supposed to be using '__argc' like this?)
>
> The linker appears to pull this variable in from winmain_ce.c, which
> also then also gives me the multiple WinMain() definition.
>
The linker isn't doing anything special with WinMain. The problem is
that __argc
is defined in the same .o as the default WinMain. So the linker pulls your
WinMain, which then pulls the __argc, contained in winmain_ce.o, which
also contains a WinMain ...
>From what I remember the last time we were looking into Winmain, msvc
doesn't parse and fill __argc/__argv with real values unless you use the
mainCRTStartup -> main entry point.
Which means that your WinMain will always return 0 - if it builds. Does
it build with MSVC?
We can fix the linking error by moving __argc/__argv to a
separate .o, but you should only be using them if you use main
instead of WinMain.
Cheers,
Pedro Alves
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
