creating shared dlls yields undefined reference to `WinMain@16' in mingw 4.3

[BGB]

----- Original Message ----- 
From: "Daniel Walter" <d2walter@hotmail.com>
To: "BGB" <cr88192@hotmail.com>; "Andrew Haley" <aph@redhat.com>
Cc: "Danny Smith" <dansmister@gmail.com>; <java@gcc.gnu.org>
Sent: Saturday, December 20, 2008 2:06 AM
Subject: Re: creating shared dlls yields undefined reference to `WinMain@16' 
in mingw 4.3


> This code is using Tool Help to enumerate the modules that have been 
> loaded. It is still making module handles and looking for process 
> addresses in the standard way though so I don't think it will be able to 
> find WinMain or other non-exported symbols.
>
> There are a few other ideas I have about searching for an entry point 
> function, but I don't really think this is a good idea.  The only 
> situation I see where it would be a good thing for gcj to backtrace to a 
> WinMain is if the WinMain came from gcj --main= and there are better ways 
> to take care of this situation.
>
> In my testing, when I throw an exception, the backtrace ends at the CNI. 
> From a reliability standpoint, I think this is highly desirable.
>
> Daniel
>

ok.


as noted though, in my project I don't use GetProcAddress (except really in 
the case of managing dll's), mostly because at the time it had only managed 
to find exported symbols.

I had presumed tool help would locate modules for the non-exported symbols 
as well, after all, this is what the FoNC project seems to be using it for, 
but I don't know since I have not tested it.


now, what my project does is a little different, namely I manually load and 
process the EXE in order to get at the symbol table (this is an ugly 
approach, but it works).

of course, my project also implements its own linker, so an internal 
at-runtime symbol table is kept.
this linker is used when loading static libraries or object files, and also 
for dynamically-compiled modules (currently, my project only natively 
compiles assembler and C, and my existing and working C compiler only 
targets x86).

the great practical cost in my project at present is that of the overhead 
(in terms of both memory and time) currently required to dynamically compile 
C code (making large-scale compilation of tiny code fragments 
impractical...). (on Linux it could be reasonably to fall back to externally 
calling GCC, which is at least a little faster, and leaves the memory issue 
up to the OS to deal with, but on Windows this is not a reasonable option as 
we can't expect GCC to always be available to the app...).

possible potentially useful GCC feature (could exist for all I know, I have 
not looked into this):
ability to include GCC as a library, and invoke it at runtime;
it should be able to accept source files and return an object file in a 
buffer;
it should be "usable" on windows (AKA: no dependence on external binaries or 
directories, and with few, if any, required DLL's, preferably with the 
entire toolchain as a single larger DLL...);
..


dynamic Java compilation and JIT as such should be, WRT overhead, a bit 
lower than C (if albeit the runtime overhead in general is likely to be 
somewhat greater than C...). this could make it more practical for many 
tasks (although, granted, some of us don't as much like Java as a 
language...).

or such...