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

[Andrew Haley <aph at redhat dot com>]

Daniel Walter wrote:
> I have been trying to proceed with a dummy WinMain, but I have been
> having some strange errors.  I am still tracing through this, but am not
> sure how I could be getting java.lang.NoClassDefFoundError with
> something that should have linked in.
> 
> Are you saying we need the address of the real main for the backtrace to
> work.  This could explain some of the weirdness in the backtraces. 
> Having the real WinMain address is probably not going to do any good
> though because this is a gcc dll that is being used in a VC++
> application.  I don't think gcc can backtrace through the VC call stack.

I have no idea about that, sorry.  This stack trace looks OK, though.

I'm wondering if you're linking correctly.  The usual reason stuff
like this fails is when someone is linking with the static library
libgcj.a.  This can mean that files like iso4217.properties.o, which
java.util.Currency needs, are not found.

I can't remember: does mingw have libgcj.dll?  If so that should fix
the problem, but I vaguely remember that it didn't.

Andrew.



> PDF library message java.lang.ExceptionInInitializerError^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   at java.util.Currency.getInstance(pdflink.cpp:0)^M
>   at java.text.DecimalFormatSymbols.<init>(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.ByteBuffer.<clinit>(pdflink.cpp:0)^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.PdfName.<init>(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.PdfName.<init>(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.PdfName.<clinit>(pdflink.cpp:0)^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.PdfWriter.<clinit>(pdflink.cpp:0)^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.PdfWriter.getInstance(pdflink.cpp:0)^M
>   at ads.Draw.createDocument(pdflink.cpp:0)^M
> Caused by: java.lang.NullPointerException^M
>   at java.io.InputStreamReader.read(pdflink.cpp:0)^M
>   at java.io.BufferedReader.fill(pdflink.cpp:0)^M
>   at java.io.BufferedReader.readLine(pdflink.cpp:0)^M
>   at java.util.Properties.load(pdflink.cpp:0)^M
>   at java.util.Currency.<clinit>(pdflink.cpp:0)^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   ...12 more^M
> 
> 
> PDF library message java.lang.NoClassDefFoundError:
> com.lowagie.text.pdf.PdfName
> ^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.BaseFont.<clinit>(pdflink.cpp:0)^M
>   at java.lang.Class.initializeClass(pdflink.cpp:0)^M
>   at com.lowagie.text.pdf.BaseFont.createFont(pdflink.cpp:0)^M
>   at ads.Draw.getEmbedFont(pdflink.cpp:0)^M
> 
> ----- Original Message ----- From: "Andrew Haley" <aph@redhat.com>
> To: "Danny Smith" <dansmister@gmail.com>
> Cc: <d2walter@hotmail.com>; <java@gcc.gnu.org>
> Sent: Wednesday, December 17, 2008 5:34 AM
> Subject: Re: creating shared dlls yields undefined reference to
> `WinMain@16' in mingw 4.3
> 
> 
>> Danny Smith wrote:
>>> 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:
>>>
>>> A dummy main() in the dll is one workaround,  but you need to be
>>> careful not to export it.
>>
>> Mmm, but it won't do the job we need: we have to have the address of
>> the real main.  Is there some Windows equivalent of dlsym() we can
>> use?
>>
>> Andrew.
>>
>