public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: [PATCH] Build libgcc_s on Windows
@ 2008-08-18 21:30 Charles Wilson
  2008-08-19 16:42 ` Charles Wilson
  0 siblings, 1 reply; 36+ messages in thread
From: Charles Wilson @ 2008-08-18 21:30 UTC (permalink / raw)
  To: gcc-patches

I'm a little concerned about this part:

+  if (pe_dll) {
+    # This matches SHLIB_SONAME in config/i386/t-cygming.
+    print "LIBRARY libgcc_s_1.dll";
+    print "EXPORTS";
+  }

when it comes to interoperability on the Windows platform.  Suppose you
have an application compiled by mingw-gcc and one compiled by
cygwin-gcc. For these two apps to work properly, the libgcc dll must be
(a) in the PATH, or (b) in the same directory as the executable (there
are a few other possibilities as well, but let's ignore those for now).

It's the first -- and most common -- case that concerns me. I'll have
two identically named DLLs in the PATH: one which is intended for use by
"native" windows programs, and the other which is intended for use by
cygwin programs.  Presumably the code in these two different DLLs will
be different, since the behavior and capabilities of the two "platforms"
differ.   Assuming case (a) above, then whichever one is found first in
the PATH will always be used by any application that claims to need
"libgcc_s_1".  This is a guaranteed recipe for runtime conflicts.

It is also why (almost all) DLLs shipped with cygwin are named
"cygfoo.dll", not "libfoo.dll" -- this naming scheme is also built in to
libtool, and is supported by ld since about 2000, which is why if you
try to build libstdc++ shared in current gcc on cygwin, you'll get
cygstdc++-VER.dll.

So, IMO, both SHLIB_SONAME and the snippet above should be sensitive to
the actual platform (cygwin, or mingw).

Also, there is another interoperability issue: IIRC the cygwin gcc
maintainer intends to provide (or hopes to one day provide) both dw2 and
sjlj versions of the compiler.  This also might be useful -- one day --
on the mingw platform. [1]  But, in that case, you'll again have two
different runtime DLLs; one for dw2 and one for sjlj.  Perhaps
SHLIB_SONAME and the snippet above should /also/ be sensitive to that
setting?

I realize you could continue this down this rabbithole indefinitely,
with
cyggcc_s_sjlj_nothread_ipcsupport_other_random_configure_option_1.dll,
and that would be very silly.  However, the mingw-vs-cygwin issue and
the dw2-vs-sjlj issues probably do need to be resolved in a way that
applications compiled with compilers of those four flavors can coexist
on the same machine.

from t-cygming:

+SHLIB_IMPLIB = @shlib_base_name@.a
+SHLIB_SOVERSION = 1
+SHLIB_SONAME = @shlib_base_name@_$(SHLIB_SOVERSION)$(SHLIB_EXT)

Here, SHLIB_IMPLIB *could* be named @shlib_base_name@.dll.a to make
clear that it is an import library (gnu ld understands this since about
2000) -- and for parallelism to the import libraries created by libtool
for the other runtime libs.  Also, in reference to the disambiguation
above, all "four" implibs could have the same name, since they will live
in the compiler's private area; only the _SONAMEs need to be explicitly
disambiguated.


--
Chuck

[1] even if not provided officially by the mingw team, a private entity
might want an sjlj compiler if they run into issues with your upcoming
foreign frame support.  And they might assume that any application
products they ship built using that compiler will actually work on a
client's machine, even if that client has ALSO installed applications
built using the official mingw-dw2 compiler.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-18 21:30 [PATCH] Build libgcc_s on Windows Charles Wilson
@ 2008-08-19 16:42 ` Charles Wilson
  2008-08-19 20:34   ` Paolo Bonzini
  2008-08-28  3:21   ` Dave Korn
  0 siblings, 2 replies; 36+ messages in thread
From: Charles Wilson @ 2008-08-19 16:42 UTC (permalink / raw)
  To: gcc-patches

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

Charles Wilson wrote (reordered):

> Here, SHLIB_IMPLIB *could* be named @shlib_base_name@.dll.a to make
> clear that it is an import library

On second thought, I think this part is a bad idea. Stick with .a, not
.dll.a.

> I'm a little concerned about this part:
> 
> +  if (pe_dll) {
> +    # This matches SHLIB_SONAME in config/i386/t-cygming.
> +    print "LIBRARY libgcc_s_1.dll";
> +    print "EXPORTS";
> +  }

Here's an *untested* possibility -- with one missing pieces.

The highlights:
in t-cygming: in SHLIB_LINK and SHLIB_INSTALL, every occurrence of
	SHLIB_SONAME
is replaced by
	$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)).

in t-cygwin/t-mingw32: define SHLIB_PREFIX. On mingw32, it's lib%, so
the patsubst above is a no-op.

in mkmap-flat.awk, do 'LIBRARY @SHLIB_SONAME@'
in t-cygming (SHLIB_LINK), sed out the @SHLIB_SONAME@ with the
appropriately-patsubst value. Take care not to modify the timestamp of
the .def file if no changes.

in t-cygming: define SHLIB_SONAME_T with _sjlj_ or _dw2_, depending on
value of dwarf2_unwind_info.

missing piece:
How to ensure that the compilation macro DWARF2_UNWIND_INFO and the
makefile variable dwarf2_unwind_info have the same value?



I just saw Paolo's message Tue, 19 Aug 2008 17:54:59 +0200; I'm not sure
how his suggestions might modify this one...

Attached should be applied on top of Aaron's existing patch -- but
again, it is untested. It's just my attempt to demonstrate the idea.

--
Chuck


[-- Attachment #2: cygming-shared.patch --]
[-- Type: text/plain, Size: 5479 bytes --]

diff -u old/gcc/mkmap-flat.awk new/gcc/mkmap-flat.awk
--- old/gcc/mkmap-flat.awk	2008-08-19 10:10:02.038400000 -0400
+++ new/gcc/mkmap-flat.awk	2008-08-19 10:11:42.466800000 -0400
@@ -93,8 +93,10 @@
 END {
 
   if (pe_dll) {
-    # This matches SHLIB_SONAME in config/i386/t-cygming.
-    print "LIBRARY libgcc_s_1.dll";
+    # The @SHLIB_SONAME@ in the output will be
+    # updated by the SHLIB_LINK rule defined in
+    # config/i386/t-cygming.
+    print "LIBRARY @SHLIB_SONAME@";
     print "EXPORTS";
   }
 
diff -u old/gcc/config/i386/t-mingw32 new/gcc/config/i386/t-mingw32
--- old/gcc/config/i386/t-mingw32	2008-08-19 11:17:24.930000000 -0400
+++ new/gcc/config/i386/t-mingw32	2008-08-19 11:59:41.568400000 -0400
@@ -3,3 +3,4 @@
 
 # MinGW-specific parts of LIB_SPEC
 SHLIB_LC += -lmingw32 -lmingwex -lmoldname -lmsvcrt
+SHLIB_PREFIX = lib%
diff -u old/gcc/config/i386/t-cygwin new/gcc/config/i386/t-cygwin
--- old/gcc/config/i386/t-cygwin	2008-08-19 11:17:17.754000000 -0400
+++ new/gcc/config/i386/t-cygwin	2008-08-19 11:59:53.952600000 -0400
@@ -16,3 +16,4 @@
 
 # Cygwin-specific parts of LIB_SPEC
 SHLIB_LC += -lcygwin
+SHLIB_PREFIX = cyg%
diff -u old/gcc/config/i386/t-cygming new/gcc/config/i386/t-cygming
--- old/gcc/config/i386/t-cygming	2008-08-19 09:43:09.051800000 -0400
+++ new/gcc/config/i386/t-cygming	2008-08-19 11:59:30.508000000 -0400
@@ -43,42 +43,63 @@
 # mkmap-flat.awk is used with the pe_dll option to produce a DEF instead
 # of an ELF map file.
 #
-# Warning: If SHLIB_SOVERSION or SHLIB_SONAME is updated, LIBGCC_SONAME
-# in mingw32.h must be updated also.
+# Warning: If SHLIB_SOVERSION or SHLIB_SONAME_T is updated,
+# LIBGCC_SONAME in mingw32.h must be updated also.
 
 SHLIB_EXT = .dll
 SHLIB_IMPLIB = @shlib_base_name@.a
 SHLIB_SOVERSION = 1
-SHLIB_SONAME = @shlib_base_name@_$(SHLIB_SOVERSION)$(SHLIB_EXT)
+ifeq ($(dwarf2_unwind_info),1)
+SHLIB_SONAME_T = @shlib_base_name@_dw2_$(SHLIB_SOVERSION)$(SHLIB_EXT)
+else
+SHLIB_SONAME_T = @shlib_base_name@_sjlj_$(SHLIB_SOVERSION)$(SHLIB_EXT)
+endif
 SHLIB_MAP = @shlib_map_file@
 SHLIB_OBJS = @shlib_objs@
 SHLIB_DIR = @multilib_dir@/shlib
 SHLIB_SLIBDIR_QUAL = @shlib_slibdir_qual@
 SHLIB_LC = -luser32 -lkernel32 -ladvapi32 -lshell32
 
-SHLIB_LINK = $(LN_S) $(SHLIB_MAP) $(SHLIB_MAP).def && \
+# $(patsubst ) expressions involving SHLIB_SONAME_T are double quoted to
+# protect them from expansion while building libgcc.mk.  We want this
+# delayed until actual link/install time.
+SHLIB_LINK = $(LN_S) $(SHLIB_MAP) $(SHLIB_MAP).def.in && \
 	if [ ! -d $(SHLIB_DIR) ]; then \
 		mkdir $(SHLIB_DIR) \
 	else true; fi && \
+	cat $(SHLIB_MAP).def.in |\
+		sed -e "s/@SHLIB_SONAME@/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T))/" >\
+		$(SHLIB_MAP).def.new && \
+		if [ ! -f $(SHLIB_MAP).def ]; then \
+			mv $(SHLIB_MAP).def.new $(SHLIB_MAP).def ;\
+		else \
+			if ! cmp $(SHLIB_MAP).def.new $(SHLIB_MAP).def >& /dev/null ; then \
+				mv $(SHLIB_MAP).def.new $(SHLIB_MAP).def ;\
+			else \
+				rm -f $(SHLIB_MAP).def.new ;\
+			fi ;\
+		fi ;\
 	$(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
 	$(SHLIB_MAP).def \
 	-Wl,--out-implib,$(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp \
-	-o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp @multilib_flags@ \
+	-o $(SHLIB_DIR)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)).tmp @multilib_flags@ \
 	$(SHLIB_OBJS) $(SHLIB_LC) && \
 	$(AR_FOR_TARGET) -r $(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp \
 		_chkstk.o _ctors.o && \
-	if [ -f $(SHLIB_DIR)/$(SHLIB_SONAME) ]; then \
-	  mv -f $(SHLIB_DIR)/$(SHLIB_SONAME) \
-		$(SHLIB_DIR)/$(SHLIB_SONAME).backup; \
+	if [ -f $(SHLIB_DIR)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)) ]; then \
+	  mv -f $(SHLIB_DIR)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)) \
+		$(SHLIB_DIR)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)).backup; \
 	else true; fi && \
-	mv $(SHLIB_DIR)/$(SHLIB_SONAME).tmp $(SHLIB_DIR)/$(SHLIB_SONAME) && \
+	mv $(SHLIB_DIR)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)).tmp \
+	   $(SHLIB_DIR)/$(SHLIB_SONAME) && \
 	mv $(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp $(SHLIB_DIR)/$(SHLIB_IMPLIB)
 # $(slibdir) double quoted to protect it from expansion while building
-# libgcc.mk.  We want this delayed until actual install time.
+# libgcc.mk.  We want this delayed until actual install time.  Similarly,
+# with regards to $(patsubst ) expressions involving SHLIB_SONAME_T.
 SHLIB_INSTALL = \
 	$$(mkinstalldirs) $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL); \
-	$(INSTALL_PROGRAM) $(SHLIB_DIR)/$(SHLIB_SONAME) \
-	  $$(DESTDIR)$$(bindir)/$(SHLIB_SONAME); \
+	$(INSTALL_PROGRAM) $(SHLIB_DIR)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)) \
+	  $$(DESTDIR)$$(bindir)/$$(patsubst lib%,$(SHLIB_PREFIX),$(SHLIB_SONAME_T)); \
 	$(INSTALL_DATA) $(SHLIB_DIR)/$(SHLIB_IMPLIB) \
 	  $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_IMPLIB)
 SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk
diff -u old/gcc/config/i386/mingw32.h new/gcc/config/i386/mingw32.h
--- old/gcc/config/i386/mingw32.h	2008-08-19 10:20:34.178800000 -0400
+++ new/gcc/config/i386/mingw32.h	2008-08-19 11:31:29.540200000 -0400
@@ -201,5 +201,9 @@
 #define MD_UNWIND_SUPPORT "config/i386/w32-unwind.h"
 #endif
 
-/* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
-#define LIBGCC_SONAME "libgcc_s_1.dll"
+/* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming/t-mingw32. */
+#if DWARF2_UNWIND_INFO
+#define LIBGCC_SONAME "libgcc_s_dw2_1.dll"
+#else
+#define LIBGCC_SONAME "libgcc_s_sjlj_1.dll"
+#endif

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-19 16:42 ` Charles Wilson
@ 2008-08-19 20:34   ` Paolo Bonzini
  2008-08-25  7:40     ` Charles Wilson
  2008-08-28  3:21   ` Dave Korn
  1 sibling, 1 reply; 36+ messages in thread
From: Paolo Bonzini @ 2008-08-19 20:34 UTC (permalink / raw)
  To: Charles Wilson; +Cc: gcc-patches


> I just saw Paolo's message Tue, 19 Aug 2008 17:54:59 +0200; I'm not sure
> how his suggestions might modify this one...

It just removes the need for sed'ing out SHLIB_SONAME.

I like your plan.

I think we should split in three parts.  First is what Aaron has, second 
is what I suggested, last is what you suggested.  Note that my part can 
be tested on Linux (which is cheaper).

Paolo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-19 20:34   ` Paolo Bonzini
@ 2008-08-25  7:40     ` Charles Wilson
  2008-08-26 12:44       ` Dave Korn
  0 siblings, 1 reply; 36+ messages in thread
From: Charles Wilson @ 2008-08-25  7:40 UTC (permalink / raw)
  Cc: gcc-patches, Dave Korn

Paolo Bonzini wrote:
> 
>> I just saw Paolo's message Tue, 19 Aug 2008 17:54:59 +0200; I'm not sure
>> how his suggestions might modify this one...
> 
> It just removes the need for sed'ing out SHLIB_SONAME.
> 
> I like your plan.
> 
> I think we should split in three parts.  First is what Aaron has, second
> is what I suggested, last is what you suggested.  Note that my part can
> be tested on Linux (which is cheaper).

So does that mean Aaron's patch has all necessary approvals to be pushed
as-is?  From re-reading the thread, I see:

Danny Smith:
> OK from this Windows maintainer, but wait for Dave Korn to comment.
and
> While your at it you may as well clean up the use of
> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.

a) Dave hasn't commented yet.
b) it's not clear whether Danny meant for the cygming-crtbegin cleanup
to be part of this patch required before push, or if he meant this patch
is ok but Aaron should post a separate patch later for cygming-crtbegin.

Then yours [Paolo]:
>  <toplevel>
>  Ok, but you forgot a piece of a comment in configure.ac.

I haven't seen a revised patch that addresses this.

[Paolo]:
>  <gcc> / mkmap related stuff
>  Right. I guess your patch is then okay from this build maintainer.

But then you [Paolo] have
> I think we should split in three parts. First is what Aaron has,

as-is?

> second is what I suggested

I assume you mean this bit:

>  ... [replace ugly code with]
>  $(call replace_shlib_vars,SOME_BASE_NAME,$(SOME_VAR))
>  using an auxiliary variable definition like this one: [etc.]

as a followon patch?

> last is what you [Charles] suggested.

as yet another, separate patch?

So at best, that's
1) wait for Dave to comment
2) fix the missing comment in <toplevel>/configure.ac
and then push, followed by

patch-1) Danny's requested cleanups to cygming-crtbegin
patch-2) the SHLIB_MKMAP_OPTS stuff $(call replace ...)
patch-3) something along the lines of what I proposed

where patch-3 must wait until patch-2, but patch-1 is independent of
both patch-2 and patch-3.

Can we get all of that in before stage-1 closes, or is some of it
acceptable in stage-3?

--
Chuck

^ permalink raw reply	[flat|nested] 36+ messages in thread

* RE: [PATCH] Build libgcc_s on Windows
  2008-08-25  7:40     ` Charles Wilson
@ 2008-08-26 12:44       ` Dave Korn
  0 siblings, 0 replies; 36+ messages in thread
From: Dave Korn @ 2008-08-26 12:44 UTC (permalink / raw)
  To: 'Charles Wilson'
  Cc: gcc-patches, 'Danny Smith', 'Aaron W. LaFramboise'

Charles Wilson wrote on 25 August 2008 06:22:

> Danny Smith:
>> OK from this Windows maintainer, but wait for Dave Korn to comment. and
>> While your at it you may as well clean up the use of
>> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.
> 
> a) Dave hasn't commented yet.

  Sorry guys, I didn't spot this thread getting started(-patches list kinda
high traffic IYKWIM).  Chuck, thanks for the heads-up.  Will review and
respond late this evening UK time.
 
    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

^ permalink raw reply	[flat|nested] 36+ messages in thread

* RE: [PATCH] Build libgcc_s on Windows
  2008-08-19 16:42 ` Charles Wilson
  2008-08-19 20:34   ` Paolo Bonzini
@ 2008-08-28  3:21   ` Dave Korn
  2008-08-28  8:51     ` Charles Wilson
  1 sibling, 1 reply; 36+ messages in thread
From: Dave Korn @ 2008-08-28  3:21 UTC (permalink / raw)
  To: 'Charles Wilson', gcc-patches

Charles Wilson wrote on 19 August 2008 17:34:

> Charles Wilson wrote (reordered):
> 
>> Here, SHLIB_IMPLIB *could* be named @shlib_base_name@.dll.a to make
>> clear that it is an import library
> 
> On second thought, I think this part is a bad idea. Stick with .a, not
> .dll.a.

  I'd like to understand a good reason for this.  The use of .dll.a is a
system standard and implied by the search ordering in ld.

> Attached should be applied on top of Aaron's existing patch -- but
> again, it is untested. It's just my attempt to demonstrate the idea.

  Not finished reading this (or Aaron's yet), just some initial responses
here.  More later.

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-28  3:21   ` Dave Korn
@ 2008-08-28  8:51     ` Charles Wilson
  2008-08-28 13:04       ` Dave Korn
  0 siblings, 1 reply; 36+ messages in thread
From: Charles Wilson @ 2008-08-28  8:51 UTC (permalink / raw)
  To: Dave Korn; +Cc: gcc-patches

Dave Korn wrote:
> Charles Wilson wrote on 19 August 2008 17:34:
> 
>> Charles Wilson wrote (reordered):
>>
>>> Here, SHLIB_IMPLIB *could* be named @shlib_base_name@.dll.a to make
>>> clear that it is an import library
>> On second thought, I think this part is a bad idea. Stick with .a, not
>> .dll.a.
> 
>   I'd like to understand a good reason for this.  The use of .dll.a is a
> system standard and implied by the search ordering in ld.

With libgcc, the shared library and the static library have different
names, so there is no "search order" confusion.

-lgcc_s  will find only libgcc_s.a; it will not be confused by libgcc.a
Ditto -lgcc

So first, it's not necessary to change .a -> .dll.a

Second, I'm hoping we can get this stuff in under the wire before stage1
closes...and I didn't want to delay things by sending Aaron on a
wild-goose-expedition, chasing after an unnecessary modification with
unknown ramifications. (Yeah, probably won't break anything -- but I
didn't want Aaron to risk further delay.)

--
Chuck

^ permalink raw reply	[flat|nested] 36+ messages in thread

* RE: [PATCH] Build libgcc_s on Windows
  2008-08-28  8:51     ` Charles Wilson
@ 2008-08-28 13:04       ` Dave Korn
  0 siblings, 0 replies; 36+ messages in thread
From: Dave Korn @ 2008-08-28 13:04 UTC (permalink / raw)
  To: 'Charles Wilson'; +Cc: gcc-patches

Charles Wilson wrote on 27 August 2008 05:34:

> Dave Korn wrote:
>> Charles Wilson wrote on 19 August 2008 17:34:
>> 
>>> Charles Wilson wrote (reordered):
>>> 
>>>> Here, SHLIB_IMPLIB *could* be named @shlib_base_name@.dll.a to make
>>>> clear that it is an import library
>>> On second thought, I think this part is a bad idea. Stick with .a, not
>>> .dll.a.
>> 
>>   I'd like to understand a good reason for this.  The use of .dll.a is a
>> system standard and implied by the search ordering in ld.
> 
> With libgcc, the shared library and the static library have different
> names, so there is no "search order" confusion.

  I managed to make it happen when I built a shared libgcc that excluded the
EH machinery and relied on pulling it in from the import lib.  I accept that's
not a conventional setup but we have at least the case of ctors.o which is
excluded from the shared lib and supplied by the static lib.

  There's still no motivation (that I'm aware of) for this.  I don't see why
libgcc should be the one and only DLL on the planet that does things
differently from the rest.  We should stick to standards to avoid confusion;
the import lib for cyg%.dll should be called lib%.dll.a, same as usual, unless
there is some clear and plain benefit from breaking with the convention, and
nobody's explained what that clear benefit is to me yet.

> -lgcc_s  will find only libgcc_s.a; it will not be confused by libgcc.a
> Ditto -lgcc

  They are in fact /both/ present on the commandline, so that static libgcc
can fill in anything not supplied by the DLL.  Check the definition of
LIBGCC_SPEC in Aaron's patch.

> Second, I'm hoping we can get this stuff in under the wire before stage1
> closes...and I didn't want to delay things by sending Aaron on a
> wild-goose-expedition, chasing after an unnecessary modification with
> unknown ramifications. (Yeah, probably won't break anything -- but I
> didn't want Aaron to risk further delay.)

  I could always propose a patch later, but it's a potential back-compat
breaker to make a change like that.


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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-10  9:26                 ` lkcl
@ 2008-09-10 12:32                   ` lkcl
  0 siblings, 0 replies; 36+ messages in thread
From: lkcl @ 2008-09-10 12:32 UTC (permalink / raw)
  To: gcc-patches


this is a good sign.

ls /usr/lib/gcc/i586-mingw32msvc/4.4.0/
crtbegin.o     include-fixed  libgcc_s.a    libssp.la           
libstdc++.la
crtend.o       install-tools  libgcov.a     libssp_nonshared.a   libsupc++.a
crtfastmath.o  libgcc.a       libssp.a      libssp_nonshared.la 
libsupc++.la
include        libgcc_eh.a    libssp.dll.a  libstdc++.a

find . -name "*gcc_s*"
./i586-mingw32msvc/libgcc/shlib/libgcc_s_1.dll
./i586-mingw32msvc/libgcc/shlib/libgcc_s.a
./gcc/libgcc_s.a

-- 
View this message in context: http://www.nabble.com/-PATCH--Build-libgcc_s-on-Windows-tp19037730p19410082.html
Sent from the gcc - patches mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-10  9:09 ` Jay
@ 2008-09-10  9:43   ` lkcl
  0 siblings, 0 replies; 36+ messages in thread
From: lkcl @ 2008-09-10  9:43 UTC (permalink / raw)
  To: gcc-patches




Jay-106 wrote:
> 
> 
> As well, if you are building a cross compiler, please put binutils in your
> source tree too, so that you'll get a cross linker and cross assembler to
> go with your cross compiler. 
> 
> I've never heard of i586-mingw32msvc.
> Going to the target system and running config.guess seems a good way to
> get the target name.
> 
> In future, consider gcc-help instead of gcc-patches.
> 
>  - Jay
> 
> 

sorry! just trying to be helpful, to confirm whether this patch does the job
intended, got a bit lost on the way.  (i586-mingw32msvc is the name of
choice by debian).
-- 
View this message in context: http://www.nabble.com/-PATCH--Build-libgcc_s-on-Windows-tp19037730p19409649.html
Sent from the gcc - patches mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-10  9:11               ` Brian Dessent
@ 2008-09-10  9:26                 ` lkcl
  2008-09-10 12:32                   ` lkcl
  0 siblings, 1 reply; 36+ messages in thread
From: lkcl @ 2008-09-10  9:26 UTC (permalink / raw)
  To: gcc-patches


:) brian, thank you: yep, just discovered that (found and
looked at MingwCrossBuild.sh).

will let you know how it gets on, now that i've the right tools duh.


Brian Dessent wrote:
> 
> lkcl wrote:
> 
>> /mnt/video/src/git-clone-gcc/gcc/build/./gcc/as: line 76: exec: : not
>> found
> 
> It seems you don't have a cross-assembler (part of binutils) correctly
> installed.  It should be one of:
> 
> - $target-as found in $exec_prefix/$target/bin/
> - $target-as found in PATH
> - part of a combined tree
> - pointed to by --with-as
> 
> Brian
> 
> 

-- 
View this message in context: http://www.nabble.com/-PATCH--Build-libgcc_s-on-Windows-tp19037730p19409521.html
Sent from the gcc - patches mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-10  8:49             ` lkcl
  2008-09-10  9:11               ` Brian Dessent
@ 2008-09-10  9:19               ` lkcl
  1 sibling, 0 replies; 36+ messages in thread
From: lkcl @ 2008-09-10  9:19 UTC (permalink / raw)
  To: gcc-patches


sorry - ignore! mingw32 binutils not installed.


lkcl wrote:
> 
> folks, hi,
> 
> downloaded from a recommended git-clone of svn, and am getting the
> following errors, using this:
>                                                   
> 

-- 
View this message in context: http://www.nabble.com/-PATCH--Build-libgcc_s-on-Windows-tp19037730p19409498.html
Sent from the gcc - patches mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-10  8:49             ` lkcl
@ 2008-09-10  9:11               ` Brian Dessent
  2008-09-10  9:26                 ` lkcl
  2008-09-10  9:19               ` lkcl
  1 sibling, 1 reply; 36+ messages in thread
From: Brian Dessent @ 2008-09-10  9:11 UTC (permalink / raw)
  To: lkcl; +Cc: gcc-patches

lkcl wrote:

> /mnt/video/src/git-clone-gcc/gcc/build/./gcc/as: line 76: exec: : not found

It seems you don't have a cross-assembler (part of binutils) correctly
installed.  It should be one of:

- $target-as found in $exec_prefix/$target/bin/
- $target-as found in PATH
- part of a combined tree
- pointed to by --with-as

Brian

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
       [not found] <1221035558.13510.ezmlm@gcc.gnu.org>
@ 2008-09-10  9:09 ` Jay
  2008-09-10  9:43   ` lkcl
  0 siblings, 1 reply; 36+ messages in thread
From: Jay @ 2008-09-10  9:09 UTC (permalink / raw)
  To: lkcl, gcc-patches


--Forwarded Message Attachment--
> From: lkcl
> Subject: Re: [PATCH] Build libgcc_s on Windows

 > #!/bin/sh 
 >     cd build                            \ 
 >         && ../configure -v         \ 
 >                     --prefix=/usr               \ 
 >                     --target=i586-mingw32msvc          \ 
 >                     --enable-languages=c,c++        \ 
 >                     --enable-threads            \ 
 >                     --enable-sjlj-exceptions        \ 
 >                     --disable-multilib          \ 
 >                    --enable-version-specific-runtime-libs 

 > /mnt/video/src/git-clone-gcc/gcc/build/./gcc/as: line 76: exec: : not foundconfigure:2418: $? = 1 


Try building in a directory that is not a subdirectory of the source.

Such as:

  set -e  
  set -x  
  mkdir /obj 
  mkdir /obj/gcc.1  
  cd /obj/gcc.1  
  /src/gcc/configure blah blah blah  
  make  

As well, if you are building a cross compiler, please put binutils in your source tree too, so that you'll get a cross linker and cross assembler to go with your cross compiler. 

I recommend the learning curve that I followed, usually. :)
First make sure you can build "native", then try building "cross", then "Canadian".
If you are going to build "Canadian", install the the cross tools beforehand, for it to use.
And research "sysroot" (configure ought to fail much much earlier.. arg...) 

 mkdir /obj 
 mkdir /obj/gcc.native 
 cd /obj/gcc.native 
 /src/gcc/configure -disable-bootstrap --enable-languages=c,c++ -disable-multilib 
 make

 mkdir /obj/gcc.cross  
 cd /obj/gcc.cross  
 /src/gcc/configure -disable-bootstrap -target  i686-pc-mingw32 -disable-bootstrap --enable-languages=c,c++ -disable-multilib 
 make

Also, given my experience, avoid making up target aliases. Use the canonical names.
I guess that is heresy/hearsay at this point. I should try it again and see what the problems were.
One is that building libgcc for Solaris wants the platform precise enough to have a version, e.g. 2.10.
The other, the more heretical, is that I thought I saw places that wanted user-given and canonical to match,
therefore...

I've never heard of i586-mingw32msvc.
Going to the target system and running config.guess seems a good way to get the target name.

In future, consider gcc-help instead of gcc-patches.

 - Jay

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-09 19:57           ` lkcl
@ 2008-09-10  8:49             ` lkcl
  2008-09-10  9:11               ` Brian Dessent
  2008-09-10  9:19               ` lkcl
  0 siblings, 2 replies; 36+ messages in thread
From: lkcl @ 2008-09-10  8:49 UTC (permalink / raw)
  To: gcc-patches


folks, hi,

downloaded from a recommended git-clone of svn, and am getting the
following errors, using this:

#!/bin/sh
    cd build                            \
        && ../configure -v         \
                    --prefix=/usr               \
                    --target=i586-mingw32msvc          \
                    --enable-languages=c,c++        \
                    --enable-threads            \
                    --enable-sjlj-exceptions        \
                    --disable-multilib          \
                    --enable-version-specific-runtime-libs

which i copied out of the debian package for mingw32 
(so we know it works for gcc 4.1)



make[2]: Leaving directory `/mnt/video/src/git-clone-gcc/gcc/build/gcc'
Checking multilib configuration for libgcc...
mkdir -p -- i586-mingw32msvc/libgcc
Configuring in i586-mingw32msvc/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i586-pc-mingw32msvc
checking for i586-mingw32msvc-ar... i586-mingw32msvc-ar
checking for i586-mingw32msvc-lipo... i586-mingw32msvc-lipo
checking for i586-mingw32msvc-nm...
/mnt/video/src/git-clone-gcc/gcc/build/./gcc/nm
checking for i586-mingw32msvc-ranlib... i586-mingw32msvc-ranlib
checking for i586-mingw32msvc-strip... i586-mingw32msvc-strip
checking whether ln -s works... yes
checking for i586-mingw32msvc-gcc...
/mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include
checking for suffix of object files... configure: error: in
`/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/mnt/video/src/git-clone-gcc/gcc/build'
make: *** [all] Error 2

config.log in build/i586-mingw32msvc/libgcc contains this:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU C Runtime Library configure 1.0, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ /mnt/video/src/git-clone-gcc/gcc/libgcc/configure
--cache-file=./config.cache --with-cross-host=x86_64-unknown-linux-gnu -v
--prefix=/usr --enable-threads --enable-sjlj-exceptions --disable-multilib
--enable-version-specific-runtime-libs --enable-languages=c,c++
--program-transform-name=s,^,i586-mingw32msvc-,
--with-target-subdir=i586-mingw32msvc --build=x86_64-unknown-linux-gnu
--host=i586-mingw32msvc --target=i586-mingw32msvc --srcdir=../../../libgcc

## --------- ##
## Platform. ##
## --------- ##

hostname = gonzalez
uname -m = x86_64
uname -r = 2.6.24-1-amd64
uname -s = Linux
uname -v = #1 SMP Sat May 10 09:28:10 UTC 2008

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/lib/ccache
PATH: /usr/lib/ccache
PATH: /home/lkcl/src/flex/bin
PATH: /home/lkcl/bin
PATH: /usr/lib/ccache
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/games


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1199: creating cache ./config.cache
configure:1388: checking for --enable-version-specific-runtime-libs
configure:1403: result: yes
configure:1435: checking for a BSD-compatible install
configure:1490: result: /usr/bin/install -c
configure:1506: checking for gawk
configure:1522: found /usr/bin/gawk
configure:1532: result: gawk
configure:1555: checking build system type
configure:1573: result: x86_64-unknown-linux-gnu
configure:1581: checking host system type
configure:1595: result: i586-pc-mingw32msvc
configure:1654: checking for i586-mingw32msvc-ar
configure:1680: result: i586-mingw32msvc-ar
configure:1733: checking for i586-mingw32msvc-lipo
configure:1759: result: i586-mingw32msvc-lipo
configure:1813: checking for i586-mingw32msvc-nm
configure:1839: result: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/nm
configure:1892: checking for i586-mingw32msvc-ranlib
configure:1918: result: i586-mingw32msvc-ranlib
configure:1972: checking for i586-mingw32msvc-strip
configure:1998: result: i586-mingw32msvc-strip
configure:2049: checking whether ln -s works
configure:2053: result: yes
configure:2070: checking for i586-mingw32msvc-gcc
configure:2096: result: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include
configure:2380: checking for C compiler version
configure:2383: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include
--version </dev/null >&5
xgcc (GCC) 4.4.0 20080909 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2386: $? = 0
configure:2388: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include -v
</dev/null >&5
Reading specs from /mnt/video/src/git-clone-gcc/gcc/build/./gcc/specs
Target: i586-mingw32msvc
Configured with: ../configure -v --prefix=/usr --target=i586-mingw32msvc
--enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions
--disable-multilib --enable-version-specific-runtime-libs
Thread model: win32
gcc version 4.4.0 20080909 (experimental) (GCC) 
configure:2391: $? = 0
configure:2393: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include -V
</dev/null >&5
xgcc: '-V' must come at the start of the command line
configure:2396: $? = 1
configure:2415: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include -o
conftest -g -O2     conftest.c  >&5
/mnt/video/src/git-clone-gcc/gcc/build/./gcc/as: line 76: exec: : not found
configure:2418: $? = 1
configure:2590: checking for suffix of object files
configure:2611: /mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include -c
-g -O2    conftest.c >&5
/mnt/video/src/git-clone-gcc/gcc/build/./gcc/as: line 76: exec: : not found
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2627: error: in
`/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/libgcc':
configure:2630: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=x86_64-unknown-linux-gnu
ac_cv_build_alias=x86_64-unknown-linux-gnu
ac_cv_env_CC_set=set
ac_cv_env_CC_value='/mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include'
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-g -O2  '
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=x86_64-unknown-linux-gnu
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=i586-mingw32msvc
ac_cv_env_target_alias_set=set
ac_cv_env_target_alias_value=i586-mingw32msvc
ac_cv_host=i586-pc-mingw32msvc
ac_cv_host_alias=i586-mingw32msvc
ac_cv_prog_AR=i586-mingw32msvc-ar
ac_cv_prog_AWK=gawk
ac_cv_prog_CC='/mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include'
ac_cv_prog_LIPO=i586-mingw32msvc-lipo
ac_cv_prog_NM=/mnt/video/src/git-clone-gcc/gcc/build/./gcc/nm
ac_cv_prog_RANLIB=i586-mingw32msvc-ranlib
ac_cv_prog_STRIP=i586-mingw32msvc-strip

## ----------------- ##
## Output variables. ##
## ----------------- ##

AR='i586-mingw32msvc-ar'
AWK='gawk'
CC='/mnt/video/src/git-clone-gcc/gcc/build/./gcc/xgcc
-B/mnt/video/src/git-clone-gcc/gcc/build/./gcc/
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/mingw
-L/mnt/video/src/git-clone-gcc/gcc/build/i586-mingw32msvc/winsup/w32api/lib
-isystem /mnt/video/src/git-clone-gcc/gcc/winsup/mingw/include -isystem
/mnt/video/src/git-clone-gcc/gcc/winsup/w32api/include
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include'
CFLAGS='-g -O2  '
CPP=''
CPPFLAGS=''
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
INSTALL_DATA='/usr/bin/install -c -m 644'
INSTALL_PROGRAM='/usr/bin/install -c'
INSTALL_SCRIPT='/usr/bin/install -c'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LIPO='i586-mingw32msvc-lipo'
LN_S='ln -s'
LTLIBOBJS=''
NM='/mnt/video/src/git-clone-gcc/gcc/build/./gcc/nm'
OBJEXT=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME='GNU C Runtime Library'
PACKAGE_STRING='GNU C Runtime Library 1.0'
PACKAGE_TARNAME='libgcc'
PACKAGE_VERSION='1.0'
PATH_SEPARATOR=':'
RANLIB='i586-mingw32msvc-ranlib'
SHELL='/bin/sh'
STRIP='i586-mingw32msvc-strip'
ac_ct_AR=''
ac_ct_CC=''
ac_ct_LIPO=''
ac_ct_NM=''
ac_ct_RANLIB=''
ac_ct_STRIP=''
asm_hidden_op=''
bindir='${exec_prefix}/bin'
build='x86_64-unknown-linux-gnu'
build_alias='x86_64-unknown-linux-gnu'
build_cpu='x86_64'
build_libsubdir='build-x86_64-unknown-linux-gnu'
build_os='linux-gnu'
build_subdir='build-x86_64-unknown-linux-gnu'
build_vendor='unknown'
datadir='${prefix}/share'
decimal_float=''
enable_decimal_float=''
enable_shared='yes'
exec_prefix='NONE'
extra_parts=''
fixed_point=''
host='i586-pc-mingw32msvc'
host_alias='i586-mingw32msvc'
host_cpu='i586'
host_noncanonical='i586-mingw32msvc'
host_os='mingw32msvc'
host_subdir='.'
host_vendor='pc'
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
libgcc_topdir='../../../libgcc/..'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='/usr'
program_transform_name='s,^,i586-mingw32msvc-,'
sbindir='${exec_prefix}/sbin'
set_have_cc_tls=''
sharedstatedir='${prefix}/com'
slibdir='$(libsubdir)'
sysconfdir='${prefix}/etc'
target_alias='i586-mingw32msvc'
target_subdir='i586-mingw32msvc'
tmake_file=''
vis_hide=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME "GNU C Runtime Library"
#define PACKAGE_STRING "GNU C Runtime Library 1.0"
#define PACKAGE_TARNAME "libgcc"
#define PACKAGE_VERSION "1.0"

configure: exit 1

./gcc/as contains the following:

ORIGINAL_AS_FOR_TARGET=""
ORIGINAL_LD_FOR_TARGET=""
ORIGINAL_NM_FOR_TARGET=""
exeext=
fast_install=yes
objdir=.libs

invoked=`basename "$0"`
case "$invoked" in
  as)
    original=$ORIGINAL_AS_FOR_TARGET
    prog=as-new$exeext
    dir=gas
    ;;
  collect-ld)
    original=$ORIGINAL_LD_FOR_TARGET
    prog=ld-new$exeext
    dir=ld
    ;;
  nm)
    original=$ORIGINAL_NM_FOR_TARGET
    prog=nm-new$exeext
    dir=binutils
    ;;
esac

case "$original" in
  ../*)
    # compute absolute path of the location of this script
    tdir=`dirname "$0"`
    scriptdir=`cd "$tdir" && pwd`

    if test -x $scriptdir/../$dir/$prog; then
      test "$fast_install" = yes || exec $scriptdir/../$dir/$prog ${1+"$@"}

      # if libtool did everything it needs to do, there's a fast path
      lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
      test -x $lt_prog && exec $lt_prog ${1+"$@"}

      # libtool has not relinked ld-new yet, but we cannot just use the
      # previous stage (because then the relinking would just never
happen!).
      # So we take extra care to use prev-ld/ld-new *on recursive calls*.
      test x"$LT_RCU" = x"1" && exec $scriptdir/../prev-$dir/$prog ${1+"$@"}

      LT_RCU=1; export LT_RCU
      $scriptdir/../$dir/$prog ${1+"$@"}
      result=$?
      exit $result

    else
      exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
    fi
    ;;
  *)
    exec "$original" ${1+"$@"}
    ;;
esac
                                                  
-- 
View this message in context: http://www.nabble.com/-PATCH--Build-libgcc_s-on-Windows-tp19037730p19409014.html
Sent from the gcc - patches mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-04  3:52         ` Danny Smith
  2008-09-04  6:25           ` NightStrike
  2008-09-04  8:31           ` Kai Tietz
@ 2008-09-09 19:57           ` lkcl
  2008-09-10  8:49             ` lkcl
  2 siblings, 1 reply; 36+ messages in thread
From: lkcl @ 2008-09-09 19:57 UTC (permalink / raw)
  To: gcc-patches




Danny Smith-5 wrote:
> 
>> able to find all necessary symbols. NightStrike, could you try this patch
>> if it is working for you?
> 
>>        * config/i386/t-mingw32 (SHLIB_LC): Change order of import
>> libraries.
> 
> This is OK and is needed for  32-bit mingw runtime as well.  Please commit
> Thanks
> Danny
> 
> 

folks, i'm cross-compiling webkit host debian-amd64 target win32,
and mingw32-3.4.5 actually _segfaults_ at the ld stage due to
missing gcc_s (as does mingw32-4.1)

i'm presently doing an svn checkout and will get back to you with
a second confirmation as to whether this patched version does
the job.

l.
-- 
View this message in context: http://www.nabble.com/-PATCH--Build-libgcc_s-on-Windows-tp19037730p19398266.html
Sent from the gcc - patches mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-04  3:52         ` Danny Smith
  2008-09-04  6:25           ` NightStrike
@ 2008-09-04  8:31           ` Kai Tietz
  2008-09-09 19:57           ` lkcl
  2 siblings, 0 replies; 36+ messages in thread
From: Kai Tietz @ 2008-09-04  8:31 UTC (permalink / raw)
  To: Danny Smith; +Cc: Aaron W. LaFramboise, gcc-patches, Kai Tietz, NightStrike

"Danny Smith" <dansmister@gmail.com> wrote on 04.09.2008 04:51:13:

> > Fine. I changed the link libraries order of SHLIB_LC. The import 
libraries
> > kernel32 and co. needs to be put at the end of SHLIB_LC, so that ld is
> > able to find all necessary symbols. NightStrike, could you try this 
patch
> > if it is working for you?
> >
> > ChangeLog
> >
> > 2008-09-03  Kai Tietz  <kai.tietz@onevision.com>
> >
> >        * gthr-win32.h (CONST_CAST2): Added.
> 
> This part is not needed  since it was fixed at  r139927
> http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00085.html
> 
> >        * config/i386/t-mingw32 (SHLIB_LC): Change order of import
> > libraries.
> 
> This is OK and is needed for  32-bit mingw runtime as well.  Please 
commit
> Thanks
> Danny

Committed at revision 139977.

Thanks,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-04  6:25           ` NightStrike
@ 2008-09-04  8:00             ` Danny Smith
  0 siblings, 0 replies; 36+ messages in thread
From: Danny Smith @ 2008-09-04  8:00 UTC (permalink / raw)
  To: NightStrike; +Cc: Kai Tietz, Aaron W. LaFramboise, gcc-patches, Kai Tietz

On Thu, Sep 4, 2008 at 6:19 PM, NightStrike <nightstrike@gmail.com> wrote:
> On 9/3/08, Danny Smith <dansmister@gmail.com> wrote:
>> >        * gthr-win32.h (CONST_CAST2): Added.
>>
>> This part is not needed  since it was fixed at  r139927
>> http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00085.html
>
> I don't mean to question things, but I am instead more curious.  Why
> define it here as opposed to ensuring that system.h gets included?
> That way, you don't have the same thing defined in two different
> places.
>
gthr-win32.h is a public header that gets installed as gthr-default.h
in libstc++ include tree.
"system.h" is an internal header for gcc build.

Danny

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-04  3:52         ` Danny Smith
@ 2008-09-04  6:25           ` NightStrike
  2008-09-04  8:00             ` Danny Smith
  2008-09-04  8:31           ` Kai Tietz
  2008-09-09 19:57           ` lkcl
  2 siblings, 1 reply; 36+ messages in thread
From: NightStrike @ 2008-09-04  6:25 UTC (permalink / raw)
  To: Danny Smith; +Cc: Kai Tietz, Aaron W. LaFramboise, gcc-patches, Kai Tietz

On 9/3/08, Danny Smith <dansmister@gmail.com> wrote:
> >        * gthr-win32.h (CONST_CAST2): Added.
>
> This part is not needed  since it was fixed at  r139927
> http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00085.html

I don't mean to question things, but I am instead more curious.  Why
define it here as opposed to ensuring that system.h gets included?
That way, you don't have the same thing defined in two different
places.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-03  9:51       ` Kai Tietz
  2008-09-03 18:03         ` NightStrike
@ 2008-09-04  3:52         ` Danny Smith
  2008-09-04  6:25           ` NightStrike
                             ` (2 more replies)
  1 sibling, 3 replies; 36+ messages in thread
From: Danny Smith @ 2008-09-04  3:52 UTC (permalink / raw)
  To: Kai Tietz; +Cc: NightStrike, Aaron W. LaFramboise, gcc-patches, Kai Tietz

> Fine. I changed the link libraries order of SHLIB_LC. The import libraries
> kernel32 and co. needs to be put at the end of SHLIB_LC, so that ld is
> able to find all necessary symbols. NightStrike, could you try this patch
> if it is working for you?
>
> ChangeLog
>
> 2008-09-03  Kai Tietz  <kai.tietz@onevision.com>
>
>        * gthr-win32.h (CONST_CAST2): Added.

This part is not needed  since it was fixed at  r139927
http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00085.html

>        * config/i386/t-mingw32 (SHLIB_LC): Change order of import
> libraries.

This is OK and is needed for  32-bit mingw runtime as well.  Please commit
Thanks
Danny

>
>
>
> Cheers,
> Kai

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-03  9:51       ` Kai Tietz
@ 2008-09-03 18:03         ` NightStrike
  2008-09-04  3:52         ` Danny Smith
  1 sibling, 0 replies; 36+ messages in thread
From: NightStrike @ 2008-09-03 18:03 UTC (permalink / raw)
  To: Kai Tietz
  Cc: Aaron W. LaFramboise, Danny Smith, gcc-patches, Kai Tietz,
	libstdc++,
	mook.gcc

On 9/3/08, Kai Tietz <Kai.Tietz@onevision.com> wrote:
> NightStrike <nightstrike@gmail.com> wrote on 02.09.2008 17:30:48:
>
> > On 9/2/08, Kai Tietz <Kai.Tietz@onevision.com> wrote:
> > > Hi,
> > >
> > > by this patch the build problems about gthr-win32.c are fixed for me.
> The
> > > problem is that in libgcc the header system.h isn't inherited and so
> > > CONST_CAST2 isn't declared. I add to gthr-win32.h an optional
> declaration
> > > of this macro.
> > >
> > > NightStrike, does this patch works for you?
> > This patch brings us back to the failures of 139837 and 139838.  So it
> > fixes the failure of 139839, but the other remains.
>
> Fine. I changed the link libraries order of SHLIB_LC. The import libraries
> kernel32 and co. needs to be put at the end of SHLIB_LC, so that ld is
> able to find all necessary symbols. NightStrike, could you try this patch
> if it is working for you?
>
> ChangeLog
>
> 2008-09-03  Kai Tietz  <kai.tietz@onevision.com>
>
>        * gthr-win32.h (CONST_CAST2): Added.
>        * config/i386/t-mingw32 (SHLIB_LC): Change order of import
> libraries.


With this patch, I can build the entire toolchain again.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-02 16:30     ` NightStrike
@ 2008-09-03  9:51       ` Kai Tietz
  2008-09-03 18:03         ` NightStrike
  2008-09-04  3:52         ` Danny Smith
  0 siblings, 2 replies; 36+ messages in thread
From: Kai Tietz @ 2008-09-03  9:51 UTC (permalink / raw)
  To: NightStrike
  Cc: Aaron W. LaFramboise, Danny Smith, gcc-patches, Kai Tietz, libstdc++

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

NightStrike <nightstrike@gmail.com> wrote on 02.09.2008 17:30:48:

> On 9/2/08, Kai Tietz <Kai.Tietz@onevision.com> wrote:
> > Hi,
> >
> > by this patch the build problems about gthr-win32.c are fixed for me. 
The
> > problem is that in libgcc the header system.h isn't inherited and so
> > CONST_CAST2 isn't declared. I add to gthr-win32.h an optional 
declaration
> > of this macro.
> >
> > NightStrike, does this patch works for you?
> This patch brings us back to the failures of 139837 and 139838.  So it
> fixes the failure of 139839, but the other remains.

Fine. I changed the link libraries order of SHLIB_LC. The import libraries 
kernel32 and co. needs to be put at the end of SHLIB_LC, so that ld is 
able to find all necessary symbols. NightStrike, could you try this patch 
if it is working for you?

ChangeLog

2008-09-03  Kai Tietz  <kai.tietz@onevision.com>

        * gthr-win32.h (CONST_CAST2): Added.
        * config/i386/t-mingw32 (SHLIB_LC): Change order of import 
libraries.



Cheers,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.


[-- Attachment #2: w64-gthr.txt --]
[-- Type: text/plain, Size: 1386 bytes --]

Index: gcc/gcc/gthr-win32.h
===================================================================
--- gcc.orig/gcc/gthr-win32.h
+++ gcc/gcc/gthr-win32.h
@@ -37,6 +37,17 @@ Software Foundation, 51 Franklin Street,
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q; TOTYPE _nq;})(X))._nq)
 #endif
 
+/* Make sure CONST_CAST2 (origin in system.h) is declared.  */
+#ifndef CONST_CAST2
+#if defined(__GNUC__) && GCC_VERSION > 4000
+/* GCC 4.0.x has a bug where it may ICE on this expression,
+   so does GCC 3.4.x (PR17436).  */
+#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q; TOTYPE _nq;})(X))._nq)
+#else
+#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((TOTYPE)(FROMTYPE)(X))
+#endif
+#endif
+
 /* Windows32 threads specific definitions. The windows32 threading model
    does not map well into pthread-inspired gcc's threading model, and so
    there are caveats one needs to be aware of.
Index: gcc/gcc/config/i386/t-mingw32
===================================================================
--- gcc.orig/gcc/config/i386/t-mingw32
+++ gcc/gcc/config/i386/t-mingw32
@@ -2,4 +2,4 @@
 NATIVE_SYSTEM_HEADER_DIR = /mingw/include
 
 # MinGW-specific parts of LIB_SPEC
-SHLIB_LC += -lmingw32 -lmingwex -lmoldname -lmsvcrt
+SHLIB_LC = -lmingw32 -lmingwex -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32
=

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-02 12:03   ` Kai Tietz
@ 2008-09-02 16:30     ` NightStrike
  2008-09-03  9:51       ` Kai Tietz
  0 siblings, 1 reply; 36+ messages in thread
From: NightStrike @ 2008-09-02 16:30 UTC (permalink / raw)
  To: Kai Tietz
  Cc: Aaron W. LaFramboise, Danny Smith, gcc-patches, Kai Tietz, libstdc++

On 9/2/08, Kai Tietz <Kai.Tietz@onevision.com> wrote:
> Hi,
>
> by this patch the build problems about gthr-win32.c are fixed for me. The
> problem is that in libgcc the header system.h isn't inherited and so
> CONST_CAST2 isn't declared. I add to gthr-win32.h an optional declaration
> of this macro.
>
> NightStrike, does this patch works for you?
>
> ChangeLog
>
> 2008-09-02  Kai Tietz  <kai.tietz@onevision.com>
>
>        * gthr-win32.h (CONST_CAST2): Added.

This patch brings us back to the failures of 139837 and 139838.  So it
fixes the failure of 139839, but the other remains.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-09-02  6:40 ` NightStrike
@ 2008-09-02 12:03   ` Kai Tietz
  2008-09-02 16:30     ` NightStrike
  0 siblings, 1 reply; 36+ messages in thread
From: Kai Tietz @ 2008-09-02 12:03 UTC (permalink / raw)
  To: NightStrike
  Cc: Aaron W. LaFramboise, Danny Smith, gcc-patches, Kai Tietz, libstdc++

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

Hi,

by this patch the build problems about gthr-win32.c are fixed for me. The 
problem is that in libgcc the header system.h isn't inherited and so 
CONST_CAST2 isn't declared. I add to gthr-win32.h an optional declaration 
of this macro.

NightStrike, does this patch works for you?

ChangeLog

2008-09-02  Kai Tietz  <kai.tietz@onevision.com>

        * gthr-win32.h (CONST_CAST2): Added.


Cheers,
Kai


[-- Attachment #2: w64-gthr.txt --]
[-- Type: text/plain, Size: 900 bytes --]

Index: gcc/gcc/gthr-win32.h
===================================================================
--- gcc.orig/gcc/gthr-win32.h
+++ gcc/gcc/gthr-win32.h
@@ -32,6 +32,17 @@ Software Foundation, 51 Franklin Street,
 #ifndef GCC_GTHR_WIN32_H
 #define GCC_GTHR_WIN32_H
 
+/* Make sure CONST_CAST2 (origin in system.h) is declared.  */
+#ifndef CONST_CAST2
+#if defined(__GNUC__) && GCC_VERSION > 4000
+/* GCC 4.0.x has a bug where it may ICE on this expression,
+   so does GCC 3.4.x (PR17436).  */
+#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q; TOTYPE _nq;})(X))._nq)
+#else
+#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((TOTYPE)(FROMTYPE)(X))
+#endif
+#endif
+
 /* Windows32 threads specific definitions. The windows32 threading model
    does not map well into pthread-inspired gcc's threading model, and so
    there are caveats one needs to be aware of.
=

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-18 19:08 Aaron W. LaFramboise
  2008-08-19  5:16 ` Danny Smith
  2008-08-19  8:05 ` Paolo Bonzini
@ 2008-09-02  6:40 ` NightStrike
  2008-09-02 12:03   ` Kai Tietz
  2 siblings, 1 reply; 36+ messages in thread
From: NightStrike @ 2008-09-02  6:40 UTC (permalink / raw)
  To: Aaron W. LaFramboise
  Cc: gcc-patches, Danny Smith, libstdc++, Kai Tietz, Kai Tietz

On 8/18/08, Aaron W. LaFramboise <aaronavay62@aaronwl.com> wrote:
> This patch enables building libgcc_s as a DLL on MinGW and Cygwin.  This
> allows throwing exceptions across DLL boundaries when using a shared
> libgcc_s.
>
> It needs approval from toplevel configure, gcc/mkmap, Windows and libstdc++
> maintainers.
>
> It was tested by a bootstrap and testsuite run on i386-pc-mingw32, as well
> as manually to make sure it works.


From what I can tell, this patch was committed to revision 139837.
This revision breaks the build for x86_64-pc-mingw32.  139836 works
fine.  139837 and 19838 die for the same reason.  139839 then dies for
a different reason.  Here is the error for 139837:

ln -s libgcc.map libgcc.map.def && if [ ! -d ./shlib ]; then mkdir
./shlib else true; fi &&
/home/nightstrike/build/gcc-svn/build-x86_64-pc-linux/./gcc/xgcc
-B/home/nightstrike/build/gcc-svn/build-x86_64-pc-linux/./gcc/
-L/home/nightstrike/build/gcc-svn/build-x86_64-pc-linux/x86_64-pc-mingw32/winsup/mingw
-L/home/nightstrike/build/gcc-svn/build-x86_64-pc-linux/x86_64-pc-mingw32/winsup/w32api/lib
-isystem /home/nightstrike/build/gcc-svn/gcc/winsup/mingw/include
-isystem /home/nightstrike/build/gcc-svn/gcc/winsup/w32api/include
-B/home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/bin/
-B/home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/lib/
-isystem /home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/include
-isystem /home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/sys-include
-O2 -I../../gcc/gcc/../winsup/w32api/include -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include   -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs
libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.a.tmp -o
./shlib/libgcc_s_1.dll.tmp -g -O2 -B./ _chkstk_s.o _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
_ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o
_addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o
_powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o
_divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o
_udiv_w_sdiv_s.o _udivmoddi4_s.o gthr-win32_s.o unwind-dw2_s.o
unwind-dw2-fde_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o
emutls_s.o -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32
-lmingwex -lmoldname -lmsvcrt &&
/home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/bin/ar -r
./shlib/libgcc_s.a.tmp _chkstk.o _ctors.o gthr-win32.o && if [ -f
./shlib/libgcc_s_1.dll ]; then mv -f ./shlib/libgcc_s_1.dll
./shlib/libgcc_s_1.dll.backup; else true; fi && mv
./shlib/libgcc_s_1.dll.tmp ./shlib/libgcc_s_1.dll && mv
./shlib/libgcc_s.a.tmp ./shlib/libgcc_s.a
Creating library file: ./shlib/libgcc_s.a.tmp
/home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/lib/libmingw32.a(lib64_libmingw32_a-gs_support.o):
In function `__report_gsfailure':
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:94:
undefined reference to `__imp__RtlCaptureContext'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:96:
undefined reference to `_RtlLookupFunctionEntry'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:99:
undefined reference to `_RtlVirtualUnwind'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:125:
undefined reference to `__imp__SetUnhandledExceptionFilter'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:126:
undefined reference to `__imp__UnhandledExceptionFilter'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:127:
undefined reference to `__imp__GetCurrentProcess'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:127:
undefined reference to `__imp__TerminateProcess'
/home/nightstrike/root-x86_64-pc-linux/x86_64-pc-mingw32/lib/libmingw32.a(lib64_libmingw32_a-gs_support.o):
In function `__security_init_cookie':
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:53:
undefined reference to `__imp__GetSystemTimeAsFileTime'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:61:
undefined reference to `__imp__GetCurrentProcessId'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:63:
undefined reference to `__imp__GetTickCount'
/home/nightstrike/build/mingw/build-x86_64-pc-linux/../mingw-w64-crt/crt64/gs_support.c:65:
undefined reference to `__imp__QueryPerformanceCounter'
collect2: ld returned 1 exit status




And this is for 139839:


/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/obj/./gcc/xgcc
-B/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/obj/./gcc/
-L/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/obj/x86_64-pc-mingw32/winsup/mingw
-L/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/obj/x86_64-pc-mingw32/winsup/w32api/lib
-isystem /mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/gcc/winsup/mingw/include
-isystem /mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/gcc/winsup/w32api/include
-B/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/root/x86_64-pc-mingw32/bin/
-B/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/root/x86_64-pc-mingw32/lib/
-isystem /mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/root/x86_64-pc-mingw32/include
-isystem /mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/root/x86_64-pc-mingw32/sys-include
-g -O0 -O2 -I../../gcc/gcc/../winsup/w32api/include -g -O0 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include   -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include
-DHAVE_CC_TLS -o gthr-win32.o -MT gthr-win32.o -MD -MP -MF
gthr-win32.dep -fexceptions -c
../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c
In file included from ../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c:40:
../../../gcc/libgcc/../gcc/gthr-win32.h: In function
‘__gthread_setspecific’:
../../../gcc/libgcc/../gcc/gthr-win32.h:458: warning: implicit
declaration of function ‘CONST_CAST2’
../../../gcc/libgcc/../gcc/gthr-win32.h:458: error: expected
expression before ‘void’
../../../gcc/libgcc/../gcc/gthr-win32.h:458: warning: passing argument
2 of ‘TlsSetValue’ makes pointer from integer without a cast
/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/root/x86_64-pc-mingw32/include/winbase.h:1617:
note: expected ‘LPVOID’ but argument is of type ‘int’
../../../gcc/libgcc/../gcc/gthr-win32.h:456: warning: unused parameter ‘ptr’
../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c: In function
‘__gthr_win32_setspecific’:
../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c:144: error:
expected expression before ‘void’
../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c:144: warning:
passing argument 2 of ‘TlsSetValue’ makes pointer from integer
without a cast
/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/root/x86_64-pc-mingw32/include/winbase.h:1617:
note: expected ‘LPVOID’ but argument is of type ‘int’
../../../gcc/libgcc/../gcc/config/i386/gthr-win32.c:142: warning:
unused parameter ‘ptr’
make[2]: *** [gthr-win32.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/obj/x86_64-pc-mingw32/libgcc'
make[1]: Leaving directory
`/mnt/sdb1/buildbot/linuxvm-slave/linux-i386/build/gcc/obj'
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
program finished with exit code 2

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
@ 2008-08-28 12:56 Charles Wilson
  0 siblings, 0 replies; 36+ messages in thread
From: Charles Wilson @ 2008-08-28 12:56 UTC (permalink / raw)
  To: GCC Patches

Brian Dessent wrote:
> Danny Smith wrote:
> 
>> The "downside" of this is that  we  force user to always add
>> "-shared-libgcc" to gcc command line rather than allow the clever user
>> to rely on a libgcc.dll.a vs libgcc.a  link order diff.
> 
> I'm not sure that will work in the case of Cygwin then, since the plan
> as I understand it is to behave like Linux: shared libgcc is the default
> if not specified, and must be overridden with -static-libgcc.

IIRC, this is one of the differences between mingw and cygwin with
regards to shared libgcc: for the former, they decided that static
runtimes should be the default, given the strong desire of most mingw
users for so-called 'monolithic' executables.  On cygwin, of course, the
more like unix the better, so shared libgcc should be the default.

--
Chuck

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-28  9:15         ` Danny Smith
@ 2008-08-28  9:35           ` Brian Dessent
  0 siblings, 0 replies; 36+ messages in thread
From: Brian Dessent @ 2008-08-28  9:35 UTC (permalink / raw)
  To: Danny Smith; +Cc: Dave Korn, Aaron W. LaFramboise, gcc-patches, libstdc++

Danny Smith wrote:

> The "downside" of this is that  we  force user to always add
> "-shared-libgcc" to gcc command line rather than allow the clever user
> to rely on a libgcc.dll.a vs libgcc.a  link order diff.

I'm not sure that will work in the case of Cygwin then, since the plan
as I understand it is to behave like Linux: shared libgcc is the default
if not specified, and must be overridden with -static-libgcc.

Brian

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-28  4:15       ` Dave Korn
@ 2008-08-28  9:15         ` Danny Smith
  2008-08-28  9:35           ` Brian Dessent
  0 siblings, 1 reply; 36+ messages in thread
From: Danny Smith @ 2008-08-28  9:15 UTC (permalink / raw)
  To: Dave Korn; +Cc: Aaron W. LaFramboise, gcc-patches, libstdc++

On Wed, Aug 27, 2008 at 11:30 AM, Dave Korn <dave.korn@artimi.com> wrote:

> Danny Smith wrote on 19 August 2008 04:11:
>
>> While your at it you may as well clean up the use of
>> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.
>
> ... ?
>
If we add this to specs, as was done in the gcc-4.2.1 experimental
release that I
uploaded to mingw release page

/* Weak symbols do not get resolved if using a Windows dll import lib.
   Make the unwind registration references strong undefs.  */
#if DWARF2_UNWIND_INFO
#define SHARED_LIBGCC_UNDEFS_SPEC \
 "%{shared-libgcc: -u ___register_frame_info -u ___deregister_frame_info}"
#else
#define SHARED_LIBGCC_UNDEFS_SPEC ""
#endif

#undef  SUBTARGET_EXTRA_SPECS
#define SUBTARGET_EXTRA_SPECS \
  { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC }

#define LINK_SPEC "%{mwindows:--subsystem windows} \
  %{mconsole:--subsystem console} \
  %{shared: %{mdll: %eshared and mdll are not compatible}} \
  %{shared: --shared} %{mdll:--dll} \
  %{static:-Bstatic} %{!static:-Bdynamic} \
  %{shared|mdll: -e _DllMainCRTStartup@12 --enable-auto-image-base} \
  %(shared_libgcc_undefs)"


then we  make the refs to the undefined externals strong so they will
always be pullled in from the import lib.  Hence no need for the
runtime linkage.

The "downside" of this is that  we  force user to always add
"-shared-libgcc" to gcc command line rather than allow the clever user
to rely on a libgcc.dll.a vs libgcc.a  link order diff.


Danny

^ permalink raw reply	[flat|nested] 36+ messages in thread

* RE: [PATCH] Build libgcc_s on Windows
  2008-08-21  5:15     ` Danny Smith
@ 2008-08-28  4:15       ` Dave Korn
  2008-08-28  9:15         ` Danny Smith
  0 siblings, 1 reply; 36+ messages in thread
From: Dave Korn @ 2008-08-28  4:15 UTC (permalink / raw)
  To: 'Danny Smith', 'Aaron W. LaFramboise'
  Cc: 'gcc-patches', libstdc++

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

Danny Smith wrote on 21 August 2008 04:45:

>> Why are the references to __register_frame_info in crtbegin weak in the
>> first place?  Shouldn't it always be able to find these symbols in
>> libgcc, whether dynamic or not?  It's not obvious to me what case there
>> would be where this symbol would not be available.
> 
> If there is no need for unwind info  then it is unnecessary to pull in
> unwind-dw2-fde.o  from static libgcc.a.  Mingw users have in past
> complained when unwind-dw2-fde.o was always pulled in, saying that it
> was unwanted bloat for small apps.
> 
> Danny

  I agree with this; we want the exception handling machinery to be optional.

  I found it necessary to apply a patch like the attached before it would
actually work correctly in the case where you're *not* pulling in the EH
machinery - otherwise it ends up jumping to NULL because some optimiser
somewhere 'knows' that an unresolved weak makes the program invalid and
doesn't consider the possibility after seeing

   if (h)
     register_frame_fn = (void (*) (const void *, struct object *))
 			GetProcAddress (h, "__register_frame_info");
-  else 
-    register_frame_fn = __register_frame_info;

that register_frame_fn could still be zero.  Danny, what did you mean by:

Danny Smith wrote on 19 August 2008 04:11:

> While your at it you may as well clean up the use of
> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.

... ?

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

[-- Attachment #2: crtbegin.diff --]
[-- Type: application/octet-stream, Size: 4610 bytes --]

diff -purN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x '*~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in origsrc/gcc-4.3.0/gcc/config/i386/cygming-crtbegin.c src/gcc-4.3.0/gcc/config/i386/cygming-crtbegin.c
--- origsrc/gcc-4.3.0/gcc/config/i386/cygming-crtbegin.c	2007-07-05 08:07:34.000000000 +0100
+++ src/gcc-4.3.0/gcc/config/i386/cygming-crtbegin.c	2008-07-06 22:23:33.187500000 +0100
@@ -65,6 +65,12 @@ extern void _Jv_RegisterClasses (const v
 # define EH_FRAME_SECTION_CONST
 #endif
 
+/* We need to indirect through a variable, as gcc assumes
+ that a function label used as a constant is never zero.  */
+void (*register_frame_info_ptr) (const void *, struct object *) = __register_frame_info;
+void *(*deregister_frame_info_ptr) (const void *) = __deregister_frame_info;
+void (*jv_registerclasses_ptr) (const void *) = _Jv_RegisterClasses;
+
 /* Stick a label at the beginning of the frame unwind info so we can
    register/deregister it with the exception handling library code.  */
 #if DWARF2_UNWIND_INFO
@@ -93,15 +99,30 @@ __gcc_register_frame (void)
 /* Weak undefined symbols won't be pulled in from dlls; hence
    we first test if the dll is already loaded and, if so,
    get the symbol's address at run-time.  If the dll is not loaded,
-   fallback to weak linkage to static archive.  */
+   fallback to weak linkage to static archive.  Fallback also
+   if the DLL is loaded but does not export the routine.   */
 
-  void (*register_frame_fn) (const void *, struct object *);
+  void (*register_frame_fn) (const void *, struct object *) = 0;
   HANDLE h = GetModuleHandle (LIBGCC_SONAME);
   if (h)
     register_frame_fn = (void (*) (const void *, struct object *))
 			GetProcAddress (h, "__register_frame_info");
-  else 
-    register_frame_fn = __register_frame_info;
+  /* Can't use
+
+  if (!register_frame_fn)
+    register_frame_fn = register_frame_info_ptr;
+
+  directly, as gcc infers that the address of a function cannot
+  be zero, but in the case of an unlinked weak definition it can.
+  It would clearly be undefined code to use the address of an
+  unlinked weak function in a function call context, but I don't
+  know whether gcc is right to infer it's always non-zero when
+  being taken as a pointer-to-function constant.  */
+  if (!register_frame_fn)
+    register_frame_fn = register_frame_info_ptr;
+
+  /* We use weak references so as to not pull in all the EH machinery
+  unless it's actually required by something else in the final link.  */
   if (register_frame_fn)
      register_frame_fn (__EH_FRAME_BEGIN__, &obj);
 #endif
@@ -109,13 +130,13 @@ __gcc_register_frame (void)
 #if TARGET_USE_JCR_SECTION 
   if (__JCR_LIST__[0])
     {
-      void (*register_class_fn) (const void *);
+      void (*register_class_fn) (const void *) = 0;
       HANDLE h = GetModuleHandle (LIBGCJ_SONAME);
       if (h)
 	register_class_fn = (void (*) (const void *))
 			     GetProcAddress (h, "_Jv_RegisterClasses");
-      else
-	register_class_fn = _Jv_RegisterClasses;
+      if (!register_class_fn)
+	register_class_fn = jv_registerclasses_ptr;
 
       if (register_class_fn)
 	register_class_fn (__JCR_LIST__);
@@ -127,13 +148,13 @@ void
 __gcc_deregister_frame (void)
 {
 #if DWARF2_UNWIND_INFO
-  void *  (*deregister_frame_fn) (const void *);
+  void *  (*deregister_frame_fn) (const void *) = 0;
   HANDLE h = GetModuleHandle (LIBGCC_SONAME);
   if (h)
     deregister_frame_fn = (void* (*) (const void *))
 			  GetProcAddress (h, "__deregister_frame_info");
-  else 
-    deregister_frame_fn = __deregister_frame_info;
+  if (!deregister_frame_fn)
+    deregister_frame_fn = deregister_frame_info_ptr;
   if (deregister_frame_fn)
      deregister_frame_fn (__EH_FRAME_BEGIN__);
 #endif

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-20 14:30   ` Aaron W. LaFramboise
@ 2008-08-21  5:15     ` Danny Smith
  2008-08-28  4:15       ` Dave Korn
  0 siblings, 1 reply; 36+ messages in thread
From: Danny Smith @ 2008-08-21  5:15 UTC (permalink / raw)
  To: Aaron W. LaFramboise; +Cc: gcc-patches, libstdc++

On Thu, Aug 21, 2008 at 1:58 AM, Aaron W. LaFramboise
<aaronavay62@aaronwl.com> wrote:
> Danny Smith wrote:
>
>>> +/* Weak symbols do not get resolved if using a Windows dll import lib.
>>> +   Make the unwind registration references strong undefs.  */
>>> +#if DWARF2_UNWIND_INFO
>>> +#define SHARED_LIBGCC_UNDEFS_SPEC \
>>> + "%{shared-libgcc: -u ___register_frame_info -u
>>> ___deregister_frame_info}"
>>> +#else
>>> +#define SHARED_LIBGCC_UNDEFS_SPEC ""
>>> +#endif
>>
>> I agree this is the safest way to handle weak linkage in libgcc_s_1.dll
>> While your at it you may as well clean up the use of
>> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.
>
> OK, I will, but there is something that is unclear to me actually.
>
> Why are the references to __register_frame_info in crtbegin weak in the
> first place?  Shouldn't it always be able to find these symbols in libgcc,
> whether dynamic or not?  It's not obvious to me what case there would be
> where this symbol would not be available.

If there is no need for unwind info  then it is unnecessary to pull in
unwind-dw2-fde.o  from static libgcc.a.  Mingw users have in past
complained when unwind-dw2-fde.o was always pulled in, saying that it
was unwanted bloat for small apps.

Danny

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-19  5:16 ` Danny Smith
@ 2008-08-20 14:30   ` Aaron W. LaFramboise
  2008-08-21  5:15     ` Danny Smith
  0 siblings, 1 reply; 36+ messages in thread
From: Aaron W. LaFramboise @ 2008-08-20 14:30 UTC (permalink / raw)
  To: Danny Smith; +Cc: gcc-patches, libstdc++

Danny Smith wrote:

>> +/* Weak symbols do not get resolved if using a Windows dll import lib.
>> +   Make the unwind registration references strong undefs.  */
>> +#if DWARF2_UNWIND_INFO
>> +#define SHARED_LIBGCC_UNDEFS_SPEC \
>> + "%{shared-libgcc: -u ___register_frame_info -u ___deregister_frame_info}"
>> +#else
>> +#define SHARED_LIBGCC_UNDEFS_SPEC ""
>> +#endif
> 
> I agree this is the safest way to handle weak linkage in libgcc_s_1.dll
> While your at it you may as well clean up the use of
> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.

OK, I will, but there is something that is unclear to me actually.

Why are the references to __register_frame_info in crtbegin weak in the 
first place?  Shouldn't it always be able to find these symbols in 
libgcc, whether dynamic or not?  It's not obvious to me what case there 
would be where this symbol would not be available.

(The JCR situation makes more sense to me, even if this is a little 
unfortunate.  It might be better to generate undefs that pull in the JCR 
code only if there are some class definitions.)

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-19 13:20   ` Aaron W. LaFramboise
@ 2008-08-19 16:17     ` Paolo Bonzini
  0 siblings, 0 replies; 36+ messages in thread
From: Paolo Bonzini @ 2008-08-19 16:17 UTC (permalink / raw)
  To: Aaron W. LaFramboise; +Cc: gcc-patches, Danny Smith, libstdc++

Aaron W. LaFramboise wrote:
> Paolo Bonzini wrote:
> 
>> +  if (pe_dll) {
>> +    # This matches SHLIB_SONAME in config/i386/t-cygming.
>> +    print "LIBRARY " pe_dll;
>> +    print "EXPORTS";
>> +  }
>>
>> so that in the future it will suffice to have Windows maintainer 
>> approval if you change the soname.
> 
> I actually tried this, but this doesn't work, because at the time mkmap 
> is run, the base soname has not yet been substituted, so you end up with 
> @something@_1.dll or something.  Maybe I'll think of a more creative way 
> to do this so its not duplicated.

Right.  I guess your patch is then okay from this build maintainer.

Howeever, if you want to do this cleanup, it's easy enough: in 
libgcc/Makefile.in you should change $(SHLIB_MKMAP_OPTS) to $(subst 
@shlib_base_name@,libgcc_s,$(SHLIB_MKMAP_OPTS)).

Bonus points if you change all the occurrences of

$(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
                 @multilib_dir@,$(MULTIDIR),$(subst \
                 @shlib_objs@,$(objects),$(subst \
                 @shlib_base_name@,SOME_BASE_NAME,$(subst \
                 @shlib_map_file@,$(mapfile),$(subst \
                 @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
                 @shlib_slibdir@,$(shlib_slibdir),$(SOME_VAR))))))))

to something like

	$(call replace_shlib_vars,SOME_BASE_NAME,$(SOME_VAR))

using an auxiliary variable definition like this one:

replace_shlib_vars = $(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
                 @multilib_dir@,$(MULTIDIR),$(subst \
                 @shlib_objs@,$(objects),$(subst \
                 @shlib_base_name@,$(1),$(subst \
                 @shlib_map_file@,$(mapfile),$(subst \
                 @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
                 @shlib_slibdir@,$(shlib_slibdir),$(2))))))))

Thanks in advance, :-P

Paolo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-19  8:05 ` Paolo Bonzini
@ 2008-08-19 13:20   ` Aaron W. LaFramboise
  2008-08-19 16:17     ` Paolo Bonzini
  0 siblings, 1 reply; 36+ messages in thread
From: Aaron W. LaFramboise @ 2008-08-19 13:20 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: gcc-patches, Danny Smith, libstdc++

Paolo Bonzini wrote:

> +  if (pe_dll) {
> +    # This matches SHLIB_SONAME in config/i386/t-cygming.
> +    print "LIBRARY " pe_dll;
> +    print "EXPORTS";
> +  }
> 
> so that in the future it will suffice to have Windows maintainer 
> approval if you change the soname.

I actually tried this, but this doesn't work, because at the time mkmap 
is run, the base soname has not yet been substituted, so you end up with 
@something@_1.dll or something.  Maybe I'll think of a more creative way 
to do this so its not duplicated.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-18 19:08 Aaron W. LaFramboise
  2008-08-19  5:16 ` Danny Smith
@ 2008-08-19  8:05 ` Paolo Bonzini
  2008-08-19 13:20   ` Aaron W. LaFramboise
  2008-09-02  6:40 ` NightStrike
  2 siblings, 1 reply; 36+ messages in thread
From: Paolo Bonzini @ 2008-08-19  8:05 UTC (permalink / raw)
  To: Aaron W. LaFramboise; +Cc: gcc-patches, Danny Smith, libstdc++

> 	<toplevel>

Ok, but you forgot a piece of a comment in configure.ac.

> 	* acinclude.m4 <enable_symvers>: Don't use symvers on Windows.

Ok (it is a build patch, so no need to wait for the libstdc++-v3 
maintainers for this kind of patch).

> 	<gcc>
> 	* mkmap-flat.awk: Add option pe_dll.

I think I can approve this part too, which is anyway pretty trivial. 
Given Charles' comments I'd do instead:

+  if (pe_dll) {
+    # This matches SHLIB_SONAME in config/i386/t-cygming.
+    print "LIBRARY " pe_dll;
+    print "EXPORTS";
+  }

so that in the future it will suffice to have Windows maintainer 
approval if you change the soname.

Paolo

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] Build libgcc_s on Windows
  2008-08-18 19:08 Aaron W. LaFramboise
@ 2008-08-19  5:16 ` Danny Smith
  2008-08-20 14:30   ` Aaron W. LaFramboise
  2008-08-19  8:05 ` Paolo Bonzini
  2008-09-02  6:40 ` NightStrike
  2 siblings, 1 reply; 36+ messages in thread
From: Danny Smith @ 2008-08-19  5:16 UTC (permalink / raw)
  To: Aaron W. LaFramboise; +Cc: gcc-patches, libstdc++

On Tue, Aug 19, 2008 at 6:50 AM, Aaron W. LaFramboise
<aaronavay62@aaronwl.com> wrote:
> This patch enables building libgcc_s as a DLL on MinGW and Cygwin.  This
> allows throwing exceptions across DLL boundaries when using a shared
> libgcc_s.
>
> It needs approval from toplevel configure, gcc/mkmap, Windows and libstdc++
> maintainers.
>
Hello Aaron.
Thanks for doing this.
OK from this Windows maintainer, but wait for Dave Korn to comment.

One comment,

> +/* Weak symbols do not get resolved if using a Windows dll import lib.
> +   Make the unwind registration references strong undefs.  */
> +#if DWARF2_UNWIND_INFO
> +#define SHARED_LIBGCC_UNDEFS_SPEC \
> + "%{shared-libgcc: -u ___register_frame_info -u ___deregister_frame_info}"
> +#else
> +#define SHARED_LIBGCC_UNDEFS_SPEC ""
> +#endif

I agree this is the safest way to handle weak linkage in libgcc_s_1.dll
While your at it you may as well clean up the use of
GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.

Danny

^ permalink raw reply	[flat|nested] 36+ messages in thread

* [PATCH] Build libgcc_s on Windows
@ 2008-08-18 19:08 Aaron W. LaFramboise
  2008-08-19  5:16 ` Danny Smith
                   ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Aaron W. LaFramboise @ 2008-08-18 19:08 UTC (permalink / raw)
  To: gcc-patches; +Cc: Danny Smith, libstdc++

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

This patch enables building libgcc_s as a DLL on MinGW and Cygwin.  This 
allows throwing exceptions across DLL boundaries when using a shared 
libgcc_s.

It needs approval from toplevel configure, gcc/mkmap, Windows and 
libstdc++ maintainers.

It was tested by a bootstrap and testsuite run on i386-pc-mingw32, as 
well as manually to make sure it works.

The mkmap machinery is re-used to generate a .def file, which is PECOFF 
equivalent of a flat map file.  This should help control the ABI a little.

OK to commit?

[-- Attachment #2: gcc-4.4.0-20080817-libgcc_s.patch --]
[-- Type: text/plain, Size: 9441 bytes --]

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

	<toplevel>
	* configure.ac (RPATH_ENVVAR): Use PATH on Windows.
	(GCC_SHLIB_SUBDIR): New.
	* Makefile.tpl (HOST_LIB_PATH_gcc): Use GCC_SHLIB_SUBDIR.
	* configure: Regenerate.
	* Makefile.in: Regenerate.

	<gcc>
	* mkmap-flat.awk: Add option pe_dll.
	* config/i386/t-cygming (SHLIB_LINK): Support building libgcc_s.
	* gcc/config/i386/t-cygwin (SHLIB_LC): Add.
	* gcc/config/i386/t-mingw32 (SHLIB_LC): Add.
	* config/i386/mingw32.h (SHARED_LIBGCC_UNDEFS_SPEC): New.
	(SUBTARGET_EXTRA_SPECS): Use SHARED_LIBGCC_UNDEFS_SPEC.
	(LINK_SPEC): Support libgcc_s.
	(LIBGCC_SPEC): Support libgcc_s.
	(LIBGCC_SONAME): New.

	<libstdc++-v3>
	* acinclude.m4 <enable_symvers>: Don't use symvers on Windows.
	* configure: Regenerated.
	* Makefile.in: Regenerated.
	* src/Makefile.in: Regenerated.
	* doc/makefile.in: Regenerated.
	* po/Makefile.in: Regenerated.
	* libmath/Makefile.in: Regenerated.
	* include/Makefile.in: Regenerated.
	* libsupc++/Makefile.in: Regenerated.
	* testsuite/makefile.in: Regenerated.

Index: gcc/mkmap-flat.awk
===================================================================
--- gcc/mkmap-flat.awk	(revision 139148)
+++ gcc/mkmap-flat.awk	(working copy)
@@ -18,6 +18,11 @@
 # along with GCC; see the file COPYING3.  If not see
 # <http://www.gnu.org/licenses/>.
 
+# Options:
+#   "-v leading_underscore=1" : Symbols in map need leading underscore.
+#   "-v pe_dll=1"             : Create .DEF file for Windows PECOFF
+#                               DLL link instead of map file.
+
 BEGIN {
   state = "nm";
   excluding = 0;
@@ -86,7 +91,14 @@ $1 == "}" {
 }
 
 END {
+
+  if (pe_dll) {
+    # This matches SHLIB_SONAME in config/i386/t-cygming.
+    print "LIBRARY libgcc_s_1.dll";
+    print "EXPORTS";
+  }
+
   for (sym in export)
-    if (def[sym])
+    if (def[sym] || (pe_dll && def["_" sym]))
       print sym;
 }
Index: gcc/config/i386/t-cygming
===================================================================
--- gcc/config/i386/t-cygming	(revision 139148)
+++ gcc/config/i386/t-cygming	(working copy)
@@ -36,3 +36,51 @@ msformat-c.o: $(srcdir)/config/i386/msfo
 	$(srcdir)/config/i386/msformat-c.c
 
 STMP_FIXINC=stmp-fixinc
+
+# Build a shared libgcc library for PECOFF with a DEF file
+# with the GNU linker.
+#
+# mkmap-flat.awk is used with the pe_dll option to produce a DEF instead
+# of an ELF map file.
+#
+# Warning: If SHLIB_SOVERSION or SHLIB_SONAME is updated, LIBGCC_SONAME
+# in mingw32.h must be updated also.
+
+SHLIB_EXT = .dll
+SHLIB_IMPLIB = @shlib_base_name@.a
+SHLIB_SOVERSION = 1
+SHLIB_SONAME = @shlib_base_name@_$(SHLIB_SOVERSION)$(SHLIB_EXT)
+SHLIB_MAP = @shlib_map_file@
+SHLIB_OBJS = @shlib_objs@
+SHLIB_DIR = @multilib_dir@/shlib
+SHLIB_SLIBDIR_QUAL = @shlib_slibdir_qual@
+SHLIB_LC = -luser32 -lkernel32 -ladvapi32 -lshell32
+
+SHLIB_LINK = $(LN_S) $(SHLIB_MAP) $(SHLIB_MAP).def && \
+	if [ ! -d $(SHLIB_DIR) ]; then \
+		mkdir $(SHLIB_DIR) \
+	else true; fi && \
+	$(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
+	$(SHLIB_MAP).def \
+	-Wl,--out-implib,$(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp \
+	-o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp @multilib_flags@ \
+	$(SHLIB_OBJS) $(SHLIB_LC) && \
+	$(AR_FOR_TARGET) -r $(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp \
+		_chkstk.o _ctors.o && \
+	if [ -f $(SHLIB_DIR)/$(SHLIB_SONAME) ]; then \
+	  mv -f $(SHLIB_DIR)/$(SHLIB_SONAME) \
+		$(SHLIB_DIR)/$(SHLIB_SONAME).backup; \
+	else true; fi && \
+	mv $(SHLIB_DIR)/$(SHLIB_SONAME).tmp $(SHLIB_DIR)/$(SHLIB_SONAME) && \
+	mv $(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp $(SHLIB_DIR)/$(SHLIB_IMPLIB)
+# $(slibdir) double quoted to protect it from expansion while building
+# libgcc.mk.  We want this delayed until actual install time.
+SHLIB_INSTALL = \
+	$$(mkinstalldirs) $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL); \
+	$(INSTALL_PROGRAM) $(SHLIB_DIR)/$(SHLIB_SONAME) \
+	  $$(DESTDIR)$$(bindir)/$(SHLIB_SONAME); \
+	$(INSTALL_DATA) $(SHLIB_DIR)/$(SHLIB_IMPLIB) \
+	  $$(DESTDIR)$$(slibdir)$(SHLIB_SLIBDIR_QUAL)/$(SHLIB_IMPLIB)
+SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk
+SHLIB_MKMAP_OPTS = -v pe_dll=1
+SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver
Index: gcc/config/i386/t-cygwin
===================================================================
--- gcc/config/i386/t-cygwin	(revision 139148)
+++ gcc/config/i386/t-cygwin	(working copy)
@@ -14,3 +14,5 @@ cygwin2.o: $(srcdir)/config/i386/cygwin2
 	$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 	$(srcdir)/config/i386/cygwin2.c
 
+# Cygwin-specific parts of LIB_SPEC
+SHLIB_LC += -lcygwin
Index: gcc/config/i386/t-mingw32
===================================================================
--- gcc/config/i386/t-mingw32	(revision 139148)
+++ gcc/config/i386/t-mingw32	(working copy)
@@ -1,2 +1,5 @@
 # Match SYSTEM_INCLUDE_DIR
 NATIVE_SYSTEM_HEADER_DIR = /mingw/include
+
+# MinGW-specific parts of LIB_SPEC
+SHLIB_LC += -lmingw32 -lmingwex -lmoldname -lmsvcrt
Index: gcc/config/i386/mingw32.h
===================================================================
--- gcc/config/i386/mingw32.h	(revision 139148)
+++ gcc/config/i386/mingw32.h	(working copy)
@@ -67,19 +67,33 @@ along with GCC; see the file COPYING3.  
 #define LIB_SPEC "%{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32} \
                   -luser32 -lkernel32 -ladvapi32 -lshell32"
 
-/* Include in the mingw32 libraries with libgcc */
-#undef LINK_SPEC
+/* Weak symbols do not get resolved if using a Windows dll import lib.
+   Make the unwind registration references strong undefs.  */
+#if DWARF2_UNWIND_INFO
+#define SHARED_LIBGCC_UNDEFS_SPEC \
+ "%{shared-libgcc: -u ___register_frame_info -u ___deregister_frame_info}"
+#else
+#define SHARED_LIBGCC_UNDEFS_SPEC ""
+#endif
+
+#undef  SUBTARGET_EXTRA_SPECS
+#define SUBTARGET_EXTRA_SPECS						\
+  { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC }
+
 #define LINK_SPEC "%{mwindows:--subsystem windows} \
   %{mconsole:--subsystem console} \
   %{shared: %{mdll: %eshared and mdll are not compatible}} \
   %{shared: --shared} %{mdll:--dll} \
   %{static:-Bstatic} %{!static:-Bdynamic} \
-  %{shared|mdll: -e _DllMainCRTStartup@12}"
+  %{shared|mdll: -e _DllMainCRTStartup@12 --enable-auto-image-base} \
+  %(shared_libgcc_undefs)"
 
 /* Include in the mingw32 libraries with libgcc */
 #undef LIBGCC_SPEC
 #define LIBGCC_SPEC \
-  "%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt"
+  "%{mthreads:-lmingwthrd} -lmingw32 \
+   %{shared-libgcc:-lgcc_s} -lgcc \
+   -lmoldname -lmingwex -lmsvcrt"
 
 #undef STARTFILE_SPEC
 #define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
@@ -186,3 +200,6 @@ __enable_execute_stack (void *addr)					
 #if !TARGET_64BIT
 #define MD_UNWIND_SUPPORT "config/i386/w32-unwind.h"
 #endif
+
+/* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
+#define LIBGCC_SONAME "libgcc_s_1.dll"
Index: libstdc++-v3/acinclude.m4
===================================================================
--- libstdc++-v3/acinclude.m4	(revision 139148)
+++ libstdc++-v3/acinclude.m4	(working copy)
@@ -2527,7 +2527,12 @@ if test x$enable_symvers = xyes ; then
     enable_symvers=no
   else
     if test $with_gnu_ld = yes ; then
-      enable_symvers=gnu
+      case ${target_os} in
+        cygwin* | pe | mingw32*)
+          enable_symvers=no ;;
+        *)
+          enable_symvers=gnu ;;
+      esac
     else
       case ${target_os} in
         darwin*)
Index: configure.ac
===================================================================
--- configure.ac	(revision 139148)
+++ configure.ac	(working copy)
@@ -2050,12 +2050,21 @@ case "${host}" in
   ;;
 esac
 
+# Decide which environment variable is used to find dynamic libraries.
 case "${host}" in
   *-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;;
   *-*-darwin* | *-*-rhapsody* ) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;;
+  *-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;
   *) RPATH_ENVVAR=LD_LIBRARY_PATH ;;
 esac
 
+# On systems where the dynamic library environment variable is PATH,
+if test "$RPATH_ENVVAR" = PATH; then
+  GCC_SHLIB_SUBDIR=/shlib
+else
+  GCC_SHLIB_SUBDIR=
+fi
+
 # Record target_configdirs and the configure arguments for target and
 # build configuration in Makefile.
 target_configdirs=`echo "${target_configdirs}" | sed -e 's/target-//g'`
@@ -2513,6 +2522,7 @@ AC_SUBST_FILE(ospace_frag)
 
 # Miscellanea: directories, flags, etc.
 AC_SUBST(RPATH_ENVVAR)
+AC_SUBST(GCC_SHLIB_SUBDIR)
 AC_SUBST(tooldir)
 AC_SUBST(build_tooldir)
 AC_SUBST(CONFIGURE_GDB_TK)
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 139148)
+++ Makefile.tpl	(working copy)
@@ -108,6 +108,11 @@ GDB_NLM_DEPS = 
 # the libraries.
 RPATH_ENVVAR = @RPATH_ENVVAR@
 
+# On targets where RPATH_ENVVAR is PATH, a subdirectory of the GCC build path
+# is used instead of the directory itself to avoid including built
+# executables in PATH.
+GCC_SHLIB_SUBDIR = @GCC_SHLIB_SUBDIR@
+
 # Build programs are put under this directory.
 BUILD_SUBDIR = @build_subdir@
 # This is set by the configure script to the arguments to use when configuring
@@ -439,7 +444,7 @@ HOST_LIB_PATH = [+ FOR host_modules +][+
 
 # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
 @if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR):
 @endif gcc
 
 [+ FOR host_modules +][+ IF lib_path +]

^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2008-09-10  9:54 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-18 21:30 [PATCH] Build libgcc_s on Windows Charles Wilson
2008-08-19 16:42 ` Charles Wilson
2008-08-19 20:34   ` Paolo Bonzini
2008-08-25  7:40     ` Charles Wilson
2008-08-26 12:44       ` Dave Korn
2008-08-28  3:21   ` Dave Korn
2008-08-28  8:51     ` Charles Wilson
2008-08-28 13:04       ` Dave Korn
     [not found] <1221035558.13510.ezmlm@gcc.gnu.org>
2008-09-10  9:09 ` Jay
2008-09-10  9:43   ` lkcl
  -- strict thread matches above, loose matches on Subject: below --
2008-08-28 12:56 Charles Wilson
2008-08-18 19:08 Aaron W. LaFramboise
2008-08-19  5:16 ` Danny Smith
2008-08-20 14:30   ` Aaron W. LaFramboise
2008-08-21  5:15     ` Danny Smith
2008-08-28  4:15       ` Dave Korn
2008-08-28  9:15         ` Danny Smith
2008-08-28  9:35           ` Brian Dessent
2008-08-19  8:05 ` Paolo Bonzini
2008-08-19 13:20   ` Aaron W. LaFramboise
2008-08-19 16:17     ` Paolo Bonzini
2008-09-02  6:40 ` NightStrike
2008-09-02 12:03   ` Kai Tietz
2008-09-02 16:30     ` NightStrike
2008-09-03  9:51       ` Kai Tietz
2008-09-03 18:03         ` NightStrike
2008-09-04  3:52         ` Danny Smith
2008-09-04  6:25           ` NightStrike
2008-09-04  8:00             ` Danny Smith
2008-09-04  8:31           ` Kai Tietz
2008-09-09 19:57           ` lkcl
2008-09-10  8:49             ` lkcl
2008-09-10  9:11               ` Brian Dessent
2008-09-10  9:26                 ` lkcl
2008-09-10 12:32                   ` lkcl
2008-09-10  9:19               ` lkcl

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).