[MinGW-dvlpr] A couple of questions about the GCC 4.3.0 i386-pc-mingw32 ALPHA Release - ping Danny/Aaron?

[Dave K. <dav...@ar...>]

    Hi guys,

  As I think I mentioned earlier, I started with a different approach to your
mingw patchset for generating shared libgcc; I added a modified version of the
contents of the generic ELF shared libgcc build fragment
gcc/config/t-slibgcc-elf-ver into gcc/config/i386/t-cygwin.  (Patch attached
for comparison, in case you're curious).

  As an experiment this weekend I tried modifying my build to use your
technique: I copied this hunk:

diff -pru gcc-4.3.0/gcc/config/i386/t-mingw32
gcc-4.3.0.new/gcc/config/i386/t-mingw32
--- gcc-4.3.0/gcc/config/i386/t-mingw32	2006-08-15 18:06:18.000000000 +0100
+++ gcc-4.3.0.new/gcc/config/i386/t-mingw32	2008-04-03 06:28:15.000000000
+0100
@@ -1,2 +1,20 @@
 # Match SYSTEM_INCLUDE_DIR
 NATIVE_SYSTEM_HEADER_DIR = /mingw/include
+
+# Build libgcc.as a  dll
+shared-libgcc: libgcc_s.a libgcc_s_alpha_1.dll
+libgcc_s.a libgcc_s_alpha_1.dll: libgcc.a
+	cp -f libgcc.a libgcc_t.a
+	$(AR) -x libgcc_t.a _chkstk.o _ctors.o
+	$(AR) -d libgcc_t.a _chkstk.o _ctors.o
+	dlltool --output-def libgcc_s.def --export-all libgcc_t.a	
+	$(GCC_FOR_TARGET)  -shared -fno-exceptions -o libgcc_s_alpha_1.dll
-Wl,--out-implib,libgcc_s.a libgcc_s.def libgcc_t.a
+	$(AR) -r  libgcc_s.a _chkstk.o _ctors.o
+	rm -f libgcc_t.a _chkstk.o _ctors.o libgcc_s.def
+
+install-shared-libgcc: installdirs shared-libgcc
+	$(INSTALL_DATA) libgcc_s.a $(DESTDIR)$(libsubdir)/
+	$(INSTALL_PROGRAM) libgcc_s_alpha_1.dll $(DESTDIR)$(bindir)/
+
+clean-shared-libgcc:
+	rm -f libgcc_s.a libgcc_s_alpha_1.dll


... wholesale from your patch into t-cygwin.

  But it didn't work.  Not even a little bit.  For reasons I don't yet
understand, none of those targets were invoked during the build.  I used
--enable-shared on the configure line, and even tried randomly adding
--enable-shared-libgcc in case it made a difference, but it didn't.

  So, looking at that code, my first guess would be that the targets
"shared-libgcc" and "libgcc_s_alpha_1.dll" (aka LIBGCC_SONAME) aren't actually
part of any normal build, and that your code is designed to only build the dll
at "make install" time, by adding the shared-libgcc target as a prerequisite
of install-shared-libgcc, which I'm guessing /is/ one of the normal targets
built during the "make install" process; am I even near right?  (I think I've
decided that "make check" isn't going to be simple to get working before "make
install" time in any case, so maybe that's the reasoning behind why it's not
so bad to leave building the DLL until then anyway?)


  I'm also a bit curious about

1) What happened to libgcc_eh?  (I think it's possible that this is built into
libgcc.a rather than compiled separately because what you're doing is
fundamentally a static libgcc build that only gets converted into a shared
library at the last minute, and libgcc_eh perhaps always needs to be
statically linked?)

2) Is there a simple one-or-two-line summary of why you have to remove the
chkstk and ctors objects before building the dll and put them back afterward
as the only "genuine" objects in what is otherwise a library full of import
stubs?



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....