Mingw build failed

[Ranjit Mathew]

Tom Tromey wrote:
> Ranjit> At least the following is surely needed to compile GCJ for
> Ranjit> MinGW if one is using the w32api-2.x packages for MinGW/Cygwin,
> Ranjit> since "socklen_t" is defined only in ws2tcpip.h:
> 
> Ranjit> Adam was using the 1.1 packages at the time he did the port:
> 
> As far as I'm concerned it is up to the two of you to decide what
> version or versions of MinGW are supported.  I haven't replied to your
> patch on java-patches simply because I don't know what to do with it
> -- do we want to require the 2.x packages, do we want to try to
> support both somehow, ...?  You tell me.

w32api-2.x is a vast improvement over the 1.x versions. My vote
would be for 2.x support only. If for some reason, we wish to
support both versions, we need to have configury mechanisms
(like the one for "broken ld" for MinGW) to decide this.


> Ranjit> As an aside, I'm *still* not able to build GCJ from the
> Ranjit> latest snapshots as I keep getting multiple definition
> Ranjit> errors for methods like InetAddress.getAddress( ),
> Ranjit> InetSocketAddress.getPort( ), Locale.getLanguage( ), etc.
> Ranjit> during the final creation of libgcj.a.
> 
> If you mark these methods as `inline' does it help?
> You'll have to modify gcjh to do this and then rebuild libgcj from
> scratch.  Or if you can make a simple failing test case you can try it
> there...

Simply putting in "-O2" helped in actually inlining these functions and
I am now able to proceed. In the (mistaken) belief that removing
optimisation flags would result in a faster build time, I'd removed
that flag from my build scripts - that was the change from 3.2.1 that
caused this puzzling (for me) behaviour.


> That's just a workaround, though.  A solution would be to dig in to
> g++ and figure out what is going on.  Maybe we aren't allowed to have
> two definitions like this, even if one is "inline only".

GCC seems to emit functions defined in situ in class declarations
as separate functions even if I define them as "inline" - it does
however mark them ".linkonce .discard" and additionally on Linux
".weak" (as Jeff had pointed out) which prevents multiple
definition errors.

The -O2 flag is what actually causes GCC to inline these
functions.

How does gcjh know which functions to define inline from a class
file? I tried to write my own class with a trivial "return 0;"
method but it was not defined inline by the gcjh generated header.

If gcjh is really to define these inline in class headers, then
gcj should correspondingly define them ".linkonce .discard" as
well (and ".weak" on Linux maybe), IMO.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

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