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

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

[Daniel Walter]

Whenever I add an object file that was generated with gcj to a g++ link 
command for a shared dll, I get an undefined reference to `WinMain@16'. 
This seems to indicate that for some reason gcc wants to build an executable 
instead of a shared library.  This was working in gcc 3.4 - though I was 
using cygwin with gcj -mno-cygwin which is no longer supported.

Is building dlls with g++ and gcj supported in newer versions of gcc?
Is there a different link command that will not try to build an executable?


works> g++ -shared cpptest.o -o pdflib.dll

works - event with lgcj> g++ -shared cpptest.o -lgcj -lws2_32 -o pdflib.dll

fails - it tries to build an executable> g++ -shared javatest.o 
cpptest.o -lgcj -lws2_32 -o pdflib.dll

Daniel

BTW, thank you for the help with the C++ references for garabage collection. 
Exactly how this works is still a little fuzzy, but at least I know what I 
can do to make things work.


gcc -v
Using built-in specs.
Reading specs from c:/documents and settings/dan/my 
documents/programs/cygwin/ho
me/dan/ming/bin/../lib/gcc/mingw32/4.3.0/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: mingw32
Configured with: 
./gcc-4.3.0/configure --enable-languages=c,ada,c++,fortran,jav
a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl
e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab
le-concept-checks --enable-version-specific-runtime-libs --build=mingw32 --with-
bugurl=http://www.mingw.org/bugs.shtml --prefix=/mingw --with-gmp=/mingw/src/gcc
/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/
mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC) 

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

[Andrew Haley]

Daniel Walter wrote:
> Whenever I add an object file that was generated with gcj to a g++ link
> command for a shared dll, I get an undefined reference to `WinMain@16'.
> This seems to indicate that for some reason gcc wants to build an
> executable instead of a shared library.  This was working in gcc 3.4 -
> though I was using cygwin with gcj -mno-cygwin which is no longer
> supported.
> 
> Is building dlls with g++ and gcj supported in newer versions of gcc?
> Is there a different link command that will not try to build an executable?
> 
> 
> works> g++ -shared cpptest.o -o pdflib.dll
> 
> works - event with lgcj> g++ -shared cpptest.o -lgcj -lws2_32 -o pdflib.dll
> 
> fails - it tries to build an executable> g++ -shared javatest.o cpptest.o -lgcj -lws2_32 -o pdflib.dll

More information needed.  'g++ -v' will show you what is being linked.
There is presumably a way to ask what symbols are needed by the various
libraries that you're linking, so have a look which one needs `WinMain@16'.

Andrew.

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

[Daniel Walter]

It appears that libmingw.a is causing the problem, though this library can 
be linked to form a dll as long as no gcj object files are linked as well. 
Below are the results of the attempts to link with 'g++ -v' first with gcj 
objects which failed and the second time with only g++ objects.


g++ -shared -v ads\pdflink.o pdflib.a -lgcj -lws2_32 -o pdflib.dll
Using built-in specs.
Target: mingw32
Configured with: 
./gcc-4.3.0/configure --enable-languages=c,ada,c++,fortran,jav
a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl
e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab
le-concept-checks --enable-version-specific-runtime-libs --build=mingw32 --with-
bugurl=http://www.mingw.org/bugs.shtml --prefix=/mingw --with-gmp=/mingw/src/gcc
/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/
mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC)
COMPILER_PATH=c:/documents and settings/dan/my 
documents/programs/cygwin/home/da
n/ming/bin/../libexec/gcc/mingw32/4.3.0/;c:/documents and settings/dan/my 
docume
nts/programs/cygwin/home/dan/ming/bin/../libexec/gcc/;c:/documents and 
settings/
dan/my 
documents/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../.
/../../mingw32/bin/
LIBRARY_PATH=c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan
/ming/bin/../lib/gcc/mingw32/4.3.0/;c:/documents and settings/dan/my 
documents/p
rograms/cygwin/home/dan/ming/bin/../lib/gcc/;c:/documents and 
settings/dan/my do
cuments/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../../../../m
ingw32/lib/;c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/
ming/bin/../lib/gcc/mingw32/4.3.0/../../../
COLLECT_GCC_OPTIONS='-shared' '-v' '-o' 'pdflib.dll' '-mtune=i386'
 c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/..
/libexec/gcc/mingw32/4.3.0/collect2.exe --shared -Bdynamic -e 
_DllMainCRTStartup
@12 --enable-auto-image-base -o pdflib.dll c:/documents and settings/dan/my 
docu
ments/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../../../dllcrt
2.o c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin
/../lib/gcc/mingw32/4.3.0/crtbegin.o -Lc:/documents and settings/dan/my 
document
s/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0 -Lc:/documents 
and
settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/../lib/gcc -Lc:/docu
ments and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/../lib/gcc
/mingw32/4.3.0/../../../../mingw32/lib -Lc:/documents and settings/dan/my 
docume
nts/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../../.. 
ads\pdfl
ink.o 
pdflib.a -lgcj -lws2_32 -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lms
vcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingw
ex -lmsvcrt c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/
ming/bin/../lib/gcc/mingw32/4.3.0/crtend.o
c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/../
lib/gcc/mingw32/4.3.0/../../../libmingw32.a(main.o):main.c:(.text+0xbd): 
undefin
ed reference to `WinMain@16'
collect2: ld returned 1 exit status





==========================================================================
g++ -shared -v dlltest.o -lgcj -lws2_32 -o outputdll.dll
Using built-in specs.
Target: mingw32
Configured with: 
./gcc-4.3.0/configure --enable-languages=c,ada,c++,fortran,jav
a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl
e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab
le-concept-checks --enable-version-specific-runtime-libs --build=mingw32 --with-
bugurl=http://www.mingw.org/bugs.shtml --prefix=/mingw --with-gmp=/mingw/src/gcc
/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/
mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC)
COMPILER_PATH=c:/documents and settings/dan/my 
documents/programs/cygwin/home/da
n/ming/bin/../libexec/gcc/mingw32/4.3.0/;c:/documents and settings/dan/my 
docume
nts/programs/cygwin/home/dan/ming/bin/../libexec/gcc/;c:/documents and 
settings/
dan/my 
documents/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../.
/../../mingw32/bin/
LIBRARY_PATH=c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan
/ming/bin/../lib/gcc/mingw32/4.3.0/;c:/documents and settings/dan/my 
documents/p
rograms/cygwin/home/dan/ming/bin/../lib/gcc/;c:/documents and 
settings/dan/my do
cuments/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../../../../m
ingw32/lib/;c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/
ming/bin/../lib/gcc/mingw32/4.3.0/../../../
COLLECT_GCC_OPTIONS='-shared' '-v' '-o' 'outputdll.dll' '-mtune=i386'
 c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/..
/libexec/gcc/mingw32/4.3.0/collect2.exe --shared -Bdynamic -e 
_DllMainCRTStartup
@12 --enable-auto-image-base -o outputdll.dll c:/documents and 
settings/dan/my d
ocuments/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../../../dll
crt2.o c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/ming/
bin/../lib/gcc/mingw32/4.3.0/crtbegin.o -Lc:/documents and settings/dan/my 
docum
ents/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0 -Lc:/documents 
a
nd settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/../lib/gcc -Lc:/d
ocuments and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/../lib/
gcc/mingw32/4.3.0/../../../../mingw32/lib -Lc:/documents and settings/dan/my 
doc
uments/programs/cygwin/home/dan/ming/bin/../lib/gcc/mingw32/4.3.0/../../.. 
dllte
st.o -lgcj -lws2_32 -lstdc++ -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luse
r32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcr
t c:/documents and settings/dan/my 
documents/programs/cygwin/home/dan/ming/bin/.
/lib/gcc/mingw32/4.3.0/crtend.o

----- Original Message ----- 
From: "Andrew Haley" <aph@redhat.com>
To: "Daniel Walter" <d2walter@hotmail.com>
Cc: <java@gcc.gnu.org>
Sent: Tuesday, December 16, 2008 5:39 AM
Subject: Re: creating shared dlls yields undefined reference to `WinMain@16' 
in mingw 4.3


> Daniel Walter wrote:
>> Whenever I add an object file that was generated with gcj to a g++ link
>> command for a shared dll, I get an undefined reference to `WinMain@16'.
>> This seems to indicate that for some reason gcc wants to build an
>> executable instead of a shared library.  This was working in gcc 3.4 -
>> though I was using cygwin with gcj -mno-cygwin which is no longer
>> supported.
>>
>> Is building dlls with g++ and gcj supported in newer versions of gcc?
>> Is there a different link command that will not try to build an 
>> executable?
>>
>>
>> works> g++ -shared cpptest.o -o pdflib.dll
>>
>> works - event with lgcj> g++ -shared cpptest.o -lgcj -lws2_32 -o 
>> pdflib.dll
>>
>> fails - it tries to build an executable> g++ -shared javatest.o 
>> cpptest.o -lgcj -lws2_32 -o pdflib.dll
>
> More information needed.  'g++ -v' will show you what is being linked.
> There is presumably a way to ask what symbols are needed by the various
> libraries that you're linking, so have a look which one needs 
> `WinMain@16'.
>
> Andrew.
> 

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

[Andrew Haley]

Daniel Walter wrote:
> It appears that libmingw.a is causing the problem, though this library
> can be linked to form a dll as long as no gcj object files are linked as
> well. Below are the results of the attempts to link with 'g++ -v' first
> with gcj objects which failed and the second time with only g++ objects.

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

Andrew.

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

[Daniel Walter]

I tried adding -Wl,-y,_WinMain@16 so that I could find out where this 
reference was missing.  The result was main.o - this was also in the 
previous output.

I am not sure this is the best way to do things, but I did an objdump on my 
dlljava.o test file that produced some symbols.  I then tried to link 
without dlljava.o, but with -Wl,-u which forces the linker to resolve a 
symbol.  It failed as soon as I used symbols that were in libgcj.a - 
particularly java.lang.Object when I used the symbol 
__ZN4java4lang6Object6class$E.

I also tried making a WinMain and putting it in a C++ file.  This allowed it 
to link a dll, but this may be causing other problems and is not really my 
desired solution.

Daniel


----- Original Message ----- 
From: "Andrew Haley" <aph@redhat.com>
To: "Daniel Walter" <d2walter@hotmail.com>
Cc: <java@gcc.gnu.org>
Sent: Tuesday, December 16, 2008 12:29 PM
Subject: Re: creating shared dlls yields undefined reference to `WinMain@16' 
in mingw 4.3


> Daniel Walter wrote:
>> It appears that libmingw.a is causing the problem, though this library
>> can be linked to form a dll as long as no gcj object files are linked as
>> well. Below are the results of the attempts to link with 'g++ -v' first
>> with gcj objects which failed and the second time with only g++ objects.
>
> So, which object file in libmingw.a contains the undefined reference to
> `WinMain@16'  And what dependency is causing it to be pulled in?
>
> Andrew.
> 

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

[Andrew Haley]

Daniel Walter wrote:

> 
>> Daniel Walter wrote:
>>> It appears that libmingw.a is causing the problem, though this library
>>> can be linked to form a dll as long as no gcj object files are linked as
>>> well. Below are the results of the attempts to link with 'g++ -v' first
>>> with gcj objects which failed and the second time with only g++ objects.
>>
>> So, which object file in libmingw.a contains the undefined reference to
>> `WinMain@16'  And what dependency is causing it to be pulled in?

> I tried adding -Wl,-y,_WinMain@16 so that I could find out where this
> reference was missing.  The result was main.o - this was also in the
> previous output.

OK, so there's a file called main.o that for some reason is pulled in when
linking.  I have no idea; I think we need mingw32 experts.

Andrew.

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

[Daniel Walter]

Thank you for your help, I wasn't sure which group to go to first on this. 
I will try reporting this to MingW.

Daniel

----- Original Message ----- 
From: "Andrew Haley" <aph@redhat.com>
To: "Daniel Walter" <d2walter@hotmail.com>
Cc: <java@gcc.gnu.org>
Sent: Tuesday, December 16, 2008 3:26 PM
Subject: Re: creating shared dlls yields undefined reference to `WinMain@16' 
in mingw 4.3


> Daniel Walter wrote:
>
>>
>>> Daniel Walter wrote:
>>>> It appears that libmingw.a is causing the problem, though this library
>>>> can be linked to form a dll as long as no gcj object files are linked 
>>>> as
>>>> well. Below are the results of the attempts to link with 'g++ -v' first
>>>> with gcj objects which failed and the second time with only g++ 
>>>> objects.
>>>
>>> So, which object file in libmingw.a contains the undefined reference to
>>> `WinMain@16'  And what dependency is causing it to be pulled in?
>
>> I tried adding -Wl,-y,_WinMain@16 so that I could find out where this
>> reference was missing.  The result was main.o - this was also in the
>> previous output.
>
> OK, so there's a file called main.o that for some reason is pulled in when
> linking.  I have no idea; I think we need mingw32 experts.
>
> Andrew.
> 

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

[Danny Smith]

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  <rmathew@gcc.gnu.org>

	* 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

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

[Andrew Haley]

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.

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

[Daniel Walter]

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

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

[Andrew Haley]

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

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

[Daniel Walter]

Thank you for all the help on this. For anyone who is searching the archives 
for MinGW gcj information, I will summarize.

1. If you are trying to build a dll in MinGW, you may need to make a dummy 
WinMain function. This should not be exported outside of the dll. This will 
get you past the libgcj reference to main/WinMain for backtraces.

2. When statically linking with libgcj 
use -Wl,--whole-archive -lgcj -Wl,--no-whole-archive. Adding this forces the 
linker to link all of libgcj instead of just the parts that are referenced 
by your program. This is important because some parts of libgcj are loaded 
via reflexion rather than directly through symbolic references. Your program 
will start fine and crash later without this.

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

[Andrew Haley]

Daniel Walter wrote:
> Thank you for all the help on this. For anyone who is searching the
> archives for MinGW gcj information, I will summarize.
> 
> 1. If you are trying to build a dll in MinGW, you may need to make a
> dummy WinMain function. 

This is wrong, though.  Surely someone knows if Windows has something
like dlsym().

Andrew.

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

[BGB]

[first time forgot reply all]

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


> Daniel Walter wrote:
>> Thank you for all the help on this. For anyone who is searching the
>> archives for MinGW gcj information, I will summarize.
>>
>> 1. If you are trying to build a dll in MinGW, you may need to make a
>> dummy WinMain function.
>
> This is wrong, though.  Surely someone knows if Windows has something
> like dlsym().
>

yes, one thing worth looking into is Tool Help.

http://msdn.microsoft.com/en-us/library/ms686837(VS.85).aspx

as well as:

http://msdn.microsoft.com/en-us/library/ms683199(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms683212.aspx

it is up to the reader to figure out how to use all this (sadly, nowhere
near as simple to make work as dlsym).


apparently it is possible to make all this work, though granted I was not
aware of all this when I wrote my stuff, so I had ended up using a much more
"manual" set of approaches when implementing my symbol lookup (manually
loading and processing the binary...).


or such...


> Andrew.
> 

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

[Daniel Walter]

GetProcAddress can be used to find the address of a function if it is 
exported, though WinMain is generally not exported.  Windows processes are 
started with an entry point address that comes from the exe header, not from 
a symbol.  I tried searching an exe for WinMain with grep and then looked 
for symbols with dumpbin and didn't find anything.

I am not sure how it helps to have an address for WinMain though.  If I 
understand things properly, this is being used to backtrace the stack for 
exception information.  Unless I am wrong and there is compatibility between 
MS and GCC call stacks, this won't be able to trace back to WinMain anyway.

Daniel

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


> Daniel Walter wrote:
>> Thank you for all the help on this. For anyone who is searching the
>> archives for MinGW gcj information, I will summarize.
>>
>> 1. If you are trying to build a dll in MinGW, you may need to make a
>> dummy WinMain function.
>
> This is wrong, though.  Surely someone knows if Windows has something
> like dlsym().
>
> Andrew.
> 

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

[BGB]

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


> GetProcAddress can be used to find the address of a function if it is 
> exported, though WinMain is generally not exported.  Windows processes are 
> started with an entry point address that comes from the exe header, not 
> from a symbol.  I tried searching an exe for WinMain with grep and then 
> looked for symbols with dumpbin and didn't find anything.
>
> I am not sure how it helps to have an address for WinMain though.  If I 
> understand things properly, this is being used to backtrace the stack for 
> exception information.  Unless I am wrong and there is compatibility 
> between MS and GCC call stacks, this won't be able to trace back to 
> WinMain anyway.
>

many functions in the Win32 API, and GCC by default, use different calling 
conventions.

much of the Win32 API (including WinMain and callbacks) use STDCALL.

int WINAPI WinMain (
    HINSTANCE hInstance, HINSTANCE hPrevInstance,
    LPSTR lpCmdLine, int nCmdShow)

note the 'WINAPI', this is important.
WINAPI is a macro that usually expands to '__stdcall'.

however, by default GCC, and many other compilers, use cdecl.

in general, many things on windows use the stdcall calling convention, which 
differs from cdecl both in terms of how the stack is managed, and also how 
functions are names (stdcall uses a name mangling scheme, and so it is 
necessary to look for the mangled form of the name, not the raw symbol).

also, take note of another details:
nearly all symbols on Windows have an underscore prefix, but this is not the 
case on Linux.

so, the actual function name for WinMain will look more like this:
_WinMain @ 4
(spaces inserted to avoid OE stupidity...).


as for GetProcAddress, I think it is the case that, by default, it will only 
look up exported symbols.
however, using the 'Tool Help' functions, one can also look up non-exported 
functions as well.

here is a chunk of code from a project known as FoNC which illustrates the 
practice (MIT liscense I guess, the authors do such weirdness as putting 
bibliographies in source files, ...):

<--
#if defined(WIN32)
# include <tlhelp32.h>
struct dll
{
char *name;
dlhandle_t handle;
struct dll *next;
};
static struct dll *dlls= 0;
static int dlinitialised= 0;
static void dlinit(void);
dlhandle_t dlopen(const char *path, int mode)
{
dlhandle_t handle= 0;
if (!dlinitialised) dlinit();
{
unsigned int errormode= SetErrorMode(SEM_FAILCRITICALERRORS);
SetErrorMode(errormode | SEM_FAILCRITICALERRORS);
handle= GetModuleHandle(path);
if ((!handle) && path) handle= LoadLibrary(path);
SetErrorMode(errormode);
}
if (handle)
{
struct dll *dll= (struct dll *)malloc(sizeof(struct dll));
dll->handle= handle;
dll->next= dlls;
dlls= dll;
}
return handle;
}
static void dlinit(void)
{
HANDLE snapshot;
dlinitialised= 1;
if ((HANDLE)-1 != (snapshot= CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, 
getpid())))
{
MODULEENTRY32 me32;
me32.dwSize= sizeof(MODULEENTRY32);
if (Module32First(snapshot, &me32))
do
dlopen(me32.szModule, RTLD_NOW | RTLD_GLOBAL);
while (Module32Next(snapshot, &me32));
CloseHandle(snapshot);
}
}
void *dlsym(dlhandle_t handle, const char *symbol)
{
void *addr= 0;
struct dll *dll;
if (!dlinitialised) dlinit();
if (handle)
{
addr= GetProcAddress(handle, symbol);
dprintf("dlsym %p \"%s\" -> %p\n", handle, symbol, addr);
return addr;
}
if ((addr= GetProcAddress(GetModuleHandle(0), symbol)))
{
dprintf("dlsym <main> \"%s\" -> %p\n", symbol, addr);
return addr;
}
for (dll= dlls; dll; dll= dll->next)
if ((addr= GetProcAddress(dll->handle, symbol)))
{
dprintf("dlsym dll %p \"%s\" -> %p\n", dll->handle, symbol, addr);
return addr;
}
dprintf("dlsym 0 \"%s\" -> FAIL\n", symbol);
return 0;
}
int dlclose(dlhandle_t handle)
{
struct dll *dll, **dllp;
for (dllp= &dlls; (dll= *dllp); dllp= &dll->next)
if (dll->handle == handle)
{
*dllp= dll->next;
free(dll);
break;
}
FreeLibrary(handle);
return 0;
}
#endif
-->


but, alas, I have not tested any of this personally...


> Daniel
>
> ----- Original Message ----- 
> From: "Andrew Haley" <aph@redhat.com>
> To: "Daniel Walter" <d2walter@hotmail.com>
> Cc: "Danny Smith" <dansmister@gmail.com>; <java@gcc.gnu.org>
> Sent: Thursday, December 18, 2008 5:16 AM
> Subject: Re: creating shared dlls yields undefined reference to 
> `WinMain@16' in mingw 4.3
>
>
>> Daniel Walter wrote:
>>> Thank you for all the help on this. For anyone who is searching the
>>> archives for MinGW gcj information, I will summarize.
>>>
>>> 1. If you are trying to build a dll in MinGW, you may need to make a
>>> dummy WinMain function.
>>
>> This is wrong, though.  Surely someone knows if Windows has something
>> like dlsym().
>>
>> Andrew.
>>
>
> 

Re: 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...