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

["Daniel Walter" <d2walter at hotmail dot com>]

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.

Daniel

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.