Maintainer searched

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Maintainer searched

Gerrit P. Haase
Hello,

there is not enough time to maintain all my packages.

Who wants to maintain one or more of my packages, maybe Yaakov wants to
take over some of the GTK+ related packages?  Then there are some more
major packages which really require a maintainer with more time than I
have (i.e. GCC, Perl).


Gerrit
--
=^..^=

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Christopher Faylor-2
On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote:
>there is not enough time to maintain all my packages.
>
>Who wants to maintain one or more of my packages, maybe Yaakov wants to
>take over some of the GTK+ related packages?  Then there are some more
>major packages which really require a maintainer with more time than I
>have (i.e. GCC, Perl).

Hi Gerrit,
I completely understand.

I'm wondering if Dave Korn or Brian Dessent would consider maintaining
gcc?

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Yaakov (Cygwin/X)
In reply to this post by Gerrit P. Haase
Gerrit P. Haase wrote:
> Who wants to maintain one or more of my packages, maybe Yaakov wants to
> take over some of the GTK+ related packages?  Then there are some more
> major packages which really require a maintainer with more time than I
> have (i.e. GCC, Perl).

I'll take everything of yours GNOME-related, namely:

atk*
glib2*
gtk-doc
gtk2-x11*
intltool
libart_lgpl2
libcroco*
pango*

AFAICS, that leaves:

check
gcc*
indent
lcms
libexif
libfpx
libmng
libwmf
libxml2
libxslt
perl

I'll consider a few more of the above (no, gcc is definitely NOT among
them), but I really won't be offended if someone else wants them.


Yaakov
Reply | Threaded
Open this post in threaded view
|

RE: Maintainer searched

Dave Korn
In reply to this post by Christopher Faylor-2
On 03 May 2006 21:43, Christopher Faylor wrote:

> On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote:
>> there is not enough time to maintain all my packages.
>>
>> Who wants to maintain one or more of my packages, maybe Yaakov wants to
>> take over some of the GTK+ related packages?  Then there are some more
>> major packages which really require a maintainer with more time than I
>> have (i.e. GCC, Perl).
>
> Hi Gerrit,
> I completely understand.
>
> I'm wondering if Dave Korn or Brian Dessent would consider maintaining
> gcc?
>
> cgf

  I will definitely consider this quite seriously.  I'm always a little
stretched for time but gcc is just one thing to take care of (albeit several
packages) and I do have a lot of compiler experience.  I'll spend some time at
the weekend reading all the gbs and packaging-related docs and rolling a set
of releasable gcc packages so I can get a feel for the amount of workload it's
likely to place on me and come back to the list with a definite answer Monday.

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

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Christopher Faylor-2
On Thu, May 04, 2006 at 10:22:16AM +0100, Dave Korn wrote:

>On 03 May 2006 21:43, Christopher Faylor wrote:
>>On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P.  Haase wrote:
>>>there is not enough time to maintain all my packages.
>>>
>>>Who wants to maintain one or more of my packages, maybe Yaakov wants to
>>>take over some of the GTK+ related packages?  Then there are some more
>>>major packages which really require a maintainer with more time than I
>>>have (i.e.  GCC, Perl).
>>
>>Hi Gerrit, I completely understand.
>>
>>I'm wondering if Dave Korn or Brian Dessent would consider maintaining
>>gcc?
>
>I will definitely consider this quite seriously.  I'm always a little
>stretched for time but gcc is just one thing to take care of (albeit
>several packages) and I do have a lot of compiler experience.  I'll
>spend some time at the weekend reading all the gbs and
>packaging-related docs and rolling a set of releasable gcc packages so
>I can get a feel for the amount of workload it's likely to place on me
>and come back to the list with a definite answer Monday.

Thanks for considering this, Dave.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Yitzchak Scott-Thoennes
In reply to this post by Gerrit P. Haase
On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote:
> Hello,
>
> there is not enough time to maintain all my packages.
>
> Who wants to maintain one or more of my packages, maybe Yaakov wants to
> take over some of the GTK+ related packages?  Then there are some more
> major packages which really require a maintainer with more time than I
> have (i.e. GCC, Perl).

If it's ok with you, I'll take perl.
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Gerrit P. Haase
In reply to this post by Yaakov (Cygwin/X)
Yaakov schrieb:

> Gerrit P. Haase wrote:
>> Who wants to maintain one or more of my packages, maybe Yaakov wants to
>> take over some of the GTK+ related packages?  Then there are some more
>> major packages which really require a maintainer with more time than I
>> have (i.e. GCC, Perl).

> I'll take everything of yours GNOME-related, namely:

> atk*
> glib2*
> gtk-doc
> gtk2-x11*
> intltool
> libart_lgpl2
> libcroco*
> pango*

Wow, fine with me, you are probably the best candidate :-)

Are these yours already?
gnome-vfs2
libbonobo2
libbonoboui2
libgnome2
libgnomeui2



> AFAICS, that leaves:

> check
> gcc*
> indent
> lcms
> libexif
> libfpx
> libmng
> libwmf
> libxml2
> libxslt
> perl

> I'll consider a few more of the above (no, gcc is definitely NOT among
> them), but I really won't be offended if someone else wants them.

lcms is not mine.  However, there was no update since I dropped the
package IIRC.  And it is quite stable.


I'll keep maintaining the following if there is no interest:

antiword
db*/libdb*
check
indent
enscript
exif/libexif
expat
freeglut
jasper
libfpx
libmng
libwmf
libxml2
libxslt
openjade
OpenSP

And TLS related: gnutls, libtasn1, opencdk


Gerrit
--
=^..^=

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Yaakov (Cygwin/X)
Gerrit P. Haase wrote:
> Wow, fine with me, you are probably the best candidate :-)

I already have updated packages ready for GNOME 2.14.

> Are these yours already?
> gnome-vfs2
> libbonobo2
> libbonoboui2
> libgnome2
> libgnomeui2

Yes, I took those for GNOME 2.10.

> lcms is not mine.  However, there was no update since I dropped the
> package IIRC.  And it is quite stable.

True.

> I'll keep maintaining the following if there is no interest:
>
> antiword
> db*/libdb*
> check
> indent
> enscript
> exif/libexif
> expat
> freeglut
> jasper
> libfpx
> libmng
> libwmf
> libxml2
> libxslt
> openjade
> OpenSP
>
> And TLS related: gnutls, libtasn1, opencdk

I've built already check, libxml2, and libxslt for my own purposes, so I
could take those too if you want.


Yaakov
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Max O Bowsher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yaakov S (Cygwin Ports) wrote:

> Gerrit P. Haase wrote:
>
>> I'll keep maintaining the following if there is no interest:
>>
>> antiword
>> db*/libdb*
>> check
>> indent
>> enscript
>> exif/libexif
>> expat
>> freeglut
>> jasper
>> libfpx
>> libmng
>> libwmf
>> libxml2
>> libxslt
>> openjade
>> OpenSP
>>
>> And TLS related: gnutls, libtasn1, opencdk
>
> I've built already check, libxml2, and libxslt for my own purposes, so I
> could take those too if you want.


After I've finished wrangling PHP into a releasable state, I'd be
willing to pick up db and expat.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)

iD8DBQFEXephfFNSmcDyxYARApBzAJ9D4iqMmLm/tTndtG+pgcxt6MIrqQCgy45a
kYuGDQOF1fDp2qPrxHqTjTs=
=b8aH
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

RE: Maintainer searched

Dave Korn
In reply to this post by Dave Korn
On 04 May 2006 10:22, Dave Korn wrote:

> On 03 May 2006 21:43, Christopher Faylor wrote:
>
>> On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote:
>>> there is not enough time to maintain all my packages.
>>>
>>> Who wants to maintain one or more of my packages, maybe Yaakov wants to
>>> take over some of the GTK+ related packages?  Then there are some more
>>> major packages which really require a maintainer with more time than I
>>> have (i.e. GCC, Perl).
>>
>> Hi Gerrit,
>> I completely understand.
>>
>> I'm wondering if Dave Korn or Brian Dessent would consider maintaining gcc?
>>
>> cgf
>
>   I will definitely consider this quite seriously.  I'm always a little
> stretched for time but gcc is just one thing to take care of (albeit several
> packages) and I do have a lot of compiler experience.  I'll spend some time
> at the weekend reading all the gbs and packaging-related docs and rolling a
> set of releasable gcc packages so I can get a feel for the amount of
> workload it's likely to place on me and come back to the list with a
> definite answer Monday.


  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++
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?)



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

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Charles Wilson-2
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 | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Christopher Faylor-2
In reply to this post by Dave Korn
On Mon, May 08, 2006 at 10:46:22AM +0100, 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++ 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?)

You may want to drop Danny Smith a line and see what he's planning so
that you can coordinate between gcc and mingw.

cgf
Reply | Threaded
Open this post in threaded view
|

RE: Maintainer searched

James R. Phillips-3
In reply to this post by Dave Korn
--- 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++
> 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?)
>
>

Dave,

The octave and octave-forge packages will greatly benefit from the first bug
fix.  I'll produce new releases ASAP following a gcc 3.4.4-2 bug-fix release.
Thanks for signing on to this important maintenance responsibility.

Do you suppose there is any chance of releasing libstdc++ as a dll for gcc
3.4.4-2 ?  This would greatly reduce the size of the octave and octave-forge
packages.

There is also some consensus that octave performance is hampered by the sjlj
exception handling scheme.  I wonder if it is necessary that mingw and cygwin
use the same method - perhaps mingw could carry sjlj forward as it is more
important for win32 programming, while cygwin could plan a transition to
dwarf2, which perhaps aligns better with the paradigm of porting linux apps.
Just a thought.

Jim Phillips

[Dave, sorry I sent the first copy to you instead of the ML]
Reply | Threaded
Open this post in threaded view
|

gcj --- Was: (RE: Maintainer searched)

Christopher Molnar-3
In reply to this post by Charles Wilson-2
I didn't get the whole thread of this. Is someone going to try and fix the
gcj? I have 3 applications that I would like to submit (Apache Tomcat,
Apache Ant, and Servsys) that I can not get to build using gcj (core dump).
I am really not sure what to do. They build perfectly using Suns jdk.

Anyone have any suggestions?

-Chris



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



Reply | Threaded
Open this post in threaded view
|

Re: gcj --- Was: (RE: Maintainer searched)

Charles Wilson-2
[top posting.  Reformatted]

Christopher Molnar wrote:
 > Charles Wilson wrote:
>> (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).
 >
> I didn't get the whole thread of this.

The section you quoted was refering to 4.x exclusively.  I have no
knowledge, nor make any claim of working or non-working, for the gcj
shipped as part of gcc-3.4.4 on cygwin.

> Is someone going to try and fix the
> gcj? I have 3 applications that I would like to submit (Apache Tomcat,
> Apache Ant, and Servsys) that I can not get to build using gcj (core dump).
> I am really not sure what to do. They build perfectly using Suns jdk.

So, this is a bug report for gcj-3.4.4 on cygwin?  If so, I'd suggest
just waiting until the new maintainer releases his own version of 3.4.x.
  (It probably won't contain any new fixes, but that'll give the new
maintainer a fighting chance).  Anyway, after that version is released,
try it again, and then raise a bug report.  And, as always....

> Anyone have any suggestions?

PTC, I'm sure.

--
Chuck
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Corinna Vinschen-2
In reply to this post by Yitzchak Scott-Thoennes
On May  4 18:06, Yitzchak Scott-Thoennes wrote:

> On Wed, May 03, 2006 at 10:24:19PM +0200, wrote:
> > Hello,
> >
> > there is not enough time to maintain all my packages.
> >
> > Who wants to maintain one or more of my packages, maybe Yaakov wants to
> > take over some of the GTK+ related packages?  Then there are some more
> > major packages which really require a maintainer with more time than I
> > have (i.e. GCC, Perl).
>
> If it's ok with you, I'll take perl.

Since there hasn't been much movement lately, I tracked which of
Gerrit's packages have been actually taken over.  As I see it now,
the following packages remain to be taken over, please correct me
if I missed something:

  antiword
  check Yaakov S?
  db* Max Bowsher?
  enscript
  exif
  expat Max Bowsher?
  freeglut
  gcc* Dave Korn?
  gconf2
  gnutls*
  indent
  jasper
  libdb*
  libexif*
  libfpx
  libgnutls11
  libmng
  libopencdk8
  libtasn1
  libwmf
  libxml2* Yaakov S?
  libxslt Yaakov S?
  opencdk
  openjade
  opensp
  perl,perl_manpages Yitzchak Scott-Thoennes?

I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over,
or are you still considering to take over?  It would be nice to have
that sorted out.

Anybody opting for the remaining packages?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Reply | Threaded
Open this post in threaded view
|

RE: Maintainer searched

Dave Korn
On 13 June 2006 11:37, Corinna Vinschen wrote:

>>> have (i.e. GCC, Perl).

>   gcc* Dave Korn?

> I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over,
> or are you still considering to take over?  It would be nice to have
> that sorted out.

  I've got a release ready to go on a pen drive here at work with me.  It'll
have to be an experimental release initially because there's some unexplained
regressions in the testsuite (branch probability .gcda file generation) but it
ought to help the people with the std::string-vs-dlls problem.  On my lunch
hour this afternoon I'll find a bit of webspace somewhere that I can dump it
to for upload and post back.

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

Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Max O Bowsher
In reply to this post by Corinna Vinschen-2
Corinna Vinschen wrote:

> On May  4 18:06, Yitzchak Scott-Thoennes wrote:
>> On Wed, May 03, 2006 at 10:24:19PM +0200, wrote:
>>> Hello,
>>>
>>> there is not enough time to maintain all my packages.
>>>
>>> Who wants to maintain one or more of my packages, maybe Yaakov wants to
>>> take over some of the GTK+ related packages?  Then there are some more
>>> major packages which really require a maintainer with more time than I
>>> have (i.e. GCC, Perl).
>> If it's ok with you, I'll take perl.
>
> Since there hasn't been much movement lately, I tracked which of
> Gerrit's packages have been actually taken over.  As I see it now,
> the following packages remain to be taken over, please correct me
> if I missed something:

>   libdb*
Not sourceful: built by db*.

>   libgnutls11
Not sourceful: built by gnutls.

>   libopencdk8
Not sourceful: built by opencdk.
(And is missing an external-source: hint to declare this!)


>   db* Max Bowsher?
>   expat Max Bowsher?
>   libxml2* Yaakov S?
>   libxslt Yaakov S?


> I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over,
> or are you still considering to take over?  It would be nice to have
> that sorted out.

Previously, I said I'd look at db*/expat after I was done with PHP - PHP
is now in final stages of ITP, so I'm clear to proceed.

I'll take db* and expat if Gerrit still wants to pass them on (they were
on his maybe-keep list).

I could take libxml2* and libxslt if Yaakov didn't want them.

> Anybody opting for the remaining packages?

After I'm done with db* and expat, I could possibly consider gnutls if
it remains unclaimed at that time.


Max.


signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Yaakov (Cygwin/X)
In reply to this post by Corinna Vinschen-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Corinna Vinschen wrote:

> Since there hasn't been much movement lately, I tracked which of
> Gerrit's packages have been actually taken over.  As I see it now,
> the following packages remain to be taken over, please correct me
> if I missed something:
>
>   check Yaakov S?
>   libxml2* Yaakov S?
>   libxslt Yaakov S?
>
> I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over,
> or are you still considering to take over?  It would be nice to have
> that sorted out.

I am taking those packages and already have newer versions ready, but as
I've been using snapshots as of late, I can't guarantee that the new
versions work with 1.5.19-4.


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEju/tpiWmPGlmQSMRAmJJAJ9IRN/7r3vpYPD7Cqj6sRcJPN47yQCcD76Q
NtO8Q0foPGEHX3737XLNvV0=
=Zumg
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Maintainer searched

Corinna Vinschen-2
In reply to this post by Dave Korn
Dave Korn wrote:

> On 13 June 2006 11:37, Corinna Vinschen wrote:
>
>>>> have (i.e. GCC, Perl).
>
>>   gcc* Dave Korn?
>
>> I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over,
>> or are you still considering to take over?  It would be nice to have
>> that sorted out.
>
>   I've got a release ready to go on a pen drive here at work with me.  It'll
> have to be an experimental release initially because there's some unexplained
> regressions in the testsuite (branch probability .gcda file generation) but it
> ought to help the people with the std::string-vs-dlls problem.  On my lunch
> hour this afternoon I'll find a bit of webspace somewhere that I can dump it
> to for upload and post back.

Hmm, reading between the lines I could assume that this is a "yay,
I'm taking over maintainership", but I'm born with a certain amount of
stubbornness, so I'm still missing a clear answer.  Are you taking over,
yay or nay?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
12