Dave Korn wrote:

  Well I didn't finish rolling the lot over the weekend owing to reasons I'll
explain on the talk list, but I'm saying yes anyway.  First thing I'll do will
be reroll a 3.4.4-2 with the fix for PR-whateveritis about the C++

24196

It also fixes this specific problem on 4.1.0 (mingw; haven't tried cygwin but I assume it'll work in 4.1.0 on our platform too)

strings-vs-dlls problem.  Once that's done and seems ok, I'll look at making
an experimental package from one of the gcc 4 series.  (Anyone got any
preferences?)

Either 4.1.[0,1] or the 4.2.0 devel branch. The mingw guys decided to wait out the 4.0.x series because, as of last May, there were just too many issues on windows with that series. It's an open question whether that is also true of 4.1.x or even 4.2.devel.

I built 4.1.0 (on mingw), c/c++/fortran, and it seemed to work okay -- of course, for fortran, I needed gmp and mpfr. However, there are a few issues:

=====

(1) libjava is "hopelessly broken", according to Danny Smith. I have to concur -- I was not able to get it to build at all, so I gave up including the java compiler in my 4.1.0 build. According to Danny, the java compiler requires a shared libjava (and shared libgcc) -- but see below about DLLs. (According to Danny, it takes over 1G RAM to successfully turn a libjava.a into a DLL+implib ; I never even got libjava.a to build so I can't verify).

Note that the autoconfigury of gcc STILL does not support --enable-shared for cygwin or mingw, so people are still creating DLLs from their .a's -- a dangerous and flaky procedure at best, and it did NOT work for me.

=====

(2) bootstrapping ADA requires the gnat tool from the ADAcore project -- but that, in turn, requires the build to use Dwarf2 exceptions. However, switching to dwarf2 has significant consequences:

(a) breaks backwards compatibility for exception handling -- this probably only affects C++ libraries currently in the cygwin distribution, plus any other users' private C++ stuff

(b) dwarf2 means that any exceptions throw by functions passed as callbacks to the w32api will NOT be caught. Unfortunately, this is a common paradigm for win32 GUI applications...

(c) You can't have C/C++/Fortran be sjlj, while ada is dwarf2 -- at least not in the same build.

=====

(3) The patch by Danny Smith to allow throwing exceptions across DLL boundaries has NOT been ported to any 4.x series -- nor will it be. According to Danny, "I've finally convinced myself
that the patch is more trouble than its worth.  Libstdc++/libgcc as
dll's is how I work it in my own trre. So you are on your own."

(a) unfortunately, when I tried to make DLLs post-build out of libgcc.a, libsupc++.a, and libstdc++.a, I couldn't get them to work -- every app I compiled died a horrible death before main() -- while they worked if I linked against static runtime libraries.

Supposedly, this is the "correct" procedure, at least until the autotoolization of the libgcc/libsupc++/libstdc++/libgfortran/etc is upgraded to support shared-lib-building on cygwin/mingw: AFTER completing the static build,

  dlltool --output.def libstdc++.def --export-all libstdc++.a
  gcc -shared -o libstdc++.dll -Wl,--out-implib,libstdc++.dll.a \
    libstdc++.def libstdc++.a

(Actually, I have a slightly more complicated recipe that uses version numbers and also munges the .la files appropriately, I'll send that later). Not that it actually gave me a working build, mind you, but...

(b) there was a reported issue with exporting vtables and type_info with the shared libgcc/libstdc++/libsupc++ DLLs that, according to Danny, "has not yet been worked out".

Not being able to catch an exception thrown from a DLL is a huge restriction. It *must* be fixed before a 4.x C++ compiler is released -- and there are two options:
  (1) forward port Danny's old patch -- against his wishes, or
  (2) get @#^@@#$ shared libgcc/libsupc++/libstdc++ to work
Neither is trivial.

=====

There are a number of patches to the "our" 3.4.x packages that are cygwin-specific but have never made it "in" to the 4.x CVS. I don't know what they are, but here's a for instance:
   class declspec(dllimport) MyForwardDeclaration;
is necessary if you want to import MyForwardDeclaration from a DLL using the MSVC++ compiler. On gcc, however, you don't need to include the declspec on forward declarations -- only at the point of actual definition:
   class declspec(dllimport) MyActualDefinition
   {
      ....
   }
If you put an attribute marker like declspec(dllimport) in a forward declaration, by default gcc (3.4.x unpatched, 4.x) generates a warning like "attribute valid only at point of definition; attribute ignored". Because MSVC++ needs it in both places, compiler-neutral code for windows tends to includes the declspec at forward declearations, and cygming-special-gcc-3.4.x has a patch to suppress the warning. That patch needs to be forward-ported to 4.x even tho, as a platform-specific hack, it'll never go in to gcc CVS.

Are there others like this? I don't know.  I'm still finding them.

=====

Aside from bringing forward "missing" bits from cygming-3.4.x, there are also serious failures in 4.x on windows, period -- especially in libjava. Danny's right: it's horribly broken, even when you're just trying to built static.

=====

Danny "plays" in a 4.2.0 branch (and has apparently abandoned any effort to get a working 4.1.x OR 4.0.x build). However, he has said that it (his modified version of 4.2.x) is just a toy and not production-ready -- "look what it does on the hairpins", but "[it] does crash a lot".

Almost every platform is jumping off the sjlj ship -- which means that very little testing is happening in the guts of gcc for sjlj handling. It'd be nice for us to switch to DWARF2 if we could: it's MUCH faster and that reportedly makes a huge difference in the compiled java code -- to the degree that it appears that libjava+sjlj is "downright unusable and practically unsupported".

However, this breaks the ability on windows to do w32api callbacks, and there are backwards compatibility issues. With sjlj, tho, ada is supposedly non-compilable; ditto java(?). So either way you eventually go, your packages will have a regression from 3.4.x: (1) either you drop ada and java support, and we live with the ever-increasing brokenness that will accumulate in the sjlj code, or (2) you switch to dwarf2, we keep ada and java, but loose the callback stuff and break backward compatibility. (3) you release TWO entire SETS of compilers: an sjlj one with only C/C++/Fortran, and a "real" one with DWARF2 and the full compiler suite. This is a support nightmare; I recommend against.


In short, getting a working 4.x compiler won't happen overnight, and requires some rather far-reaching decisions, some bugfixes and mailing-list haunting, and some actual coding. I don't think there's any *hurry* for a 4.x compiler; as long as somebody is actually working, however slowly, to make it happen *eventually* would be great -- and more than is happening at present on EITHER cygwin or mingw. AND, I reckon folks would be eager to help test, at least.

I don't mean to be discouraging, but I wanted to publicize what *I* had discovered, during my investigations of the 4.x issue over on the "mingw" side of the fence.

--
Chuck

P.S. attached find my *collected* patches for gcc-4.1 (I didn't write any of them, I merely collected them from various mailing lists -- and it doesn't include the aforementioned warning-suppress patch). Also, see my "build recipe" **on mingw**, not cygwin.

WARNING WARNING WARNING:

The build recipe and patch below gave me a reasonably-working C/C++/Fortran compiler on mingw -- at least, until I dllized the runtime libraries. Then it broke horribly. And even the static version had this known problem: exceptions thrown from user DLLs would NOT be caught by the user application.

Use at your own risk.  no support.  etc etc etc.

WARNING WARNING WARNING
Index: gcc/fortran/gfortran.h
===================================================================
--- gcc/fortran/gfortran.h      (revision 113110)
+++ gcc/fortran/gfortran.h      (working copy)
@@ -1706,6 +1706,7 @@
 
 void gfc_set_sym_referenced (gfc_symbol * sym);
 
+typedef unsigned int uint;
 try gfc_add_attribute (symbol_attribute *, locus *, uint);
 try gfc_add_allocatable (symbol_attribute *, locus *);
 try gfc_add_dimension (symbol_attribute *, const char *, locus *);
Index: libstdc++-v3/include/bits/basic_string.h
===================================================================
--- libstdc++-v3/include/bits/basic_string.h    (revision 113110)
+++ libstdc++-v3/include/bits/basic_string.h    (working copy)
@@ -226,11 +226,8 @@
        void
        _M_dispose(const _Alloc& __a)
        {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
-         if (__builtin_expect(this != &_S_empty_rep(), false))
-#endif
-           if (__gnu_cxx::__exchange_and_add(&this->_M_refcount, -1) <= 0)
-             _M_destroy(__a);
+         if (__gnu_cxx::__exchange_and_add(&this->_M_refcount, -1) <= 0)
+           _M_destroy(__a);
        }  // XXX MT
 
        void
@@ -239,10 +236,7 @@
        _CharT*
        _M_refcopy() throw()
        {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
-         if (__builtin_expect(this != &_S_empty_rep(), false))
-#endif
-            __gnu_cxx::__atomic_add(&this->_M_refcount, 1);
+         __gnu_cxx::__atomic_add(&this->_M_refcount, 1);
          return _M_refdata();
        }  // XXX MT
 
@@ -2048,11 +2042,7 @@
   template<typename _CharT, typename _Traits, typename _Alloc>
     inline basic_string<_CharT, _Traits, _Alloc>::
     basic_string()
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
-    : _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }
-#else
-    : _M_dataplus(_S_construct(size_type(), _CharT(), _Alloc()), _Alloc()) { }
-#endif
+    : _M_dataplus(_S_empty_rep()._M_refcopy(), _Alloc()) { }
 
   // operator+
   /**
Index: libstdc++-v3/include/bits/basic_string.tcc
===================================================================
--- libstdc++-v3/include/bits/basic_string.tcc  (revision 113110)
+++ libstdc++-v3/include/bits/basic_string.tcc  (working copy)
@@ -90,10 +90,9 @@
       _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a,
                   input_iterator_tag)
       {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
        if (__beg == __end && __a == _Alloc())
-         return _S_empty_rep()._M_refdata();
-#endif
+         return _S_empty_rep()._M_refcopy();
+
        // Avoid reallocation for common case.
        _CharT __buf[128];
        size_type __len = 0;
@@ -136,10 +135,9 @@
       _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a,
                   forward_iterator_tag)
       {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
        if (__beg == __end && __a == _Alloc())
-         return _S_empty_rep()._M_refdata();
-#endif
+         return _S_empty_rep()._M_refcopy();
+
        // NB: Not required, but considered best practice.
        if (__builtin_expect(__is_null_pointer(__beg) && __beg != __end, 0))
          __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
@@ -164,10 +162,9 @@
     basic_string<_CharT, _Traits, _Alloc>::
     _S_construct(size_type __n, _CharT __c, const _Alloc& __a)
     {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
       if (__n == 0 && __a == _Alloc())
-       return _S_empty_rep()._M_refdata();
-#endif
+       return _S_empty_rep()._M_refcopy();
+
       // Check for out_of_range and length_error exceptions.
       _Rep* __r = _Rep::_S_create(__n, size_type(0), __a);
       if (__n)
@@ -435,10 +432,6 @@
     basic_string<_CharT, _Traits, _Alloc>::
     _M_leak_hard()
     {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
-      if (_M_rep() == &_S_empty_rep())
-       return;
-#endif
       if (_M_rep()->_M_is_shared())
        _M_mutate(0, 0, 0);
       _M_rep()->_M_set_leaked();
Index: libjava/configure.host
===================================================================
--- libjava/configure.host      (revision 113110)
+++ libjava/configure.host      (working copy)
@@ -260,6 +260,7 @@
        slow_pthread_self=
        ;;
   *-mingw*)
+       libgcj_flags="${libgcj_flags} -fno-omit-frame-pointer"
        # FIXME: win32_exception_handler( ) in win32.cc does not do the
        # right stuff yet w.r.t. SEH. Live with the following for now.
        can_unwind_signal=no
@@ -267,6 +268,7 @@
        DIVIDESPEC=-fuse-divide-subroutine
        ;;
   *-cygwin*)
+       libgcj_flags="${libgcj_flags} -fno-omit-frame-pointer"
        # The cygwin linker doesn't do 8-byte alignment by default, so
        # disable hash synchronization for now.
        enable_hash_synchronization_default=no
Index: libjava/stacktrace.cc
===================================================================
--- libjava/stacktrace.cc       (revision 113110)
+++ libjava/stacktrace.cc       (working copy)
@@ -407,7 +407,6 @@
 _Jv_StackTrace::GetCallerInfo (jclass checkClass, jclass *caller_class,
   _Jv_Method **caller_meth)
 {
-#ifndef SJLJ_EXCEPTIONS
   int trace_size = 20;
   _Jv_StackFrame frames[trace_size];
   _Jv_UnwindState state (trace_size);
@@ -425,15 +424,19 @@
   //JvSynchronized (ncodeMap);
   UpdateNCodeMap ();
 
+#ifdef SJLJ_EXCEPTIONS
+  // The Unwind interface doesn't work with the SJLJ exception model.
+  // Fall back to a platform-specific unwinder.
+  fallback_backtrace (&state);
+#else /* SJLJ_EXCEPTIONS */
   _Unwind_Backtrace (UnwindTraceFn, &state);
+#endif /* SJLJ_EXCEPTIONS */
   
   if (caller_class)
     *caller_class = trace_data.foundClass;
   if (caller_meth)
     *caller_meth = trace_data.foundMeth;
-#else
   return;
-#endif
 }
 
 // Return a java array containing the Java classes on the stack above 
CHECKCLASS.
@@ -450,7 +453,13 @@
   //JvSynchronized (ncodeMap);
   UpdateNCodeMap ();
 
+#ifdef SJLJ_EXCEPTIONS
+  // The Unwind interface doesn't work with the SJLJ exception model.
+  // Fall back to a platform-specific unwinder.
+  fallback_backtrace (&state);
+#else /* SJLJ_EXCEPTIONS */
   _Unwind_Backtrace (UnwindTraceFn, &state);
+#endif /* SJLJ_EXCEPTIONS */
 
   // Count the number of Java frames on the stack.
   int jframe_count = 0;
@@ -520,8 +529,14 @@
 
   //JvSynchronized (ncodeMap);
   UpdateNCodeMap ();
-  
+
+#ifdef SJLJ_EXCEPTIONS
+  // The Unwind interface doesn't work with the SJLJ exception model.
+  // Fall back to a platform-specific unwinder.
+  fallback_backtrace (&state);
+#else /* SJLJ_EXCEPTIONS */
   _Unwind_Backtrace (UnwindTraceFn, &state);
+#endif /* SJLJ_EXCEPTIONS */
 
   if (state.trace_data)
     return (ClassLoader *) state.trace_data;
#!/bin/bash -x
###
##  [snip] a bunch of information concerning mingw prereqs and system
##         setup; default cygwin should be okay as long as the following
##         are installed:
##     libiconv, gettext, zlib, flex, bison, autoconf25, autoconf21,
##     automake19, automake18, automake17, libtool, gcc-3.4.x, gmp, 
##     mpfr
##
##  [M] means mingw-specific
## 
##  GCC CONFIGURE:
##  
##     NOTES:
## [M]   (1) must use relative path to configure (PR24382)
## [M]   (2) must specify --with-as=/path/to/as.exe and 
--with-ld=/path/to/ld.exe (PR24382)
## [M]   (3) if --prefix is not /mingw, then you need to extract w32api and 
mingw-runtime
##           packages into the prefix tree.
##       (4) --disable-werror is required on mingw due to PR25502
##       (5) Java screwed up
##          (a) libjava must be compiled with -fno-omit-frame-pointer ; 
unfortunately,
##              passing the variables in to configure (c.f. BOOT_CFLAGS) does 
not propagate 
##              them to the libjava configury.  So, we have to put them in the 
environment 
##              instead -- and that includes plain old "LDFLAGS" because 
libjava has no 
##              GCJ-specific LD var AND doesn't get its value passed in.
##              The patch to libjava/configure.host MAY fix this problem 
without requiring
##              the environment variables to be set -- but we ALSO need them 
set so that
##              libiconv and libintl are found!
##              *** BUT --- even that won't work, because libjava is "horribly 
broken" on mingw.
##              so, we do not build the java frontend.
##          (b) libjava with SJLJ requires this patch 
http://gcc.gnu.org/ml/java/2006-04/msg00025.html
##              but given #5 it's a moot point.
##          (c) Even so, get a wierd error building libjava classpath: 
##                
../../../../../gcc-4.1.0-svn/libjava/classpath/gnu/CORBA/DynAn/AbstractAny.java:0:
 
##                fatal error: can't open 
/usr/local/src/gcc/gcc-4.1.0-svn/libjava/gnu/CORBA/DynAn/gnuDynValue.java:
##                No such file or directory
##              when the file in question DOES in fact exist. (c.f. 
http://gcc.gnu.org/ml/java/2006-03/msg00043.html)
##              There are also oddities in the .deps files in that they include 
relative paths with backslashes, 
##              which *does not work* with msys's path conversion stuff:
##                  C:\foo\bar is okay. /foo/bar or ../../foo/bar is okay.
##                  NONE OF ..\..\foo\bar nor foo\bar nor \foo\bar work.
##              But again, given 5a...it's moot.
##          (d) see 
http://tjlaurenzo.blogspot.com/2005/08/building-libgcjdll-for-mingw-with-gcc.html
##                  http://rmathew.com/articles/gcj/bldgcj.html
##                    + http://gcc.gnu.org/ml/java/2006-04/msg00057.html
##                  http://gcc.gnu.org/ml/java/2006-02/msg00047.html && thread
##                  http://gcc.gnu.org/ml/java/2006-04/msg00025.html && thread
##                 
##       (6) both java and ada would probably work better with DWARF2 instead 
of SJLJ (except gcj 
##           needs a little more work to properly support DWARF2/mingw).  C++ 
would be 
##           a lot faster with DWARF2.  But then you can't catch exceptions 
thrown by your
##           methods when they are passed as callbacks to Win32API functions -- 
a very common
##           paradigm in win32 GUI programming.
##
## set up some environment variables.  CPPFLAGS must be
## handled special, because it is not passed down to subconfigures

export 
PATH=.:/usr/local/bin:/gnuwin32/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Util/python24:/c/Util/Subversion/bin
export IP="-I/usr/local/include"
export LP="-L/usr/local/lib"
export CPPFLAGS="${IP}"
## export LIBGCJ_CFLAGS="-ffloat-store -fno-omit-frame-pointer ${IP}"
## export LIBGCJ_CXXFLAGS="-ffloat-store -fno-omit-frame-pointer ${IP}"
## export LIBGCJ_JAVAFLAGS="-ffloat-store -fno-omit-frame-pointer ${IP}"
## export GCJFLAGS="-g -O2 -fno-omit-frame-pointer ${IP}"
## export LDFLAGS="${LP}"


srcdir=../gcc-4.1.0-svn
srcdir_abs=$(cd ${srcdir} ; pwd)
instdir=/usr/local/src/gcc/gcc-4.1.0-inst-release
builddir=/usr/local/src/gcc/gcc-4.1.0-build-release
buildlog=/usr/local/src/gcc/gcc-4.1.0-make-bootstrap.log
instlog=/usr/local/src/gcc/gcc-4.1.0-make-install.log 


#   CFLAGS="-O2 -g ${IP}"      CXXFLAGS="-O2 -g ${IP}"      LDFLAGS="${LP}" \
#   BOOT_CFLAGS="-O2 -g ${IP}" BOOT_CXXFLAGS="-O2 -g ${IP}" 
BOOT_LDFLAGS="${LP}" \
#   /bin/sh ${srcdir}/configure \
#      --with-gcc --with-gnu-ld --with-gnu-as \
#      --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe \
#      --with-gmp=/usr/local --with-mpfr=/usr/local \
#      --without-included-gettext --with-libintl-prefix=/usr/local --enable-nls 
\
#      --with-libiconv-prefix=/usr/local \
#      --host=mingw32 --target=mingw32 --prefix=/mingw \
#      --enable-threads --enable-languages=c,c++,fortran \
#      --enable-version-specific-runtime-libs \
#      --disable-win32-registry --disable-shared --enable-sjlj-exceptions \
#      --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm \
#      --disable-libgcj-debug --enable-interpreter 
--enable-hash-synchronization \
#      --enable-libstdcxx-debug \
#      --enable-bootstrap --disable-werror
#
#
#make bootstrap | tee ${buildlog} 2>&1

##
##  OR (takes longer but get a faster compiler)
##  EXCEPT that it is currently (4.1.0) broken on mingw
##  
http://spaces.msn.com/yaekees/blog/cns!1955EE8C6707277A!174.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink
##
# make profiledbootstrap

## need the following to avoid a bug in make install
# make stage3-start

# make install DESTDIR=${instdir} | tee ${instlog} 2>&1

pushd ${instdir}/mingw/lib/gcc/mingw32/4.1.0
dlltool --output-def libstdc++.def --export-all libstdc++.a
dlltool --output-def libsupc++.def --export-all libsupc++.a
dlltool --output-def libgcc.def --export-all libgcc.a
cd debug
dlltool --output-def libstdc++.def --export-all libstdc++.a
cd ..

LIBVER=$(grep libtool_VERSION= ${srcdir}/libstdc++-v3/configure | sed -e 
's/libtool_VERSION=//')
LIBVER_c=$(echo $LIBVER | awk -F: '{print $1}')
LIBVER_r=$(echo $LIBVER | awk -F: '{print $2}')
LIBVER_a=$(echo $LIBVER | awk -F: '{print $3}')
LIBSTDCPP_DLLVER=$(($LIBVER_c - $LIBVER_a))

## no need for a DLLVER for libgcc; it's guaranteed to only add functions,
## never remove or change thier signature.  So it'll always be 
backwards-compatible.

## It's probably not necessary, but we'll use the LIBSTDCPP_DLLVER for 
## libsupc++ as well (after all, all of libsupc++ appears IN libstdc++
## so if libsupc++ changes in a backwards-non-compatible way, then libstdc++
## will, too -- and the gcc folks will modify its LIBVER.  The downside here
## is that if libsupc++ is unchanged or remains backwards compatible, but
## some other part of libstdc++ changes badly -- we will unnecessarily bump
## libsupc++'s DLLNUM.  'sokay.


${builddir}/stage3-gcc/xgcc -shared -olibstdc++-${LIBSTDCPP_DLLVER}.dll \
  -Wl,--out-implib,libstdc++-${LIBSTDCPP_DLLVER}.dll.a \
  ./libstdc++.def ./libstdc++.a
ln libstdc++-${LIBSTDCPP_DLLVER}.dll.a libstdc++.dll.a

${builddir}/stage3-gcc/xgcc -shared -olibsupc++-${LIBSTDCPP_DLLVER}.dll \
  -Wl,--out-implib,libsupc++-${LIBSTDCPP_DLLVER}.dll.a \
  ./libsupc++.def ./libsupc++.a
ln libsupc++-${LIBSTDCPP_DLLVER}.dll.a libsupc++.dll.a

${builddir}/stage3-gcc/xgcc -shared -olibgcc.dll \
  -Wl,--out-implib,libgcc.dll.a \
  ./libgcc.def ./libgcc.a
#no versioned implib, no need to ln

cd debug
${builddir}/stage3-gcc/xgcc -shared -olibstdc++-${LIBSTDCPP_DLLVER}.dll \
  -Wl,--out-implib,libstdc++-${LIBSTDCPP_DLLVER}.dll.a \
  ./libstdc++.def ./libstdc++.a
ln libstdc++-${LIBSTDCPP_DLLVER}.dll.a libstdc++.dll.a
cd ..

## for shared fortran, go here (and you'll need your intact build directory!
## http://www.g95.org/src.html#Support


## MUNGE the .la files
mv libstdc++.la libstdc++.la.SAVE
cat libstdc++.la.SAVE |\
   sed -e "s/^dlname=.*\$/dlname='libstdc++-${LIBSTDCPP_DLLVER}.dll'/" \
       -e "s/^library_names=.*\$/library_names='libstdc++.dll.a'/" >\
   libstdc++.la

mv libsupc++.la libsupc++.la.SAVE
cat libsupc++.la.SAVE |\
   sed -e "s/^dlname=.*\$/dlname='libsupc++-${LIBSTDCPP_DLLVER}.dll'/" \
       -e "s/^library_names=.*\$/library_names='libsupc++.dll.a'/" >\
   libsupc++.la

cd debug
mv libstdc++.la libstdc++.la.SAVE
cat libstdc++.la.SAVE |\
   sed -e "s/^dlname=.*\$/dlname='libstdc++-${LIBSTDCPP_DLLVER}.dll'/" \
       -e "s/^library_names=.*\$/library_names='libstdc++.dll.a'/" >\
   libstdc++.la
cd ..

## And create the links (curdir is ${instdir}/mingw/gcc/mingw32/4.1.0)
pushd ${instdir}/mingw/bin

ln ../lib/gcc/mingw32/4.1.0/libstdc++-${LIBSTDCPP_DLLVER}.dll .
ln ../lib/gcc/mingw32/4.1.0/libsupc++-${LIBSTDCPP_DLLVER}.dll .
ln ../lib/gcc/mingw32/4.1.0/libgcc.dll .

popd
popd


Reply via email to