* [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows
@ 2008-08-24 4:23 Aaron W. LaFramboise
2008-08-24 11:07 ` Danny Smith
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Aaron W. LaFramboise @ 2008-08-24 4:23 UTC (permalink / raw)
To: gcc-patches, java-patches
[-- 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 */
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-24 4:23 [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows Aaron W. LaFramboise @ 2008-08-24 11:07 ` Danny Smith 2008-08-24 16:54 ` Andrew Haley 2009-04-11 5:33 ` Dave Korn 2 siblings, 0 replies; 22+ messages in thread From: Danny Smith @ 2008-08-24 11:07 UTC (permalink / raw) To: Aaron W. LaFramboise; +Cc: gcc-patches, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-24 4:23 [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows Aaron W. LaFramboise 2008-08-24 11:07 ` Danny Smith @ 2008-08-24 16:54 ` Andrew Haley 2008-08-24 20:09 ` Aaron W. LaFramboise 2009-04-11 5:33 ` Dave Korn 2 siblings, 1 reply; 22+ messages in thread From: Andrew Haley @ 2008-08-24 16:54 UTC (permalink / raw) To: Aaron W. LaFramboise; +Cc: gcc-patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-24 16:54 ` Andrew Haley @ 2008-08-24 20:09 ` Aaron W. LaFramboise 0 siblings, 0 replies; 22+ messages in thread From: Aaron W. LaFramboise @ 2008-08-24 20:09 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc-patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-24 4:23 [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows Aaron W. LaFramboise 2008-08-24 11:07 ` Danny Smith 2008-08-24 16:54 ` Andrew Haley @ 2009-04-11 5:33 ` Dave Korn 2009-04-11 9:36 ` Andrew Haley 2009-04-11 17:15 ` Aaron W. LaFramboise 2 siblings, 2 replies; 22+ messages in thread From: Dave Korn @ 2009-04-11 5:33 UTC (permalink / raw) To: Aaron W. LaFramboise; +Cc: gcc-patches, java-patches [-- 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 5:33 ` Dave Korn @ 2009-04-11 9:36 ` Andrew Haley 2009-04-11 11:20 ` Dave Korn 2009-04-11 17:15 ` Aaron W. LaFramboise 1 sibling, 1 reply; 22+ messages in thread From: Andrew Haley @ 2009-04-11 9:36 UTC (permalink / raw) To: Dave Korn; +Cc: Aaron W. LaFramboise, gcc-patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 9:36 ` Andrew Haley @ 2009-04-11 11:20 ` Dave Korn 2009-04-11 20:13 ` Andrew Haley 0 siblings, 1 reply; 22+ messages in thread From: Dave Korn @ 2009-04-11 11:20 UTC (permalink / raw) To: Andrew Haley; +Cc: Dave Korn, Aaron W. LaFramboise, gcc-patches, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 11:20 ` Dave Korn @ 2009-04-11 20:13 ` Andrew Haley 0 siblings, 0 replies; 22+ messages in thread From: Andrew Haley @ 2009-04-11 20:13 UTC (permalink / raw) To: Dave Korn; +Cc: Aaron W. LaFramboise, gcc-patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 5:33 ` Dave Korn 2009-04-11 9:36 ` Andrew Haley @ 2009-04-11 17:15 ` Aaron W. LaFramboise 2009-04-11 18:12 ` Dave Korn 1 sibling, 1 reply; 22+ messages in thread From: Aaron W. LaFramboise @ 2009-04-11 17:15 UTC (permalink / raw) To: Dave Korn; +Cc: gcc-patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 17:15 ` Aaron W. LaFramboise @ 2009-04-11 18:12 ` Dave Korn 2009-04-11 21:52 ` Aaron W. LaFramboise 2009-04-11 23:15 ` Pedro Alves 0 siblings, 2 replies; 22+ messages in thread From: Dave Korn @ 2009-04-11 18:12 UTC (permalink / raw) To: Aaron W. LaFramboise; +Cc: Dave Korn, gcc-patches, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 18:12 ` Dave Korn @ 2009-04-11 21:52 ` Aaron W. LaFramboise 2009-04-11 23:03 ` Dave Korn 2009-04-11 23:15 ` Pedro Alves 1 sibling, 1 reply; 22+ messages in thread From: Aaron W. LaFramboise @ 2009-04-11 21:52 UTC (permalink / raw) To: Dave Korn; +Cc: gcc-patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 21:52 ` Aaron W. LaFramboise @ 2009-04-11 23:03 ` Dave Korn 2009-04-12 4:15 ` Aaron W. LaFramboise 0 siblings, 1 reply; 22+ messages in thread From: Dave Korn @ 2009-04-11 23:03 UTC (permalink / raw) To: Aaron W. LaFramboise; +Cc: Dave Korn, gcc-patches, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 23:03 ` Dave Korn @ 2009-04-12 4:15 ` Aaron W. LaFramboise 0 siblings, 0 replies; 22+ messages in thread From: Aaron W. LaFramboise @ 2009-04-12 4:15 UTC (permalink / raw) To: Dave Korn; +Cc: gcc-patches, java-patches, Joseph S. Myers 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 18:12 ` Dave Korn 2009-04-11 21:52 ` Aaron W. LaFramboise @ 2009-04-11 23:15 ` Pedro Alves 2009-04-11 23:17 ` Dave Korn 1 sibling, 1 reply; 22+ messages in thread From: Pedro Alves @ 2009-04-11 23:15 UTC (permalink / raw) To: gcc-patches; +Cc: Dave Korn, Aaron W. LaFramboise, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 23:15 ` Pedro Alves @ 2009-04-11 23:17 ` Dave Korn 2009-04-11 23:58 ` Pedro Alves 0 siblings, 1 reply; 22+ messages in thread From: Dave Korn @ 2009-04-11 23:17 UTC (permalink / raw) To: Pedro Alves; +Cc: gcc-patches, Dave Korn, Aaron W. LaFramboise, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 23:17 ` Dave Korn @ 2009-04-11 23:58 ` Pedro Alves 2009-04-15 0:03 ` Ian Lance Taylor 0 siblings, 1 reply; 22+ messages in thread From: Pedro Alves @ 2009-04-11 23:58 UTC (permalink / raw) To: Dave Korn; +Cc: gcc-patches, Aaron W. LaFramboise, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-11 23:58 ` Pedro Alves @ 2009-04-15 0:03 ` Ian Lance Taylor 2009-04-15 0:13 ` Pedro Alves 0 siblings, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2009-04-15 0:03 UTC (permalink / raw) To: Pedro Alves; +Cc: Dave Korn, gcc-patches, Aaron W. LaFramboise, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2009-04-15 0:03 ` Ian Lance Taylor @ 2009-04-15 0:13 ` Pedro Alves 0 siblings, 0 replies; 22+ messages in thread From: Pedro Alves @ 2009-04-15 0:13 UTC (permalink / raw) To: Ian Lance Taylor Cc: Dave Korn, gcc-patches, Aaron W. LaFramboise, java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <48B1DA69.9070306@cwilson.fastmail.fm>]
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows [not found] <48B1DA69.9070306@cwilson.fastmail.fm> @ 2008-08-25 4:34 ` Aaron W. LaFramboise 2008-08-25 4:37 ` Charles Wilson 0 siblings, 1 reply; 22+ messages in thread From: Aaron W. LaFramboise @ 2008-08-25 4:34 UTC (permalink / raw) To: Charles Wilson; +Cc: GCC Patches, java-patches 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-25 4:34 ` Aaron W. LaFramboise @ 2008-08-25 4:37 ` Charles Wilson 2008-08-25 4:57 ` Charles Wilson 2008-08-25 18:11 ` Paolo Bonzini 0 siblings, 2 replies; 22+ messages in thread From: Charles Wilson @ 2008-08-25 4:37 UTC (permalink / raw) To: GCC Patches; +Cc: java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-25 4:37 ` Charles Wilson @ 2008-08-25 4:57 ` Charles Wilson 2008-08-25 18:11 ` Paolo Bonzini 1 sibling, 0 replies; 22+ messages in thread From: Charles Wilson @ 2008-08-25 4:57 UTC (permalink / raw) To: GCC Patches; +Cc: java-patches 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows 2008-08-25 4:37 ` Charles Wilson 2008-08-25 4:57 ` Charles Wilson @ 2008-08-25 18:11 ` Paolo Bonzini 1 sibling, 0 replies; 22+ messages in thread From: Paolo Bonzini @ 2008-08-25 18:11 UTC (permalink / raw) To: Charles Wilson; +Cc: GCC Patches, java-patches > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-04-15 0:13 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-24 4:23 [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows Aaron W. LaFramboise
2008-08-24 11:07 ` Danny Smith
2008-08-24 16:54 ` Andrew Haley
2008-08-24 20:09 ` Aaron W. LaFramboise
2009-04-11 5:33 ` Dave Korn
2009-04-11 9:36 ` Andrew Haley
2009-04-11 11:20 ` Dave Korn
2009-04-11 20:13 ` Andrew Haley
2009-04-11 17:15 ` Aaron W. LaFramboise
2009-04-11 18:12 ` Dave Korn
2009-04-11 21:52 ` Aaron W. LaFramboise
2009-04-11 23:03 ` Dave Korn
2009-04-12 4:15 ` Aaron W. LaFramboise
2009-04-11 23:15 ` Pedro Alves
2009-04-11 23:17 ` Dave Korn
2009-04-11 23:58 ` Pedro Alves
2009-04-15 0:03 ` Ian Lance Taylor
2009-04-15 0:13 ` Pedro Alves
[not found] <48B1DA69.9070306@cwilson.fastmail.fm>
2008-08-25 4:34 ` Aaron W. LaFramboise
2008-08-25 4:37 ` Charles Wilson
2008-08-25 4:57 ` Charles Wilson
2008-08-25 18:11 ` Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).