[PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Aaron W. LaFramboise]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.

Autoimport is used in the final link of some of the tools.  This is OK 
for now, but suboptimal in the long run.  I'll address this later by 
adding the proper decorations.

This massively reduces the size of a full GCC installation on Windows. 
Most of the tools go from being about 44 MB to about 20 KB.

The DLL itself is pretty massive, weighing in at 70 MB (29 MB stripped), 
and a massive 82217 exports.  In the future, it might possible to 
improve this situation by linking by ordinal.

I tested this by a bootstrap on i386-pc-mingw32.

OK to commit?


[-- Attachment #2: gcc-4.4.0-20080823-libjava_s.patch --]
[-- Type: text/plain, Size: 3713 bytes --]

2008-08-23  Aaron W. LaFramboise  <aaronavay62@aaronwl.com>

	<libffi>
	* libffi/Makefile.am (LTLDFLAGS): Add -no-undefined.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerated.
	* libffi/testsuite/Makefile.in: Regenerated.

	<libjava>
	* configure.ac [mingw|cygwin] (extra_ldflags_libjava): Add -lws2_32.
	* Makefile.am (extra_cppflags_libjava): New.
	(AM_CPPFLAGS): Use extra_cppflags_libjava.
	* Makefile.in: Regenerated.
	* configure: Regenerated.
	* gcj/Makefile.in: Regenerated.
	* include/Makefile.in: Regenerated.
	* testsuite/Makefile.in: Regenerated.

	<libjava/libltdl>
	* ltdl.c (DLL_EXPORT): Rename to LIBLTDL_DLL_EXPORT.
	* ltdl.h (DLL_EXPORT): Rename to LIBLTDL_DLL_EXPORT.

Index: libffi/Makefile.am
===================================================================
--- libffi/Makefile.am	(revision 139510)
+++ libffi/Makefile.am	(working copy)
@@ -156,7 +156,8 @@ nodist_libffi_convenience_la_SOURCES = $
 
 AM_CFLAGS = -Wall -g -fexceptions
 
-LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
+LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \
+        -no-undefined
 
 libffi_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS)
 
Index: libjava/configure.ac
===================================================================
--- libjava/configure.ac	(revision 139510)
+++ libjava/configure.ac	(working copy)
@@ -811,6 +811,9 @@ arm*linux*eabi)
     LIBSTDCXXSPEC=-lstdc++
     LIBGCJTESTSPEC="-L`${PWDCMD-pwd}`/.libs -L`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -rpath `${PWDCMD-pwd}`/.libs:`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -lstdc++"
     ;;
+*-*-mingw*|*-*-cygwin)
+    extra_ldflags_libjava=-lws2_32
+    ;;
 esac
 AC_SUBST(extra_ldflags_libjava)
 AC_SUBST(extra_gij_ldflags)
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 139510)
+++ libjava/Makefile.am	(working copy)
@@ -123,7 +123,8 @@ GCJLINK = $(LIBTOOL) --tag=GCJ --mode=li
 GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
 GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
 LIBLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXX) -L$(here) $(JC1FLAGS) \
-          $(LDFLAGS) $(extra_ldflags_libjava) $(extra_ldflags) -o $@
+          $(LDFLAGS) $(extra_ldflags_libjava) $(extra_ldflags) -no-undefined \
+                    -o $@
 
 GCC_UNWIND_INCLUDE = @GCC_UNWIND_INCLUDE@
 
@@ -292,6 +293,7 @@ libgcj_tools_la_LDFLAGS = -rpath $(toole
  -version-info `grep -v '^\#' $(srcdir)/libtool-version` \
  $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS)
 libgcj_tools_la_DEPENDENCIES = libgcj.la libgcj.spec
+libgcj_tools_la_LIBADD = -L$(here)/.libs libgcj.la
 libgcj_tools_la_LINK = $(LIBLINK)
 
 ## libjvm.so
Index: libjava/libltdl/ltdl.c
===================================================================
--- libjava/libltdl/ltdl.c	(revision 139510)
+++ libjava/libltdl/ltdl.c	(working copy)
@@ -142,7 +142,7 @@ Foundation, Inc., 51 Franklin Street, Fi
 /* --- WINDOWS SUPPORT --- */
 
 
-#ifdef DLL_EXPORT
+#ifdef LIBLTDL_DLL_EXPORT
 #  define LT_GLOBAL_DATA	__declspec(dllexport)
 #else
 #  define LT_GLOBAL_DATA
Index: libjava/libltdl/ltdl.h
===================================================================
--- libjava/libltdl/ltdl.h	(revision 139510)
+++ libjava/libltdl/ltdl.h	(working copy)
@@ -128,7 +128,7 @@ LT_BEGIN_C_DECLS
    ridiculous implementation of data symbol exporting. */
 #ifndef LT_SCOPE
 #  ifdef __WINDOWS__
-#    ifdef DLL_EXPORT		/* defined by libtool (if required) */
+#    ifdef LIBLTDL_DLL_EXPORT		/* defined by libtool (if required) */
 #      define LT_SCOPE	__declspec(dllexport)
 #    endif
 #    ifdef LIBLTDL_DLL_IMPORT	/* define if linking with this dll */

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Danny Smith]

On Sun, Aug 24, 2008 at 1:44 PM, Aaron W. LaFramboise
<aaronavay62@aaronwl.com> wrote:
> This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.
>
> Autoimport is used in the final link of some of the tools.  This is OK for
> now, but suboptimal in the long run.  I'll address this later by adding the
> proper decorations.
>

There is problem in libffi/src/x86/win32.S  that may be hidden by auto-import.
Namely, the function labels is the asm src file are not being defined
as functions and so will be treated as data symbols when building a
dll.

This will fix	* src/x86/win32.S  (_ffi_prep_args): Prefix label with underscore.
	(_ffi_call_SYSV) :  Define as function.
	(_ffi_call_STDCALL) : Likewise.
	(_ffi_closure_SYSV): Likewise.
	(_ffi_raw_closure_SYSV): Likewise.

Index: win32.S
===================================================================
--- win32.S	(revision 139424)
+++ win32.S	(working copy)
@@ -32,11 +32,12 @@

 .text

-.globl ffi_prep_args
+.globl _ffi_prep_args

         # This assumes we are using gas.
         .balign 16
 .globl _ffi_call_SYSV
+	.def	_ffi_call_SYSV;	.scl	2;	.type	32;	.endef

 _ffi_call_SYSV:
         pushl %ebp
@@ -150,6 +151,7 @@
         # This assumes we are using gas.
         .balign 16
 .globl _ffi_call_STDCALL
+	.def	_ffi_call_STDCALL;	.scl	2;	.type	32;	.endef

 _ffi_call_STDCALL:
         pushl %ebp
@@ -259,6 +261,8 @@
 .ffi_call_STDCALL_end:

 	.globl _ffi_closure_SYSV
+	.def	_ffi_closure_SYSV;	.scl	2;	.type	32;	.endef
+
 _ffi_closure_SYSV:
 	pushl	%ebp
 	movl	%esp, %ebp
@@ -322,6 +326,7 @@

 	.balign	16
 	.globl _ffi_closure_raw_SYSV
+	.def	_ffi_closure_raw_SYSV;	.scl	2;	.type	32;	.endef
 _ffi_closure_raw_SYSV:
 	pushl	%ebp
 	movl	%esp, %ebp

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Andrew Haley]

Aaron W. LaFramboise wrote:
> This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.
> 
> Autoimport is used in the final link of some of the tools.  This is OK
> for now, but suboptimal in the long run.  I'll address this later by
> adding the proper decorations.
> 
> This massively reduces the size of a full GCC installation on Windows.
> Most of the tools go from being about 44 MB to about 20 KB.

Quite right too.

> The DLL itself is pretty massive, weighing in at 70 MB (29 MB stripped),
> and a massive 82217 exports.  In the future, it might possible to
> improve this situation by linking by ordinal.

Maybe you don't use libgcj.ver or some equivalent?  I have no idea
if you're even using GNU ld.

Andrew.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Aaron W. LaFramboise]

Andrew Haley wrote:
> Aaron W. LaFramboise wrote:
>> This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.

>> The DLL itself is pretty massive, weighing in at 70 MB (29 MB stripped),
>> and a massive 82217 exports.  In the future, it might possible to
>> improve this situation by linking by ordinal.
> 
> Maybe you don't use libgcj.ver or some equivalent?  I have no idea
> if you're even using GNU ld.

The Windows targets use GNU binutils as and ld.

However, version scripts only seem to be supported for ELF targets; 
Windows uses the PE variant of COFF.

The equivalent mechanism on Windows is the 'DEF' file, which 
unfortunately is not as expressive as version scripts, but it does have 
a few features version scripts don't, such as by-ordinal linking. 
Unfortunately DEF files do not support wild-card patterns either.

Actually, at present, this is not so much worse than on Linux ELF, which 
exports 65662 dynamic symbols from libgcj.so.10.0.0.

I will figure out what is necessary to generate a DEF file properly 
sometime soon, but in the meantime I think this can go in.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

Aaron W. LaFramboise wrote:
> This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.

  This patch revises and updates Aaron's old patch from last August.  It adds
some essential support for Cygwin that the previous patch didn't have, and
does things slightly differently in places.

  There's only one substantial addition: I added a mechanism in libffi's build
system to allow the override of $toolexeclibdir.  We use this on Cygwin to
install the newly built libffi into the GCC private directory alongside cc1 et
al., as we may have a different upstream version of libffi-devel installed in
/usr/lib and /usr/include.

  I'm just putting this through a bootstrap at the moment.  There's not going
to be much to test because none of this used to be built on Cygwin at all
before, so it can hardly regress.  If it bootstraps and builds nice working
DLLs, OK for HEAD?

ChangeLog:

	* configure.ac (Cygwin noconfigdirs):  Remove libgcj.
	* configure:  Regenerate.

boehm-gc/ChangeLog:

	* win32_threads.c (get_thread_stack_base):  Add missing function
	definition for Cygwin.

gcc/ChangeLog

	* config/i386/t-cygming (jc1):  Add -Wl,-stack to LDFLAGS.

libffi/ChangeLog

	* configure.ac (toolexeclibdir):  Allow host-specific override
	if defined in host__toolexeclibdir.
	* configure.host (Cygwin host__toolexeclibdir):  Define.
	* Makefile.am (gcc_version):  New makefile variable.
	(toollibffidir):  Likewise.
	(LTLDFLAGS):  Add "-no-undefined".
	* configure:  Regenerate.
	* Makefile.in:  Regenerate.

	* src/x86/win32.S (ffi_prep_args):  Rename from this ...
	(_ffi_prep_args):  ... to this.
	(_ffi_call_SYSV, _ffi_call_STDCALL, _ffi_closure_SYSV,
	_ffi_closure_raw_SYSV):  Add missing symbol function type attributes.

libjava/ChangeLog

	* configure.ac (Cygwin|MinGW extra_ldflags_libjava):  Add ws2_32 lib.
	* Makefile.am (LIBLINK):  Add "-no-undefined".
	(libgij_la_LDFLAGS, libjvm_la_LDFLAGS):  Likewise.
	(libgcj_tools_la_LIBADD):  Link against new libgcj.la.
	* Makefile.in:  Regenerate.

	* sysdep/i386/backtrace.h (MAIN_FUNC):  New define.
	(fallback_backtrace):  Use it.

libjava/libltdl/ChangeLog

	* ldtl.c (DLL_EXPORT):  Rename from this ...
	(LIBLTDL_DLL_EXPORT):  ... to this.
	* ldtl.c (DLL_EXPORT, LIBLTDL_DLL_EXPORT):  Change use.


    cheers,
      DaveK

[-- Attachment #2: cygming-gcj-ffi-patch-updated.diff --]
[-- Type: text/x-c, Size: 10718 bytes --]


ChangeLog:

	* configure.ac (Cygwin noconfigdirs):  Remove libgcj.
	* configure:  Regenerate.

boehm-gc/ChangeLog:

	* win32_threads.c (get_thread_stack_base):  Add missing function 
	definition for Cygwin.

gcc/ChangeLog

	* config/i386/t-cygming (jc1):  Add -Wl,-stack to LDFLAGS.

libffi/ChangeLog

	* configure.ac (toolexeclibdir):  Allow host-specific override
	if defined in host__toolexeclibdir.
	* configure.host (Cygwin host__toolexeclibdir):  Define.
	* Makefile.am (gcc_version):  New makefile variable.
	(toollibffidir):  Likewise.
	(LTLDFLAGS):  Add "-no-undefined".
	* configure:  Regenerate.
	* Makefile.in:  Regenerate.

	* src/x86/win32.S (ffi_prep_args):  Rename from this ...
	(_ffi_prep_args):  ... to this.
	(_ffi_call_SYSV, _ffi_call_STDCALL, _ffi_closure_SYSV,
	_ffi_closure_raw_SYSV):  Add missing symbol function type attributes.

libjava/ChangeLog

	* configure.ac (Cygwin|MinGW extra_ldflags_libjava):  Add ws2_32 lib.
	* Makefile.am (LIBLINK):  Add "-no-undefined".
	(libgij_la_LDFLAGS, libjvm_la_LDFLAGS):  Likewise.
	(libgcj_tools_la_LIBADD):  Link against new libgcj.la.
	* Makefile.in:  Regenerate.

	* sysdep/i386/backtrace.h (MAIN_FUNC):  New define.
	(fallback_backtrace):  Use it.

libjava/libltdl/ChangeLog

	* ldtl.c (DLL_EXPORT):  Rename from this ...
	(LIBLTDL_DLL_EXPORT):  ... to this.
	* ldtl.c (DLL_EXPORT, LIBLTDL_DLL_EXPORT):  Change use.

==============================================================================

Index: gcc/config/i386/t-cygming
===================================================================
--- gcc/config/i386/t-cygming	(revision 145828)
+++ gcc/config/i386/t-cygming	(working copy)
@@ -37,6 +37,13 @@ msformat-c.o: $(srcdir)/config/i386/msformat-c.c $
 
 STMP_FIXINC=stmp-fixinc
 
+# Building and linking gcj, gcj-tools stretches a 32-bit Windows
+# system to its limits, and the default per-thread stack allocation
+# is way too low.  Add a target-specific make variable definition
+# to extend LDFLAGS so that the compiler is built with header fields
+# set to make the runtime loader give it a big stack allocation.
+jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
+
 # Build a shared libgcc library for PECOFF with a DEF file
 # with the GNU linker.
 #
Index: configure.ac
===================================================================
--- configure.ac	(revision 145828)
+++ configure.ac	(working copy)
@@ -727,7 +727,7 @@ case "${target}" in
     ;;    
   *-*-cygwin*)
     target_configdirs="$target_configdirs target-libtermcap target-winsup"
-    noconfigdirs="$noconfigdirs target-gperf target-libgloss ${libgcj}"
+    noconfigdirs="$noconfigdirs target-gperf target-libgloss"
     # always build newlib if winsup directory is present.
     if test -d "$srcdir/winsup/cygwin"; then
       skipdirs=`echo " ${skipdirs} " | sed -e 's/ target-newlib / /'`
Index: boehm-gc/win32_threads.c
===================================================================
--- boehm-gc/win32_threads.c	(revision 145828)
+++ boehm-gc/win32_threads.c	(working copy)
@@ -753,6 +753,12 @@ int GC_pthread_detach(pthread_t thread)
     return result;
 }
 
+GC_PTR GC_get_thread_stack_base()
+{
+  extern GC_PTR _tlsbase __asm__ ("%fs:4");
+  return _tlsbase;
+}
+
 #else /* !CYGWIN32 */
 
 /*
Index: libffi/src/x86/win32.S
===================================================================
--- libffi/src/x86/win32.S	(revision 145828)
+++ libffi/src/x86/win32.S	(working copy)
@@ -32,11 +32,12 @@
  
 .text
  
-.globl ffi_prep_args
+.globl _ffi_prep_args
  
         # This assumes we are using gas.
         .balign 16
 .globl _ffi_call_SYSV
+	.def	_ffi_call_SYSV;	.scl	2;	.type	32;	.endef
  
 _ffi_call_SYSV:
         pushl %ebp
@@ -152,6 +153,7 @@ epilogue:
 .globl _ffi_call_STDCALL
 
 _ffi_call_STDCALL:
+	.def	_ffi_call_STDCALL;	.scl	2;	.type	32;	.endef
         pushl %ebp
         movl  %esp,%ebp
 
@@ -259,6 +261,7 @@ sc_epilogue:
 .ffi_call_STDCALL_end:
 
 	.globl _ffi_closure_SYSV
+	.def	_ffi_closure_SYSV;	.scl	2;	.type	32;	.endef
 _ffi_closure_SYSV:
 	pushl	%ebp
 	movl	%esp, %ebp
@@ -322,6 +325,7 @@ _ffi_closure_SYSV:
 
 	.balign	16
 	.globl _ffi_closure_raw_SYSV
+	.def	_ffi_closure_raw_SYSV;	.scl	2;	.type	32;	.endef
 _ffi_closure_raw_SYSV:
 	pushl	%ebp
 	movl	%esp, %ebp
Index: libffi/configure.host
===================================================================
--- libffi/configure.host	(revision 145828)
+++ libffi/configure.host	(working copy)
@@ -8,4 +8,8 @@ case "${host}" in
   frv*-elf)
     LDFLAGS=`echo $LDFLAGS | sed "s/\-B[^ ]*libgloss\/frv\///"`\ -B`pwd`/../libgloss/frv/
     ;;
+  i?86-*-cygwin*)
+    # Redirect installation to gcc private dir.
+    host__toolexeclibdir='$(toollibffidir)'
+    ;;
 esac
Index: libffi/configure.ac
===================================================================
--- libffi/configure.ac	(revision 145828)
+++ libffi/configure.ac	(working copy)
@@ -344,6 +344,7 @@ if test -n "$with_cross_host" &&
    test x"$with_cross_host" != x"no"; then
   toolexecdir='$(exec_prefix)/$(target_alias)'
   toolexeclibdir='$(toolexecdir)/lib'
+  test "${host__toolexeclibdir+set}" = set && toolexeclibdir=${host__toolexeclibdir}
 else
   toolexecdir='$(libdir)/gcc-lib/$(target_alias)'
   toolexeclibdir='$(libdir)'
Index: libffi/Makefile.am
===================================================================
--- libffi/Makefile.am	(revision 145828)
+++ libffi/Makefile.am	(working copy)
@@ -31,6 +31,10 @@ EXTRA_DIST = LICENSE ChangeLog.v1 ChangeLog.libgcj
 	src/pa/ffitarget.h src/pa/ffi.c src/pa/linux.S src/pa/hpux32.S \
 	src/frv/ffi.c src/frv/eabi.S src/frv/ffitarget.h
 
+# Where generated headers like ffitarget.h get installed.
+gcc_version   = $(shell cat $(top_srcdir)/../gcc/BASE-VER)
+toollibffidir = $(libdir)/gcc/$(target_alias)/$(gcc_version)
+
 ## ################################################################
 
 ##
@@ -156,7 +160,8 @@ nodist_libffi_convenience_la_SOURCES = $(nodist_li
 
 AM_CFLAGS = -Wall -g -fexceptions
 
-LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
+LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \
+        -no-undefined
 
 libffi_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS)
 
Index: libjava/libltdl/ltdl.c
===================================================================
--- libjava/libltdl/ltdl.c	(revision 145828)
+++ libjava/libltdl/ltdl.c	(working copy)
@@ -142,7 +142,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor,
 /* --- WINDOWS SUPPORT --- */
 
 
-#ifdef DLL_EXPORT
+#ifdef LIBLTDL_DLL_EXPORT
 #  define LT_GLOBAL_DATA	__declspec(dllexport)
 #else
 #  define LT_GLOBAL_DATA
Index: libjava/libltdl/ltdl.h
===================================================================
--- libjava/libltdl/ltdl.h	(revision 145828)
+++ libjava/libltdl/ltdl.h	(working copy)
@@ -128,7 +128,7 @@ LT_BEGIN_C_DECLS
    ridiculous implementation of data symbol exporting. */
 #ifndef LT_SCOPE
 #  ifdef __WINDOWS__
-#    ifdef DLL_EXPORT		/* defined by libtool (if required) */
+#    ifdef LIBLTDL_DLL_EXPORT	/* don't define or ld disables auto-export. */
 #      define LT_SCOPE	__declspec(dllexport)
 #    endif
 #    ifdef LIBLTDL_DLL_IMPORT	/* define if linking with this dll */
Index: libjava/configure.ac
===================================================================
--- libjava/configure.ac	(revision 145828)
+++ libjava/configure.ac	(working copy)
@@ -885,6 +885,9 @@ arm*linux*eabi)
     LIBSTDCXXSPEC=-lstdc++
     LIBGCJTESTSPEC="-L`${PWDCMD-pwd}`/.libs -L`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -rpath `${PWDCMD-pwd}`/.libs:`${PWDCMD-pwd}`/../libstdc++-v3/src/.libs -lstdc++"
     ;;
+*-*-mingw*|*-*-cygwin)
+    extra_ldflags_libjava=-lws2_32
+    ;;
 esac
 AC_SUBST(extra_ldflags_libjava)
 AC_SUBST(extra_gij_ldflags)
Index: libjava/sysdep/i386/backtrace.h
===================================================================
--- libjava/sysdep/i386/backtrace.h	(revision 145828)
+++ libjava/sysdep/i386/backtrace.h	(working copy)
@@ -13,7 +13,14 @@ details.  */
 
 #include <java-stack.h>
 
-extern int main (int, char **);
+#ifdef __CYGWIN__
+/* To allow this to link as a DLL.  */
+#define MAIN_FUNC dll_crt0__FP11per_process
+extern "C" int MAIN_FUNC () __declspec(dllimport);
+#else /* !__CYGWIN__ */
+#define MAIN_FUNC main
+extern int MAIN_FUNC (int, char **);
+#endif /* ?__CYGWIN__ */
 
 /* The context used to keep track of our position while unwinding through
    the call stack.  */
@@ -104,7 +111,7 @@ fallback_backtrace (_Unwind_Trace_Fn trace_fn, _Jv
                             const char **, bool))_Jv_RunMain;
       if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
           || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
-          || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
+          || (ctx.meth_addr - (_Jv_uintptr_t)MAIN_FUNC) < 16)
         break;
     }
 
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 145828)
+++ libjava/Makefile.am	(working copy)
@@ -134,7 +134,8 @@ GCJLINK = $(LIBTOOL) --tag=GCJ --mode=link $(GCJ)
 GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
 GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
 LIBLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXX) -L$(here) $(JC1FLAGS) \
-          $(LTLDFLAGS) $(extra_ldflags_libjava) $(extra_ldflags) -o $@
+          $(LTLDFLAGS) $(extra_ldflags_libjava) $(extra_ldflags) -no-undefined \
+          -o $@
 CXXLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXXLD) $(AM_CXXFLAGS) \
 	$(CXXFLAGS) $(AM_LDFLAGS) $(LTLDFLAGS) -o $@
 
@@ -221,7 +222,7 @@ libgij_la_DEPENDENCIES = libgcj.la libgcj.spec
 ## See jv_convert_LDADD.
 libgij_la_LIBADD = -L$(here)/.libs libgcj.la
 ## The mysterious backslash in the grep pattern is consumed by make.
-libgij_la_LDFLAGS = -rpath $(toolexeclibdir) \
+libgij_la_LDFLAGS = -rpath $(toolexeclibdir) -no-undefined \
         -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LIBGCJ_LD_SYMBOLIC)
 
 if INTERPRETER
@@ -311,6 +312,7 @@ libgcj_tools_la_LDFLAGS = -rpath $(toolexeclibdir)
  -version-info `grep -v '^\#' $(srcdir)/libtool-version` \
  $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS)
 libgcj_tools_la_DEPENDENCIES = libgcj.la libgcj.spec
+libgcj_tools_la_LIBADD = -L$(here)/.libs libgcj.la
 libgcj_tools_la_LINK = $(LIBLINK)
 
 ## libjvm.so
@@ -318,7 +320,7 @@ libjvm_la_SOURCES = jni-libjvm.cc
 libjvm_la_DEPENDENCIES = libgcj.la libgcj.spec
 ## See jv_convert_LDADD.
 libjvm_la_LIBADD = -L$(here)/.libs libgcj.la
-libjvm_la_LDFLAGS = -avoid-version $(LIBGCJ_LD_SYMBOLIC)
+libjvm_la_LDFLAGS = -avoid-version $(LIBGCJ_LD_SYMBOLIC) -no-undefined
 
 ## The .db file.  This rule is only used for native builds, so it is
 ## safe to invoke gcj-dbtool.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Andrew Haley]

Dave Korn wrote:
> Aaron W. LaFramboise wrote:
>> This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.
> 
>   This patch revises and updates Aaron's old patch from last August.  It adds
> some essential support for Cygwin that the previous patch didn't have, and
> does things slightly differently in places.
> 
>   There's only one substantial addition: I added a mechanism in libffi's build
> system to allow the override of $toolexeclibdir.  We use this on Cygwin to
> install the newly built libffi into the GCC private directory alongside cc1 et
> al., as we may have a different upstream version of libffi-devel installed in
> /usr/lib and /usr/include.
> 
>   I'm just putting this through a bootstrap at the moment.  There's not going
> to be much to test because none of this used to be built on Cygwin at all
> before, so it can hardly regress.  If it bootstraps and builds nice working
> DLLs, OK for HEAD?

I'm going to ask for libgcj test results: we need to know if it's fit for
use.

Andrew.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Dave Korn]

Andrew Haley wrote:

>>   I'm just putting this through a bootstrap at the moment.  There's not going
>> to be much to test because none of this used to be built on Cygwin at all
>> before, so it can hardly regress.  If it bootstraps and builds nice working
>> DLLs, OK for HEAD?
> 
> I'm going to ask for libgcj test results: we need to know if it's fit for
> use.

  Certainly.  Will be many many hours before my bootstrap get to them, but
I'll report back.  As a guideline to what to expect, I get these results on
4.3.2 using a similar patch; maybe you could let me know if you see any
patterns in there that would indicate fundamental brokenness.



		=== libjava tests ===


Running target unix
FAIL: TestClosureGC run
FAIL:
/gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.3/libjava/testsuite/libjava.jar/TestClosureGC.jar
execution - gij test
FAIL:
/gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.3/libjava/testsuite/libjava.jar/simple.jar
execution - gij test
FAIL: PR15133 run
FAIL: PR18116 run
FAIL: PR28178 run
FAIL: bytebuffer run
FAIL: calls run
FAIL: cxxtest run
FAIL: directbuffer run
FAIL: field run
FAIL: final_method run
FAIL: findclass run
FAIL: findclass2 run
FAIL: iface run
FAIL: init run
FAIL: invoke run
FAIL: jniutf run
FAIL: martin run
FAIL: noclass run
FAIL: overload run
FAIL: pr11951 run
FAIL: pr18278 run
FAIL: pr23739 run
FAIL: register run
FAIL: register2 run
FAIL: simple_int run
FAIL: throwit run
FAIL: virtual run
FAIL: PR16923 run
FAIL: pr29812 execution - gij test
FAIL: getargssize run
FAIL: getlocalvartable run
FAIL: getstacktrace run
FAIL: ArrayStore execution - source compiled test
FAIL: ArrayStore -findirect-dispatch execution - source compiled test
FAIL: ArrayStore -O3 execution - source compiled test
FAIL: ArrayStore -O3 -findirect-dispatch execution - source compiled test
FAIL: ArrayStore2 execution - source compiled test
FAIL: ArrayStore2 -findirect-dispatch execution - source compiled test
FAIL: ArrayStore2 -O3 execution - source compiled test
FAIL: ArrayStore2 -O3 -findirect-dispatch execution - source compiled test
FAIL: Array_3 execution - source compiled test
FAIL: Array_3 -findirect-dispatch execution - source compiled test
FAIL: Array_3 -O3 execution - source compiled test
FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test
FAIL: Divide_1 execution - source compiled test
FAIL: Divide_1 -findirect-dispatch execution - source compiled test
FAIL: Divide_1 -O3 execution - source compiled test
FAIL: Divide_1 -O3 -findirect-dispatch execution - source compiled test
FAIL: Divide_2 execution - source compiled test
FAIL: Divide_2 -findirect-dispatch execution - source compiled test
FAIL: Divide_2 -O3 execution - source compiled test
FAIL: Divide_2 -O3 -findirect-dispatch execution - source compiled test
FAIL: ExtraClassLoader execution - source compiled test
FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
FAIL: ExtraClassLoader -O3 execution - source compiled test
FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test
FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test
FAIL: Final execution - source compiled test
FAIL: Final -findirect-dispatch execution - source compiled test
FAIL: Final -O3 execution - source compiled test
FAIL: Final -O3 -findirect-dispatch execution - source compiled test
FAIL: G19990302_02 execution - source compiled test
FAIL: G19990302_02 -findirect-dispatch execution - source compiled test
FAIL: G19990302_02 -O3 execution - source compiled test
FAIL: G19990302_02 -O3 -findirect-dispatch execution - source compiled test
FAIL: G19990303_01 execution - source compiled test
FAIL: G19990303_01 -findirect-dispatch execution - source compiled test
FAIL: G19990303_01 -O3 execution - source compiled test
FAIL: G19990303_01 -O3 -findirect-dispatch execution - source compiled test
FAIL: G19990303_02 execution - source compiled test
FAIL: G19990303_02 -findirect-dispatch execution - source compiled test
FAIL: G19990303_02 -O3 execution - source compiled test
FAIL: G19990303_02 -O3 -findirect-dispatch execution - source compiled test
FAIL: G19990304_01 execution - source compiled test
FAIL: G19990304_01 -findirect-dispatch execution - source compiled test
FAIL: G19990304_01 -O3 execution - source compiled test
FAIL: G19990304_01 -O3 -findirect-dispatch execution - source compiled test
FAIL: InterfaceDispatch execution - source compiled test
FAIL: InterfaceDispatch -findirect-dispatch execution - source compiled test
FAIL: InterfaceDispatch -O3 execution - source compiled test
FAIL: InterfaceDispatch -O3 -findirect-dispatch execution - source compiled test
FAIL: Invoke_1 execution - source compiled test
FAIL: Invoke_1 -findirect-dispatch execution - source compiled test
FAIL: Invoke_1 -O3 execution - source compiled test
FAIL: Invoke_1 -O3 -findirect-dispatch execution - source compiled test
FAIL: PR12416 execution - source compiled test
FAIL: PR12416 -O3 execution - source compiled test
FAIL: PR218 execution - source compiled test
FAIL: PR218 -findirect-dispatch execution - source compiled test
FAIL: PR218 -O3 execution - source compiled test
FAIL: PR218 -O3 -findirect-dispatch execution - source compiled test
FAIL: PR26858 execution - source compiled test
FAIL: PR26858 -findirect-dispatch execution - source compiled test
FAIL: PR26858 -O3 execution - source compiled test
FAIL: PR26858 -O3 -findirect-dispatch execution - source compiled test
FAIL: PR36252 execution - source compiled test
FAIL: PR36252 -findirect-dispatch execution - source compiled test
FAIL: PR36252 -O3 execution - source compiled test
FAIL: PR36252 -O3 -findirect-dispatch execution - source compiled test
FAIL: Process_2 output - source compiled test
WARNING: program timed out.
FAIL: Process_2 -findirect-dispatch execution - source compiled test
FAIL: Process_2 -O3 compilation from source
FAIL: Process_2 -O3 -findirect-dispatch output - source compiled test
FAIL: Process_3 output - source compiled test
FAIL: Process_3 -findirect-dispatch output - source compiled test
FAIL: Process_3 -O3 output - source compiled test
FAIL: Process_3 -O3 -findirect-dispatch output - source compiled test
FAIL: Process_4 output - source compiled test
FAIL: Process_4 -O3 -findirect-dispatch output - source compiled test
FAIL: Process_5 execution - source compiled test
FAIL: Process_5 -findirect-dispatch execution - source compiled test
FAIL: Process_5 -O3 execution - source compiled test
FAIL: Process_5 -O3 -findirect-dispatch execution - source compiled test
FAIL: Process_6 execution - source compiled test
FAIL: Process_6 -findirect-dispatch execution - source compiled test
FAIL: Process_6 -O3 execution - source compiled test
FAIL: Process_6 -O3 -findirect-dispatch execution - source compiled test
FAIL: Process_7 output - source compiled test
FAIL: Process_7 -findirect-dispatch output - source compiled test
FAIL: Process_7 -O3 output - source compiled test
FAIL: Process_7 -O3 -findirect-dispatch output - source compiled test
FAIL: ProxyTest execution - source compiled test
FAIL: ProxyTest -O3 execution - source compiled test
FAIL: StackTrace2 execution - source compiled test
FAIL: StackTrace2 -findirect-dispatch execution - source compiled test
FAIL: StackTrace2 -O3 execution - source compiled test
FAIL: StackTrace2 -O3 -findirect-dispatch execution - source compiled test
FAIL: StringBuffer_1 execution - source compiled test
FAIL: StringBuffer_1 -findirect-dispatch execution - source compiled test
FAIL: StringBuffer_1 -O3 execution - source compiled test
FAIL: StringBuffer_1 -O3 -findirect-dispatch execution - source compiled test
FAIL: StringBuffer_overflow execution - source compiled test
FAIL: StringBuffer_overflow -findirect-dispatch execution - source compiled test
FAIL: StringBuffer_overflow -O3 execution - source compiled test
FAIL: StringBuffer_overflow -O3 -findirect-dispatch execution - source
compiled test
FAIL: String_overflow execution - source compiled test
FAIL: String_overflow -findirect-dispatch execution - source compiled test
FAIL: String_overflow -O3 execution - source compiled test
FAIL: String_overflow -O3 -findirect-dispatch execution - source compiled test
FAIL: Thread_Alive execution - source compiled test
FAIL: Thread_Alive -findirect-dispatch execution - source compiled test
FAIL: Thread_Alive -O3 execution - source compiled test
FAIL: Thread_Alive -O3 -findirect-dispatch execution - source compiled test
FAIL: Thread_Interrupt execution - source compiled test
FAIL: Thread_Interrupt -findirect-dispatch execution - source compiled test
FAIL: Thread_Interrupt -O3 execution - source compiled test
FAIL: Thread_Interrupt -O3 -findirect-dispatch execution - source compiled test
FAIL: Thread_Wait_2 execution - source compiled test
FAIL: Thread_Wait_2 -findirect-dispatch execution - source compiled test
FAIL: Thread_Wait_2 -O3 execution - source compiled test
FAIL: Thread_Wait_2 -O3 -findirect-dispatch execution - source compiled test
FAIL: Thread_Wait_Interrupt execution - source compiled test
FAIL: Thread_Wait_Interrupt -findirect-dispatch execution - source compiled test
FAIL: Thread_Wait_Interrupt -O3 execution - source compiled test
FAIL: Thread_Wait_Interrupt -O3 -findirect-dispatch execution - source
compiled test
FAIL: Throw_1 execution - source compiled test
FAIL: Throw_1 -findirect-dispatch execution - source compiled test
FAIL: Throw_1 -O3 execution - source compiled test
FAIL: Throw_1 -O3 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test
FAIL: Throw_3 execution - source compiled test
FAIL: Throw_3 -findirect-dispatch execution - source compiled test
FAIL: Throw_3 -O3 execution - source compiled test
FAIL: Throw_3 -O3 -findirect-dispatch execution - source compiled test
FAIL: WalkerTest execution - source compiled test
FAIL: WalkerTest -O3 execution - source compiled test
FAIL: assign2 execution - source compiled test
FAIL: assign2 -findirect-dispatch execution - source compiled test
FAIL: assign2 -O3 execution - source compiled test
FAIL: assign2 -O3 -findirect-dispatch execution - source compiled test
FAIL: initexc execution - source compiled test
FAIL: initexc -findirect-dispatch execution - source compiled test
FAIL: initexc -O3 execution - source compiled test
FAIL: initexc -O3 -findirect-dispatch execution - source compiled test
FAIL: instinit2 execution - source compiled test
FAIL: instinit2 -findirect-dispatch execution - source compiled test
FAIL: instinit2 -O3 execution - source compiled test
FAIL: instinit2 -O3 -findirect-dispatch execution - source compiled test
FAIL: invokethrow execution - source compiled test
FAIL: invokethrow -findirect-dispatch execution - source compiled test
FAIL: invokethrow -O3 execution - source compiled test
FAIL: invokethrow -O3 -findirect-dispatch execution - source compiled test
FAIL: newarray_overflow execution - source compiled test
FAIL: newarray_overflow -findirect-dispatch execution - source compiled test
FAIL: newarray_overflow -O3 execution - source compiled test
FAIL: newarray_overflow -O3 -findirect-dispatch execution - source compiled test
FAIL: pr184 execution - source compiled test
FAIL: pr184 -findirect-dispatch execution - source compiled test
FAIL: pr184 -O3 execution - source compiled test
FAIL: pr184 -O3 -findirect-dispatch execution - source compiled test
FAIL: pr21785 execution - source compiled test
FAIL: pr21785 -O3 execution - source compiled test
FAIL: pr83 execution - source compiled test
FAIL: pr83 -findirect-dispatch execution - source compiled test
FAIL: pr83 -O3 execution - source compiled test
FAIL: pr83 -O3 -findirect-dispatch execution - source compiled test
FAIL: stacktrace execution - source compiled test
FAIL: stacktrace -findirect-dispatch execution - source compiled test
FAIL: stacktrace -O3 execution - source compiled test
FAIL: stacktrace -O3 -findirect-dispatch execution - source compiled test

		=== libjava Summary ===

# of expected passes		2142
# of unexpected failures	205
# of untested testcases		194



		=== libffi tests ===


Running target unix
FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
FAIL: libffi.call/return_sc.c execution test
FAIL: libffi.call/struct5.c execution test
FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
FAIL: libffi.call/return_sc.c execution test
FAIL: libffi.call/struct5.c execution test
FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
FAIL: libffi.call/return_sc.c execution test
FAIL: libffi.call/struct5.c execution test
FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
FAIL: libffi.call/struct5.c execution test
FAIL: libffi.call/cls_12byte.c output pattern test, is 7 4 9 1 5 3: 8 9 12
FAIL: libffi.call/cls_16byte.c output pattern test, is 7 8 9 1 9 3: 8 17 12
FAIL: libffi.call/cls_18byte.c output pattern test, is 1 127 126 3 4 125 124
5: 5 252 250 8
FAIL: libffi.call/cls_19byte.c output pattern test, is 1 127 126 3 120 4 125
124 5 119: 5 252 250 8 239
FAIL: libffi.call/cls_1_1byte.c output pattern test, is 12 178: 190
FAIL: libffi.call/cls_20byte.c output pattern test, is 1 2 3 4 5 7: 5 7 10
FAIL: libffi.call/cls_20byte1.c output pattern test, is 1 2 3 4 5 7: 5 7 10
FAIL: libffi.call/cls_24byte.c output pattern test, is 9 2 6 5 1 2 3 7 4 5 7 9
8 6 1 9: 22 15 17 25
FAIL: libffi.call/cls_2byte.c output pattern test, is 12 127 1 13: 13 140
FAIL: libffi.call/cls_3_1byte.c output pattern test, is 12 13 14 178 179 180:
190 192 194
FAIL: libffi.call/cls_5_1_byte.c output pattern test, is 127 120 1 3 4 12 128
9 3 4: 139 248 10 6 8
FAIL: libffi.call/cls_5byte.c output pattern test, is 127 120 1 12 128 9: 139
248 10
FAIL: libffi.call/cls_64byte.c output pattern test, is 22 15 17 25 6 13 19 18
FAIL: libffi.call/cls_6_1_byte.c output pattern test, is 127 120 1 3 4 5 12
128 9 3 4 5: 139 248 10 6 8 10
FAIL: libffi.call/cls_6byte.c output pattern test, is 127 120 1 128 12 128 9
127: 139 248 10 255
FAIL: libffi.call/cls_7_1_byte.c output pattern test, is 127 120 1 3 4 5 6 12
128 9 3 4 5 6: 139 248 10 6 8 10 12
FAIL: libffi.call/cls_9byte1.c output pattern test, is 7 8 1 9: 8 17
FAIL: libffi.call/cls_9byte2.c output pattern test, is 7 8 1 9: 8 17
FAIL: libffi.call/cls_align_double.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_float.c output pattern test, is 12 4951 127 1 9320
13: 13 14271 140
FAIL: libffi.call/cls_align_longdouble.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_pointer.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_sint16.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_sint32.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_sint64.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_uint16.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_uint32.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/cls_align_uint64.c output pattern test, is 12 4951 127 1
9320 13: 13 14271 140
FAIL: libffi.call/nested_struct.c execution test
FAIL: libffi.call/nested_struct1.c execution test
FAIL: libffi.call/nested_struct10.c execution test
FAIL: libffi.call/nested_struct2.c execution test
FAIL: libffi.call/nested_struct3.c execution test
FAIL: libffi.call/nested_struct4.c execution test
FAIL: libffi.call/nested_struct5.c execution test
FAIL: libffi.call/nested_struct6.c execution test
FAIL: libffi.call/nested_struct7.c execution test
FAIL: libffi.call/nested_struct8.c execution test
FAIL: libffi.call/nested_struct9.c execution test
FAIL: libffi.call/problem1.c output pattern test, is 1 2 3 1 2 3: 2 4 6
FAIL: libffi.call/return_sc.c execution test
FAIL: libffi.call/struct5.c execution test
FAIL: libffi.special/unwindtest.cc execution test
FAIL: libffi.special/unwindtest_ffi_call.cc execution test
FAIL: libffi.special/unwindtest.cc execution test
FAIL: libffi.special/unwindtest_ffi_call.cc execution test
FAIL: libffi.special/unwindtest.cc execution test
FAIL: libffi.special/unwindtest_ffi_call.cc execution test
FAIL: libffi.special/unwindtest.cc execution test
FAIL: libffi.special/unwindtest_ffi_call.cc execution test

		=== libffi Summary ===

# of expected passes		1325
# of unexpected failures	65


    cheers,
      DaveK

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Aaron W. LaFramboise]

Dave Korn wrote:
> Aaron W. LaFramboise wrote:
>> This patch builds libgcj, libgcj-tools, and libffi as DLLs on Windows.
> 
>   This patch revises and updates Aaron's old patch from last August.  It adds
> some essential support for Cygwin that the previous patch didn't have, and
> does things slightly differently in places.

You could probably split this into separate parts, unless you think it 
would be easier to get it reviewed as a single chunk.

As I recall, and you can probably tell from where you got the patches 
from, there were some reservations with some parts of this patch.

In particular, it might be better to import a new LTDL version, assuming 
that fixes this problem.  If not, it should probably be fixed upstream.

This stuff is slightly incomplete, as it really needs a DEF-generation 
thing, probably with some sort of versioned ordinal thing, or this will 
have awful storage and load-time performance.  I had started on this, 
and I can submit a patch for this if you have not already started 
working on this.

I have no objections to any of this going in though, except for the below.

> Index: gcc/config/i386/t-cygming

> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000

I think it would be better to figure out why the top-level LDFLAGS does 
not get propagated properly into java as it does for every other 
language, rather than sticking in this hack.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Dave Korn]

Aaron W. LaFramboise wrote:
> Dave Korn wrote:
>> Aaron W. LaFramboise wrote:

> This stuff is slightly incomplete, as it really needs a DEF-generation
> thing, probably with some sort of versioned ordinal thing, or this will
> have awful storage and load-time performance.  I had started on this,
> and I can submit a patch for this if you have not already started
> working on this.

  Yes, at the moment it just relies on everything being auto exported, it
would be very helpful if you've got something going for a map file.

> I have no objections to any of this going in though, except for the below.
> 
>> Index: gcc/config/i386/t-cygming
> 
>> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
> 
> I think it would be better to figure out why the top-level LDFLAGS does
> not get propagated properly into java as it does for every other
> language, rather than sticking in this hack.

  Two questions:

-  Why "hack"?  It's a robust mechanism specified in the GNU Make manual as
far as I know.
-  What does this have to do with the top-level LDFLAGS?  I didn't change them
because I don't want cc1 and cc1plus to also have 128meg of stack, do I?

    cheers,
      DaveK

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Andrew Haley]

Dave Korn wrote:
> Andrew Haley wrote:
> 
>>>   I'm just putting this through a bootstrap at the moment.  There's not going
>>> to be much to test because none of this used to be built on Cygwin at all
>>> before, so it can hardly regress.  If it bootstraps and builds nice working
>>> DLLs, OK for HEAD?
>> I'm going to ask for libgcj test results: we need to know if it's fit for
>> use.
> 
>   Certainly.  Will be many many hours before my bootstrap get to them, but
> I'll report back.  As a guideline to what to expect, I get these results on
> 4.3.2 using a similar patch; maybe you could let me know if you see any
> patterns in there that would indicate fundamental brokenness.

Well, there are so many failures that it's unlikely any non-trivial program
would run.  It's hard to know what the problems are without seeing the logs.

Andrew.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Aaron W. LaFramboise]

Dave Korn wrote:
> Aaron W. LaFramboise wrote:
>> Dave Korn wrote:

>>> Index: gcc/config/i386/t-cygming
>>> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
>> I think it would be better to figure out why the top-level LDFLAGS does
>> not get propagated properly into java as it does for every other
>> language, rather than sticking in this hack.
> 
>   Two questions:
> 
> -  Why "hack"?  It's a robust mechanism specified in the GNU Make manual as
> far as I know.
> -  What does this have to do with the top-level LDFLAGS?  I didn't change them
> because I don't want cc1 and cc1plus to also have 128meg of stack, do I?

Look at config/mh-mingw, where this is set in LDFLAGS for the entire 
build.  A while back, someone or other decided that this was the right 
thing to do.  This value should be propagated into gcc/java, the same 
way that it is for everything else, but for some weird reason, it 
doesn't propagate through the build machinery.  The value that is there 
is large enough for jc1.exe to compile libjava.

I think the right thing to do is fix that bug, rather than just hacking 
it to use the flag that it should already be using, if you see what I mean.

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Dave Korn]

Aaron W. LaFramboise wrote:
> Dave Korn wrote:

>> -  What does this have to do with the top-level LDFLAGS?  I didn't
>> change them
>> because I don't want cc1 and cc1plus to also have 128meg of stack, do I?
> 
> Look at config/mh-mingw, where this is set in LDFLAGS for the entire
> build.  A while back, someone or other decided that this was the right
> thing to do.  This value should be propagated into gcc/java, the same
> way that it is for everything else, but for some weird reason, it
> doesn't propagate through the build machinery.  The value that is there
> is large enough for jc1.exe to compile libjava.
> 
> I think the right thing to do is fix that bug, rather than just hacking
> it to use the flag that it should already be using, if you see what I mean.

  I notice that those flags get applied to everything in stage1 (xgcc, cc1,
gen* et al) and not to stages 2 or 3.  Are you sure that isn't intendtional?

    cheers,
      DaveK

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Pedro Alves]

On Saturday 11 April 2009 19:22:25, Dave Korn wrote:
> >> Index: gcc/config/i386/t-cygming
> > 
> >> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
> > 
> > I think it would be better to figure out why the top-level LDFLAGS does
> > not get propagated properly into java as it does for every other
> > language, rather than sticking in this hack.
> 
>   Two questions:
> 
> -  Why "hack"?  It's a robust mechanism specified in the GNU Make manual as
> far as I know.

Isn't this a *host* issue rather than a *target* problem?  If so, it would
seem to me that a t-* file would be the wrong place for this.  E.g., would a
linux x cygwin gcj need this?  What about a cygwin x linux gcj ?

-- 
Pedro Alves

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Dave Korn]

Pedro Alves wrote:
> On Saturday 11 April 2009 19:22:25, Dave Korn wrote:
>>>> Index: gcc/config/i386/t-cygming
>>>> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000

> Isn't this a *host* issue rather than a *target* problem?  If so, it would
> seem to me that a t-* file would be the wrong place for this.  

  Oh, yeh.  It's host, not target.  I forgot to think cross-compiler.  Host
makefile frags are "discouraged", but I see there is already an x-cygwin, so I
guess I should try it there?

    cheers,
      DaveK

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Pedro Alves]

On Sunday 12 April 2009 00:27:48, Dave Korn wrote:
> Pedro Alves wrote:
> > On Saturday 11 April 2009 19:22:25, Dave Korn wrote:
> >>>> Index: gcc/config/i386/t-cygming
> >>>> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
> 
> > Isn't this a *host* issue rather than a *target* problem?  If so, it would
> > seem to me that a t-* file would be the wrong place for this.  
> 
>   Oh, yeh.  It's host, not target.  I forgot to think cross-compiler.  Host
> makefile frags are "discouraged", but I see there is already an x-cygwin, so I
> guess I should try it there?

Looks like there's precedent for something like that:

>cat gcc/config/rs6000/x-aix
# genautomata requires more than 256MB of data
build/genautomata : override LDFLAGS += -Wl,-bmaxdata:0x20000000

# jc1 requires more than 256MB of data
jc1 : override LDFLAGS += -Wl,-bmaxdata:0x20000000

-- 
Pedro Alves

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Aaron W. LaFramboise]

Dave Korn wrote:
> Aaron W. LaFramboise wrote:
>> Dave Korn wrote:
> 
>>> -  What does this have to do with the top-level LDFLAGS?  I didn't
>>> change them
>>> because I don't want cc1 and cc1plus to also have 128meg of stack, do I?
>> Look at config/mh-mingw, where this is set in LDFLAGS for the entire
>> build.  A while back, someone or other decided that this was the right
>> thing to do.  This value should be propagated into gcc/java, the same
>> way that it is for everything else, but for some weird reason, it
>> doesn't propagate through the build machinery.  The value that is there
>> is large enough for jc1.exe to compile libjava.
>>
>> I think the right thing to do is fix that bug, rather than just hacking
>> it to use the flag that it should already be using, if you see what I mean.
> 
>   I notice that those flags get applied to everything in stage1 (xgcc, cc1,
> gen* et al) and not to stages 2 or 3.  Are you sure that isn't intendtional?

OK, I didn't know that.  If that's true, then probably those flags are 
only for the host's compiler.

See <http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00420.html>.  At the 
very least, it was my understanding that the LDFLAGS in mh-mingw were 
*supposed* to fix this.  Apparently, it only worked for non-bootstrap 
cross-builds.

Joseph, what do you think about this?

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Ian Lance Taylor]

Pedro Alves <pedro@codesourcery.com> writes:

> On Sunday 12 April 2009 00:27:48, Dave Korn wrote:
>> Pedro Alves wrote:
>> > On Saturday 11 April 2009 19:22:25, Dave Korn wrote:
>> >>>> Index: gcc/config/i386/t-cygming
>> >>>> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
>> 
>> > Isn't this a *host* issue rather than a *target* problem?  If so, it would
>> > seem to me that a t-* file would be the wrong place for this.  
>> 
>>   Oh, yeh.  It's host, not target.  I forgot to think cross-compiler.  Host
>> makefile frags are "discouraged", but I see there is already an x-cygwin, so I
>> guess I should try it there?
>
> Looks like there's precedent for something like that:
>
>>cat gcc/config/rs6000/x-aix
> # genautomata requires more than 256MB of data
> build/genautomata : override LDFLAGS += -Wl,-bmaxdata:0x20000000
>
> # jc1 requires more than 256MB of data
> jc1 : override LDFLAGS += -Wl,-bmaxdata:0x20000000

See also top level config/mh-mingw.

Ian

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Pedro Alves]

On Wednesday 15 April 2009 01:02:50, Ian Lance Taylor wrote:
> Pedro Alves <pedro@codesourcery.com> writes:
> 
> > On Sunday 12 April 2009 00:27:48, Dave Korn wrote:
> >> Pedro Alves wrote:
> >> > On Saturday 11 April 2009 19:22:25, Dave Korn wrote:
> >> >>>> Index: gcc/config/i386/t-cygming
> >> >>>> +jc1$(exeext): LDFLAGS+=-Wl,-stack,0x8000000
> >> 
> >> > Isn't this a *host* issue rather than a *target* problem?  If so, it would
> >> > seem to me that a t-* file would be the wrong place for this.  
> >> 
> >>   Oh, yeh.  It's host, not target.  I forgot to think cross-compiler.  Host
> >> makefile frags are "discouraged", but I see there is already an x-cygwin, so I
> >> guess I should try it there?
> >
> > Looks like there's precedent for something like that:
> >
> >>cat gcc/config/rs6000/x-aix
> > # genautomata requires more than 256MB of data
> > build/genautomata : override LDFLAGS += -Wl,-bmaxdata:0x20000000
> >
> > # jc1 requires more than 256MB of data
> > jc1 : override LDFLAGS += -Wl,-bmaxdata:0x20000000
> 
> See also top level config/mh-mingw.

See also http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00887.html

-- 
Pedro Alves

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Paolo Bonzini]

> I noticed another thread where Peter O'Gorman was proposing to update
> libtool in gcc to latest libtool-git-tip (e.g. now that libtool-2.0 ne'
> libtool-2.2 is out). Perhaps the update to more recent ltdl would be an
> appropriate addendum/followup to his patch.

Unfortunately, I think it is very hard to squeeze a ltdl update in the
deadline for stage1.  Maybe the release managers could defer to the
libjava maintainers.

> Right. If I am correct above, this was probably the rationale for why it
> didn't happen as part of the Great Autotool Update: too messy to deal
> with all at once.  But now...maybe it's time. But I agree -- that is a
> big effort, and shouldn't be part of your patch here.
> 
>> There may also be
>> other reasons we're still using this old version of libltdl.
> 
> I doubt it. Probably just inertia.

Yes, nobody really cared because:

1) it was not much of a maintainance pain, unlike libtool -- remember
that there were some things to be invented (such as exec-tool.in) to
update libtool;

2) nobody knows how easier a libltdl update would be (I'd say somewhat
easier, but only because it only touches libjava).

3) a different set of maintainers was involved (build vs. libjava)

4) nobody really checked what features a newer libltdl has (in either
group of maintainers).

Paolo

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Charles Wilson]

Charles Wilson wrote:
>> If it's all the same to you, I like my solution better. :)  Let me know
>> if you still feel differently, and maybe we can talk more.
> 
> No, it's fine.
      ^^^^^^^^^^
Just my opinion; I'm not a maintainer and can't give commit approval.
You'll have to get that from somebody else. <g>

--
Chuck

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Charles Wilson]

Aaron W. LaFramboise wrote:
> Yes.  Sorry, I forgot to mention this.  In addition, we specifically do
> not want this function to be exported from the DLL at all.  See below.

Well, with the default ld behavior, we /are/ exporting darn near
everything, including these ltdl symbols.  By ensuring that the ltdl
symbols are not decorated, and given that no other symbols anywhere in
libjava are decorated, you in effect turn the default
--enable-auto-export behavior back on -- just as if you had explicitly
specified it on the command line.  But you knew that.

> OK, I will fix this comment to reflect the purpose of this name change.

Good enough, given <below>.

> The new libltdl does not have this issue.  I have no idea why we're
> stuck with the 1.5 version of libltdl even though we're using a recent
> libtool.

Yes, I thought we had fixed this.  I don't remember, but perhaps back in
spring '07 when the Great Autotool Update happened -- taking libtool
from 1.4p3-FORK to libtool-CVS-HEAD-20070318, the decision was made to
postpone the libltdl bits until the "real" libtool-2.0 (now called
libtool-2.2) was released.  I guess.

I noticed another thread where Peter O'Gorman was proposing to update
libtool in gcc to latest libtool-git-tip (e.g. now that libtool-2.0 ne'
libtool-2.2 is out). Perhaps the update to more recent ltdl would be an
appropriate addendum/followup to his patch.

For now, tho:

> However, libltdl seems to have been modified in similar ways by other
> people; just look at the ChangeLog.  Since everyone else is modifying
> this, and this is not an issue in the upstream version, I think this is
> the best change.

Sure. If -- for whatever reason -- we are currently using a forked
version of old ltdl, there's not too much reason to worry about
maintaining synchrony with the original (and independently progressed)
version over at libtool-git.

> Updating to a newer libltdl would probably be good, since I suspect
> there are Windows-specific improvements in it.  However, libjava would
> need to be ported to it, since its currently dependent upon interfaces
> that have been removed in newer versions of libltdl. 

Right. If I am correct above, this was probably the rationale for why it
didn't happen as part of the Great Autotool Update: too messy to deal
with all at once.  But now...maybe it's time. But I agree -- that is a
big effort, and shouldn't be part of your patch here.

> There may also be
> other reasons we're still using this old version of libltdl.

I doubt it. Probably just inertia.

> I don't like this solution as much, as these exports really are not
> dllexport, and we specifically do not want them to be exported--even
> though we are doing nothing at present to prevent this. 

Ack.

> (As I mentioned
> previous, a future patch will fix this symbol leakage.)  For this
> reason, I think it's important we completely avoid marking these
> dllexport, beyond fixing this specific issue.

That makes sense. I wonder if the right approach is to once again
leverage the version script stuff and generate a .def file, like you did
for libgcc.  But later.

> If it's all the same to you, I like my solution better. :)  Let me know
> if you still feel differently, and maybe we can talk more.

No, it's fine.

BTW, I don't think I've mentioned this: but /thank you/ for your efforts
this summer.

--
Chuck

Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Aaron W. LaFramboise]

Charles Wilson wrote:
> Why was this necessary:
> 
> 	<libjava/libltdl>
> 	* ltdl.c (DLL_EXPORT): Rename to LIBLTDL_DLL_EXPORT.
> 	* ltdl.h (DLL_EXPORT): Rename to LIBLTDL_DLL_EXPORT.
> 
> AFAIK, this new symbol LIBLDL_DLLEXPORT, is never defined by libtool,
> even when building libjava shared.  So the symbols decorated with
> LT_SCOPE will never get the __declspec(dllexport) annotation.
> 
> Or was that the intention, in order to work around the issue where ld
> disables its default auto-export behavior, when it sees ANY symbol
> explicitly marked as __declspec(dllexport)?

Yes.  Sorry, I forgot to mention this.  In addition, we specifically do 
not want this function to be exported from the DLL at all.  See below.

> If so, then the comment:
> +#  ifdef LIBLTDL_DLL_EXPORT /* defined by libtool (if required) */
> is wrong; it should be something like
>    /* !not! 'DLL_EXPORT'; we don't want libtool to
>       automatically decorate just these exports without
>       also decorating every other libjava export
>    */

OK, I will fix this comment to reflect the purpose of this name change.

> But finally, there's one last issue: I thought one of the gcc guidelines
> going forward with respect to autotools was to NOT modify imported
> files.  These changes will be lost every time somebody resyncs with
> upstream libtool...

The new libltdl does not have this issue.  I have no idea why we're 
stuck with the 1.5 version of libltdl even though we're using a recent 
libtool.

However, libltdl seems to have been modified in similar ways by other 
people; just look at the ChangeLog.  Since everyone else is modifying 
this, and this is not an issue in the upstream version, I think this is 
the best change.

Updating to a newer libltdl would probably be good, since I suspect 
there are Windows-specific improvements in it.  However, libjava would 
need to be ported to it, since its currently dependent upon interfaces 
that have been removed in newer versions of libltdl.  There may also be 
other reasons we're still using this old version of libltdl.

> Wouldn't it make more sense, until there are proper __declspec()
> markings/macros on all desired libjava exports, to leave these source
> files alone and just explicitly use -Wl,--enable-auto-export when
> linking the libjava DLL on mingw/cygwin?

I don't like this solution as much, as these exports really are not 
dllexport, and we specifically do not want them to be exported--even 
though we are doing nothing at present to prevent this.  (As I mentioned 
previous, a future patch will fix this symbol leakage.)  For this 
reason, I think it's important we completely avoid marking these 
dllexport, beyond fixing this specific issue.

If it's all the same to you, I like my solution better. :)  Let me know 
if you still feel differently, and maybe we can talk more.