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

Sorry for joining this thread sideways and lately
At:    http://gcc.gnu.org/ml/java/2008-12/msg00032.html

Andrew Haley wrote:
>"So, which object file in libmingw.a contains the undefined reference to
> `WinMain@16'  And what dependency is causing it to be pulled in?"

On i386 targets libgcj has a undefined reference to 'main' due to the
fallback backtrace code introduced with this patch:

2006-07-14  Ranjit Mathew  <[email protected]>

	* stacktrace.cc (_Jv_StackTrace::GetStackTrace): Unconditionally use
	_Unwind_Backtrace().
	(_Jv_StackTrace::GetCallerInfo): Enable even for targets using SJLJ
	EH.
	(_Jv_StackTrace::GetClassContext): Unconditionally use
	_Unwind_Backtrace().
	(_Jv_StackTrace::GetFirstNonSystemClassLoader): Likewise.
	* sysdep/i386/backtrace.h (HAVE_FALLBACK_BACKTRACE): Do not define.
	(_Unwind_GetIPInfo): Define macro if SJLJ EH is in use.
	(_Unwind_GetRegionStart): Likewise.
	(_Unwind_Backtrace): Likewise.
>>>>>	(fallback_backtrace): Accept additional unwind trace function
>>>>>	argument.  Call it during unwinding.  Stop when any of _Jv_RunMain(),
>>>>>	_Jv_ThreadStart() or main() is seen during unwinding.
	* sysdep/generic/backtrace.h (fallback_backtrace): Accept an
	additional unwind trace function argument.


This code. and reference to 'main' gets pulled into the users dll from
a static libgcj.a
Since windows dll's (unlike ELF shared objects) do not allow undefined
symbols, the reference to 'main' must be resolved in the dll.

In the event, it is resolved by mingw runtime's main.c, which just
calls WinMain (an
alternative 'main' for Windows GUI apps in MSVC land).  I won't go
into detail's but
this main.c in libmingw.a is an old hack for the benefit of MSVC-based code.

A dummy main() in the dll is one workaround,  but you need to be
careful not to export it.

Danny