Mingw build failed
Ranjit Mathew
rmathew@hotmail.com
Wed Jan 15 05:05:00 GMT 2003
Tom Tromey wrote:
> Ranjit> See this message (and its followups):
> Ranjit> http://gcc.gnu.org/ml/java/2002-12/msg00218.html
>> Is the patch here still valid? I don't know anything about Windows; I
> really rely on you and Adam to say what is correct.
At least the following is surely needed to compile GCJ for
MinGW if one is using the w32api-2.x packages for MinGW/Cygwin,
since "socklen_t" is defined only in ws2tcpip.h:
------------------------------------ 8< -------------------------------------
--- libjava/include/win32.h 2002年12月18日 23:28:14.000000000 +0530
+++ libjava/include/win32.h 2002年12月18日 23:31:33.000000000 +0530
@@ -15,6 +15,5 @@
#undef STRICT
-#undef __INSIDE_CYGWIN__
-#include <winsock.h>
+#include <ws2tcpip.h>
#define IP_TOS 3
#include <gcj/cni.h>
------------------------------------ 8< -------------------------------------
Adam was using the 1.1 packages at the time he did the port:
http://gcc.gnu.org/ml/java/2003-01/msg00093.html
Perhaps I should submit a patch for the same if Adam and
others approve of this change.
However, the networking code would still not build unless
the ECONNREFUSED related changes are done or unless we split
the networking code soon into separate POSIX and Win32
native code. The latter seems to be on the TODO list of
Michael.
> As to error reporting, I think we decided to make new nat*Win32.cc files
> for the networking code.
Yes, see above.
As an aside, I'm *still* not able to build GCJ from the
latest snapshots as I keep getting multiple definition
errors for methods like InetAddress.getAddress( ),
InetSocketAddress.getPort( ), Locale.getLanguage( ), etc.
during the final creation of libgcj.a.
The perplexing thing (for me) is that all of these are
defined inline as trivial "return foo;" type statements but
not all such methods show the error. Besides, the GCC
compiler that is produced from the build at least *seems
to* behave sanely w.r.t. inline functions so it should
be something else...
The other weird thing is that these methods are defined
in the same way in 3.2.1 but I never used to get any
such errors there...
:-(
I'll try to investigate this a bit more tonight.
Sincerely Yours,
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/
More information about the Java
mailing list