Linker name conflicts due to optimization in gjavah

[Ranjit Mathew]

On 8/18/05, Danny Smith <dannysmith@clear.net.nz> wrote:
> > The backup (non-inlined) copy is emitted as a weak symbol and
> > should not normally cause linking errors. Perhaps the stock FSF
> > binutils' ld does not (yet) have proper support for weak symbols
> > on MinGW. See if this patch:
> >
> 
> Actually, it should be emitted as a link-once COMDAT symbol the way  C++ inlines
> are..

It probably is - I don't know for sure. I just took a "W" in nm's
output to mean a weak symbol, that's all.


> The PE_COFF link-once sematics are tried and true.  No need for latest binutils.
> 
> Weak definitions are not really supported  in PE-COFF.  Weak externals are
> supported.

I wonder what changed in 4.1. GCJ for MinGW used to build just 
fine in 3.4 and 4.0, IIRC, no?


> I wouldn't go down the pragma #interface/implementation road  Unless it is done
> carefully, it can really mes up dllimport/dllexport.
> 
> I would like to help more, but unfortunately I haven't been able to buiild
> libgcj natively on my humble windows box (XP. Athlon 2000, 512 MB phys mem)  for
> months.

Well, my home PC is even "humbler" (P3 750MHz, 512MB RAM) but
I manage to do a native bootstrap of C, C++ and Java in around 150-
160 minutes on Linux. If you have Linux, you can try the crossed-native
build approach as given in:

  http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html

Thanks,
Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/