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

Danny Smith
Wed Dec 17 07:47:00 GMT 2008

Sorry for joining this thread sideways and lately

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  <>

	* (_Jv_StackTrace::GetStackTrace): Unconditionally use
	(_Jv_StackTrace::GetCallerInfo): Enable even for targets using SJLJ
	(_Jv_StackTrace::GetClassContext): Unconditionally use
	(_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.


More information about the Java mailing list