On Mon, 2005-01-24 at 12:04 -0500, Branden Robinson wrote:
> After discussing this with Keith Packard on IRC, I'm going to apply this
> patch with a guard on it:
>
> #if defined(__GNUC__) && defined(__arm__)
>
> Everyone seems to find the patch esthetically abhorrent, but it also
> appears to be
On Sun, 2004-07-04 at 23:53, David Martínez Moreno wrote:
> Hello, fellow developers. I have found this log in elara (the ARM
> buildd):
> arm-linux-g++: Internal error: Killed (program cc1plus)
> Please submit a full bug report.
> See http://gcc.gnu.org/bugs.html> for instructions.
> For De
On Sun, 2004-06-13 at 21:45, Colin Watson wrote:
> On Sun, Jun 13, 2004 at 08:35:08PM +0100, Philip Blundell wrote:
> > On Sun, 2004-06-13 at 20:11, Matthias Klose wrote:
> > > Philip Blundell writes:
> > > > Apparently this problem is triggered by -O3, which ssh has
It seems so, yes. I don't know why openssh started using -O3.
p.
On Sun, 2004-06-13 at 20:11, Matthias Klose wrote:
> So a workaround is to build using -O2 on arm (which should be the
> default according to Debian policy anyway).
>
> Philip Blundell writes:
> > App
On Fri, 2004-04-09 at 16:37, Peter Naulls wrote:
> gcc -Wp,-MD,arch/arm/boot/compressed/.ll_char_wr.o.d -nostdinc -iwithprefix
> include -D__KERNEL__ -Iinclude
> -D__KERNEL__ -Iinclude -D__ASSEMBLY__ -mlittle-endian -mapcs-32
> -D__LINUX_ARM_ARCH__=3 -march=armv3
> -mtune=strongarm110 -msoft-
On Fri, 2004-03-12 at 12:08, Richard Earnshaw wrote:
> Phil, were you going to commit the back-port you had done?
Yep, I can do that.
p.
On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
> > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
>
> CCed Phil Blundell
No. The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
was a different bug. I don't think we had a PR filed for the XFree86
thin
On Mon, 2003-09-22 at 23:58, Matt Zimmerman wrote:
> It is a problem for us to ship binary packages that we cannot build. What
> happens if we needed to do an urgent update on this package (e.g.,
> security)? Or if a user needs to patch and rebuild it?
>From what I recall, fixing libstdc++3 to b
On Fri, 2003-08-08 at 13:35, GOTO Masanori wrote:
> So how to act for two bugs?:
>
> #203322: python2.2: Python fails with illegal instruction during
> postinst on sparc32
> #203324: libc6: __strtod_internal fails with illegal instruction on
> sparc32.
>
> Keeping them as "Critical"
On Fri, 2003-06-27 at 18:54, Daniel Jacobowitz wrote:
> On Thu, Jun 26, 2003 at 06:09:07PM +0100, Philip Blundell wrote:
> > On Wed, 2003-06-25 at 21:13, Bill Allombert wrote:
> > > A wild guess : '@ lr needed for prologue'
> > > mean that lr must not be c
On Wed, 2003-06-25 at 21:13, Bill Allombert wrote:
> A wild guess : '@ lr needed for prologue'
> mean that lr must not be clobbered but
> 'ldrb lr, [r0, #3]' clobber it (??)
Yes, exactly that. Thanks for isolating this problem!
I'll take a look at the code and see if I can come up with a fix,
a
On Fri, 2003-06-20 at 10:24, Marcelo E. Magallon wrote:
> (sid)[EMAIL PROTECTED]:~/gts-0.7.1/src$ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..
> -I/usr/include -DG_LOG_DOMAIN=\"Gts\" -O2 -Wall -Wall
> -Werror-implicit-function-declaration -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-declaration
On Thu, 2003-06-19 at 16:26, Bill Allombert wrote:
> Package: gcc-3.3
> Version: 1:3.3-3
> Severity: normal
>
> Dear GCC maintainers,
>
> gcc 3.3 (1:3.3ds9-3) miscompile pari (2.1.5) on arm with -O3, whereas
> gcc 3.2 (3.2.3 20030331) worked fine.
>
> With -O2 gcc 3.3 works fine also
>
> The pr
This looks rather similar to #192634, though the bit about "source
register same as write-back base" is slightly worrying.
A patch for that bug is in debian-gcc cvs for both 3.2 and 3.3 now, so
it might be worth making new packages for testing.
p.
tags 192634 + patch
thanks
A patch for this problem is at:
http://gcc.gnu.org/ml/gcc-patches/2003-05/txt5.txt
p.
On Fri, 2003-01-17 at 07:38, Christoph Martin wrote:
> I need some help with this bugreport. I checked that the problem is
> reproduceable. Could someone please verify that the problem description
> is correct. Do you think the solution is the right one?
> ;
> }
Does this still happen when you com
So, per our IRC discussion this afternoon, I think the current plan for
this is to have ld.so treat CMOV as an optional extension, similar to
how MMX is handled. In other words:
- Add CMOV to HWCAP_IMPORTANT in glibc.
- Ask the maintainers of openssl and any other affected packages to put
thei
On Wed, 2003-01-08 at 15:32, Matthias Klose wrote:
> I hope Phil will be looking at this. We should not take care of testing at
> this point. some architectures don't even have glibc-2.3.1 at the moment.
BTW, all architectures except hurd-i386 have glibc-2.3.1 built now.
p.
On Wed, 2003-01-08 at 15:32, Matthias Klose wrote:
> Nathanael Nerode writes:
> > Looking at the 'update_excuses' and buildd logs, it seems the most
> > recent version of gcc-3.2 isn't building on ARM. It's failing after a
> > veerry long command line which appears to have improperly embedde
On Fri, 2002-11-15 at 12:41, Martin v. Loewis wrote:
> Philip Blundell <[EMAIL PROTECTED]> writes:
>
> > Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
> > "recursion limit reached" problem). For gcc-3.0, changing the build
>
Package: gcc-3.1
Version: 1:3.1.1ds3-3
Severity: serious
libstdc++ doesn't compile with glibc 2.3 headers. Its locale-related
files make copious use of symbols that are no longer declared (e.g.
__strtod_l, __newlocale, __ctype_toupper).
Package: gcc-3.1
Version: 1:3.1.1ds3-3
Severity: serious
Justification: arm autobuilder can't cope otherwise
Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
"recursion limit reached" problem). For gcc-3.0, changing the build
dependency from autoconf to autoconf2.13 fixed
On Wed, 2002-09-25 at 10:05, Richard Earnshaw wrote:
> > python2.3 now builds fine on arm-linux with this patch. It's not yet
> > checked into the 3.2 branch.
>
> Why on earth would a real application want to put part of a pointer into a
> bit-field? That sounds like it is highly non-portable.
On Tue, 2002-09-03 at 17:27, LaMont Jones wrote:
> Bug #158290 talks about an issue with gcc 3.0 on hppa. Specifically,
> building perl 5.8 with -O2 fails tests, while -O1 works.
>
> Any thoughts on the subject? mawk also suffers from the same ailment.
Try gcc 3.1 or 3.2?
p.
On Tue, 2002-09-03 at 00:19, James Troup wrote:
> 'cos you had already uploaded a newer version by the time it had
> finished building. If foo_1.0-1 gets built, it'll only be uploaded as
> long as 1.0-2 (source) hasn't gone into the archive. I suppose I
> could manually upload the old version, bu
On Sat, 2002-08-31 at 09:38, Matthias Klose wrote:
> patching file gcc/config/arm/linux-elf.h
> configure.in:2120: /usr/bin/m4: ERROR: Recursion limit of 1024 exceeded, use
> -L to change it
> make: *** [stamps/02-patch-stamp-arm-tune] Error 1
Yeah, I suspected it was to do with that. I still do
Hmm, where did this change come from?
* debian/patches/arm-tune.dpatch: Increase stack limit for configure.
It seems to be breaking the build: I can't find any version of autoconf
that actually understands the -L option. Matthias, any idea?
p.
On Tue, 2002-08-27 at 12:40, Junichi Uekawa wrote:
> On Tue, 27 Aug 2002 13:14:30 +0200
> "Laurent Bonnaud" <[EMAIL PROTECTED]> wrote:
>
> > LD_LIBRARY_PATH=/tmp/LB/gcc-3.2-3.2ds0/build/gcc/ada \
> > /usr/bin/make -C /tmp/LB/gcc-3.2-3.2ds0/build/gcc gnatlib gnattools
>
> It should probabl
On Wed, 2002-08-14 at 08:08, Martin Schulze wrote:
> Package: gcc-3.2
> Version: current
> Severity: minor
>
> - Description: The GNU C compiler
> + Description: GNU Compiler Collection 3.2
>
> It's called "GNU Compiler Collection" since 1999, btw/fyi.
That's indeed the name of the upstream proj
Package: gcc-2.95
Version: 1:2.95-7
Severity: important
Tags: fixed
Profiling does not work on ARM with gcc 2.95. There are two problems:
- the cc1 specs seem to be missing %{profile:-p}, so "-profile" doesn't
actually enable profiling code generation (though -p/-pg works)
- the generated prof
On Mon, 2002-06-10 at 22:04, Chris Cheney wrote:
> Does anyone know if/when Debian is planning on switching the default
> compiler to gcc 3.1.x. I am waiting to upload KDE 3 to see if gcc 3.1
> will become the default compiler anytime soon.
At some point during the next major release cycle, yes.
On Mon, 2002-06-10 at 13:15, Ulrich Eckhardt wrote:
> Package: libstdc++3-dbg
> Version: 3.0.4-7
>
> While trying to debug a program, I encountered some weird paths that
> prevented me from taking advance of the debug-lib:
>
> LD_PRELOAD=/usr/lib/libstdc++_debug/libstdc++3.so.3 gdb ./test
> ...
On Sun, 2002-06-09 at 20:26, Martin v. Loewis wrote:
> I don't think that a Debian bug report is the right place to "push" a
> patch into gcc (i.e. to lobby for it).
>
> Instead, you should assume that all patches that have been submitted
> to gcc-patches are implicitly Debian bug reports which al
On Sun, 2002-06-09 at 18:38, Torsten Knodt wrote:
> I think there should be a gcc version with stack protection patch included.
> The patch was sent in the gcc patches mailing list. Perhaps a single version
> is enough, as the patch can be (completly ?) disabled.
Please include a pointer to the pa
On Wed, 2002-05-29 at 14:47, Othmar Pasteka wrote:
> i tested searchandrescue on arm with gcc 3.1. it worked,
Oh, cool. Want to try realtimebattle as well? :-)
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, 2002-05-06 at 19:35, Matthew Wilcox wrote:
>
> I've tried building m68k-linux, arm-linux and alpha-linux gnat compilers.
> None has worked ;-( ARM and m68k seem to be missing some exception handling
> support, eg (arm):
>
> ../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2
On Sat, 2002-04-06 at 20:17, Samuel Tardieu wrote:
> | - More architectures: Chris wrote, he wanted to build for alpha.
> | Anyone else for other architectures?
>
> Cross compilation needed, not difficult, only tedious.
Is there a recipe somewhere for bringing up GNAT using a cross compiler?
I'
On Sat, 2002-04-06 at 00:13, Matthias Klose wrote:
> Philip Blundell writes:
> > On Tue, 2002-04-02 at 11:04, Matthias Klose wrote:
> > > - arm: missing(?) arm-patches
> >
> > I sent the two patches we had in 3.0 to the gcc mailing lists. Maybe
> > there
On Tue, 2002-04-02 at 11:04, Matthias Klose wrote:
> - arm: missing(?) arm-patches
I sent the two patches we had in 3.0 to the gcc mailing lists. Maybe
there's still a chance that they might be included in the actual
release. If not, it's no big deal.
Yesterday I ran a build of the 3.1 package
On Fri, 2002-04-05 at 08:16, Zdenek Kabelac wrote:
> Hmm looks like it - but there are two interesting points however
> - somehow I've not noticed this report while using reportbug
> - I do not link libGLU to avifile - but as it's linked with libSDL
> libGL seems to be linked with the program -
On Thu, 2002-04-04 at 22:28, Zdenek Kabelac wrote:
> Just today I've recompiled avifile with latest gcc3.0
> and with Qt compiled with gcc3.0 so I could actually try how this
> works - and I've discovered that dynamic_cast with this
> gcc no longer works and actually creates coredump.
>
> For av
On Mon, 2002-04-01 at 16:44, Jeff Bailey wrote:
> Do you folks have pre-release gcc-3.1 debs that we can use for testing
> (and possibly building...)? A quick google search doesn't seem to
> show any recent discussion on this, so if there's somewhere better I
> need to look, please let me know.
T
On Fri, 2002-03-29 at 14:24, mffm Matt Flax wrote:
> Please find attatched a complete shared library project and Makefile.
>
> a] tar zxpvf g++-3.0-possible-bug.tar.gz ; cd g++-3.0-possible-bug
> b] make
> c] export LD_LIBRARY_PATH=.
> d] /sbin/ldconfig
> e] ./HelloWorldExample
> ./HelloWorldExamp
reassign 139796 localepurge
thanks
On Fri, 2002-03-29 at 01:55, Mark Montague wrote:
> > Date: Fri, 29 Mar 2002 08:10:06 +0900
> > From: Junichi Uekawa <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > Subject: Re: Bug#139796: gij-3.0: fails to configure when localepurge has
On Fri, 2002-03-29 at 03:17, Camm Maguire wrote:
> arm g77 compiler failure new to -8, must be due to a
> (default compiler upgrade on this arch
> optimizations)
Looks like the buildd just ran out of memory. Elara is not 100%
dedicated to the
tags 140186 + unreproducible
thanks
I'm not able to replicate this bug. Can you send a complete test-case
that shows the problem?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
severity 137959 important
thanks
You wrote:
> marking serious since this bug is keeping several packages out of
> woody.
Can you clarify whether this is a new failure, or one that has just gone
unnoticed previously?
I'm downgrading it to "important" on the assumption that the bug has
existed
: low
Maintainer: Debian GCC maintainers
Changed-By: Philip Blundell <[EMAIL PROTECTED]>
Description:
chill-2.95 - The GNU CHILL compiler.
cpp-2.95 - The GNU C preprocessor.
cpp-2.95-doc - Documentation for the GNU C preprocessor (cpp).
g++-2.95 - The GNU C++ compiler.
g77-2.95 - T
On Thu, 2002-03-21 at 12:16, Tomas Pospisek wrote:
> Since I do not have the original sources/patch etc. I am unable to verify
> (well I might go searching for it on the net, but I'm lazy).
>
> But I have been building pine*.deb packages for a long time now
> every time a new pine came out so I gu
On Thu, 2002-03-21 at 11:21, Tomas Pospisek wrote:
> I guess http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=78826 can be
> closed. Maybe someone of your group who knows better than me can affirm
> and close it?
Does the problem still exist with the latest gcc-2.95 package? It's not
clear to me
says:
gcc-defaults (0.19) unstable; urgency=medium
* Set g77 version for ARM to 3.0.
* Disable java for mips(el); it clearly isn't getting built.
* Add self to Uploaders
-- Philip Blundell <[EMAIL PROTECTED]> Sun, 3 Mar 2002 22:36:36 +
and the rules patch is:
--- gcc-defau
On Wed, 2002-02-27 at 19:27, Matthias Klose wrote:
> Philip Blundell writes:
> > On Wed, 2002-02-27 at 17:04, Adam C Powell IV wrote:
> > > 3.0 fixes this problem, but then maintainers must hand-build using
> > > g77-3.0, which is not a viable long-term solution. I k
On Wed, 2002-02-27 at 17:04, Adam C Powell IV wrote:
> 3.0 fixes this problem, but then maintainers must hand-build using
> g77-3.0, which is not a viable long-term solution. I know some arches
> have 3.0 as their default compiler. So, what are the criteria, and
> what's the procedure, for cha
On Mon, 2002-02-25 at 21:51, Blars Blarson wrote:
> On Mon, Feb 25, 2002 at 09:39:13PM +0000, Philip Blundell wrote:
> > There is no point just trying to pin the blame on arbitrary packages.
> > The fact that libstdc++2.10-dev won't configure is a symptom of the
> > prob
On Mon, 2002-02-25 at 21:07, Blars Blarson wrote:
> On Mon, Feb 25, 2002 at 06:11:52PM +0100, Matthias Klose wrote:
> > I don't think this is related to libstdc++2.10-dev (a dev package not
> > containing any shared libs).
>
> As I said, the apt maintainer wasn't willing to accept the bug as
> the
On Tue, 2002-02-12 at 22:20, Frederic Tessier wrote:
> We are not familiar with the intricate workings of the compiler,
> but this must have to do with an alignment problem when the
> executable is launched, as the changes typically occur when the
> name length is increased by 8 bytes. This is a se
Package: gcc-3.0
Version: 1:3.0.4ds2-0pre020209
Severity: serious
Tags: patch
See below. C++ certainly does seem to be busted pretty badly at the
moment.
--- Begin Message ---
Hi,
following patch fixes the behavior of g++ for arm.
It is against the gcc-3_0-branch.
The difference can be seen by
tags 130422 + patch
thanks
see http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00627.html
plus some earlier analysis at
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=4860
>i am by no way a gcc literate person, so i just want to point out
>that the latest gcc-2.95 version doesn't build on arm, see the
>build logs on
>http://buildd.debian.org/fetch.php?&pkg=gcc-2.95&ver=2.95.4.ds8-1&arch=arm&sta
>mp=1010333265&file=log&as=raw
>for further details.
Yeah, Matthias and
The version of gpc in the 2001-12-23 upload doesn't seem to work on arm,
sparc, m68k or s390; they all seem to segfault somewhere during the build.
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings
-Wmissing-prototypes -Wmissing-declarations -g -O3
-DRTS_RELEASE_STRING="'
Does anybody know what the deal is here?
p.
--
if [ -x debian/patches/libffi-install.dpatch ]; then true; else chmod +x
debian/patches/libffi-install.dpatch; fi
if [ -f stamps/02-patch-stamp-libffi-install ]; then \
echo "libffi-install patches already applied."; exit 1; \
fi
debian/patches/l
>IIRC, the released version of gcc-3.0 is supposed to be moved to woody
>soon, especially if IA64, etc want to make this release cycle (Alpha may
>also switch to gcc-3.0, so it would need to be there for us as well).
The ia-64 people seem to want to stick with gcc-2.96. Personally I think this
i
>#103980- [PR c++/3702] gcc-3.0 copies constructors, a build error
> in the sfs package.
>#105246:- [PR c++/3774 arm] can't compile a trivial program including
>
I just downgraded those two to important. They have been forwarded upstream,
they aren't Debi
# these are bad, but not release critical
severity 105246 important
severity 103980 important
thanks
pgpLAocCVxWEe.pgp
Description: PGP signature
>What's the hold-up on the sid->woody move for gcc-3.0 (I haven't seen
>update-excuses yet)? I can't think of any reason to keep the version in
>woody around at all...
It has an RC bug, #105246. Update-excuses also mentions some problem with the
doc packages but this looks like it may be spurio
>It's used as a noun, but the same rules do not apply, atleast from what
>I remember from the english textbooks.
Oh. Maybe this is specific to American English; I don't think British English
treats acronyms or initialisms specially.
p.
pgpgcL66IFau0.pgp
Description: PGP signature
>No, we aren't talking about nouns, we are talking about acronyms. The above
>does not pertain to this use.
An acronym is still a noun. (And "80s" isn't an acroynm, anyway.)
p.
pgpU4M3HJgHOm.pgp
Description: PGP signature
>IMO, this is incorrect. The ('s) is always used for showing plural and
>possesive on things like "API's" or "80's". It just doesn't make sense
>without it.
>
>Then again, I never cared much for the language part of english class :)
No, James is right. This is the infamous grocers' apostrophe; Fo
>Phil disabled the softfloat package for arm, m68k doesn't build (yet),
>the other architectures don't built with multilibs configured. Let's
Yeah. I turned it off for arm because it isn't much use (and indeed prevents
the package from building) if you don't also have a soft-float version of
gl
>isnt it called GNU Compiler Collection?
>http://packages.debian.org/unstable/devel/gcc-3.0.html
Well, yes and no. The "gcc" package really is the GNU C Compiler, but its
description is a bit confusing. I'll update this in CVS. Thanks for the
report.
p.
pgpk22SnfWv83.pgp
Description: PGP
>should these reports closed?
You mean #81338? I'd just tag it "wontfix".
p.
pgp5OOjaUih0G.pgp
Description: PGP signature
The ARM port could use a new upload of gcc-2.95 for unstable. Matthias, do
you have any plan to do one soon?
Thanks
p.
pgpCIxnGZux39.pgp
Description: PGP signature
>I sincerely doubt that this will ever get past the Release Manager
>unless you have a very good, very specific reason. I recommend talking
>to him before spending your time.
I think it's worth making the packages even if the Release Manager (who is
that for potato these days, anyway?) won't acc
>the current 2.95.4 doesn't builf on s390, but 2.95.3, so it might be
>necessary to add a reverse-diff (for woody as well).
Is there any bug open for this? I couldn't find one from a quick look at the
lists for gcc and gcc-2.95. In any case I don't think we have to worry about
it for potato --
I think our current "gcc 2.95.4" is stable enough, and sufficiently better
than the 2.95.2 in potato, that we should consider making new packages to go
into 2.2r4 or whatever the next version is going to be. I guess this should
be straightforward enough to achieve.
Anybody object to this? If
>If nobody gets to it and if I can't find a good spot to pick that info up
>from, I'll change the hard-coded value on Saturday night or Sunday...
I wonder if you can use readlink on the libgcc_s.so that gcc creates, before
you blow it away.
p.
pgp3loUk20q7x.pgp
Description: PGP signature
>with gcc-3.0 yields a warning: "implicit declaration of function
>`strlen'" although strlen is declared in stdio.h according to
>the man page.
This is incorrect: strlen is declared in , not .
Refer to the glibc manual.
p.
pgpobqH4WjmBu.pgp
Description: PGP signature
>I think you need to add "libgc5-dev" to the gcc build-depends.
>Without that package installed, the package build fails in objc.
gcc-2.95_2.95.4.ds1-0.010506 has:
Build-Depends: dejagnu (>= 1.3-19990614), bzip2, binutils (>= 2.11.90.0.1-1),
deb
helper (>= 2), gperf (>= 2.7-3), autoconf (>= 2.
>Is there any mips or arm machine I could log into which has 2.95.4
>installed so that I could check the aleph package ?
I can do you an account on an arm machine. Send me a username and either a
crypted password or an SSH public key. Dunno about mips.
p.
>Okay... I'll look into this again in a couple of weeks... Let's give
>time to the autobuilders...
It's not actually a case of the autobuilders being behind; the current 3.0
package doesn't compile on ARM because of some soft-float related lossage.
I think I fixed the copy of the rules in CVS b
There is no bug here. "#pragma pack" isn't ignored on arm, it just doesn't
do what you expect it to. Try this; the second printf should yield the same
results on x86 and arm.
#pragma pack(2)
struct foo {
short a;
long b;
};
int main() {
struct foo f;
/* prints
>just uploaded a 2.95.4 package from the branch to incoming. This will
>fix #91823 as well?
Oh, right, cool. Yes, it's the same bug.
>btw, could you have a look at #90363?
Yeah, I'd forgotten about that one. Fortran is in pretty bad shape on ARM,
and I don't hold out all that much hope of get
Package: gcc-2.95
Version: 1:2.95.3-11
This patch fixes a problem compiling binutils on ARM. It's already installed
on the 2.95 branch in CVS, but if future packages are going to use the 2.95.3
tarball it would be good to have this included.
#! /bin/sh -e
# DP: Fix for SUBREG problems
src=gc
83 matches
Mail list logo
