We've discovered a critical problem with the multiarch proposal. I
don't know where to send this, but it needs to be sent somewhere!
(I said):
>>Why not just use the canonical system name?
Goswin von Brederlow wrote:
>
>
> No reason. But how do we get that name?
>
> The existing multiarch prop
Matthias Klose wrote:
>anyway, I'll wait until Debian's position on the GFDL is documented
>somewhere and then address all these together.
It's pretty well documented by now. So is it time? :-P
I'm sorry I haven't had the time or mental focus to write replacement
manpages, but the {cpp, gcc, g++
Matthias Klose wrote:
> about 150. attached is a list of source packages, which either define
> mt_alloc symbols or reference them. libraries depending on kdelibs do
> not have to be renamed (about 30/40).
Um, out of curiosity, why don't they? They didn't need to be renamed
for 'c2' because KDE ha
tags 336114 +upstream
forwarded 336114 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
thanks
Forwarded upstream as GCC bug number 24712.
--
Nathanael Nerode <[EMAIL PROTECTED]>
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to [EMAIL PRO
ommit which caused this.
--
Nathanael Nerode <[EMAIL PROTECTED]>
"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,
http://lists.debian.org/debian-devel/2005/09/msg01056.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
Has this been reported to the libstdc++ list upstream? It doesn't look like
it, and it's certainly their thing.
--
Nathanael Nerode <[EMAIL PROTECTED]>
[Insert famous quote here]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
I sent a message about this earlier, but it seems to have gotten lost.
> On Saturday 08 October 2005 22:38, Nathanael Nerode wrote:
> > Disgustingly, I worked out that we could have revived real i386 support
> > for etch thanks to changes in gcc-3.4 and gcc-4.0 which nobody
Frans Pop wrote:
> Do you mean that the security-flawed kernel patch would not have been
> needed?
Yes. For those interested, the full story is as follows.
gcc-3.3 contained inline functions in the C++ header atomicity.h -- included
by nearly every C++ program, and thus part of the binary inte
> > * or a bug in ld.so -- inability to handle correctly specified multiple
GOTs
> > for more than 16k global symbols
Thiemo wrote:
>
> That (it shouldn't segfault), and/or potentially also a bug in ld which
> leads to failure for large MultiGOT binaries.
Rocking. It looks like most people inv
Daniel Jacobowitz wrote:
> It's a lot of work to fix and no one has done it. That's not the same
> thing at all.
That's nice, but there's still a real problem unrelated to that.
An example of a relatively healthy bug which is "a lot of work to fix and no
one has done it" is http://gcc.gnu.org/b
Thanks *very much* for your help explaining this mess.
Thiemo Seufer wrote:
> - A too large object file can overflow plain GOT. This is not only
> MIPS-specific, it affects several architecture's toolchains,
Right, it would affect any architecture which does silly things like having a
16-bi
Thiemo Seufer wrote:
>You are mistaken (since I'm also upstream)
Upstream for binutils? Yes, you're one of two MIPS maintainers, second after
Eric Christopher, and there are also nine global maintainers.
And apparently nobody has documented this bug in the documentation for ld, or
bfd, or binut
>> Apparently the MIPS ABI is just plain broken. It contains some sort of
>> impassable hard limit on relocation table size, breaking random packages at
>> random times with no possible fix. Nobody can fix this without changing
>> the ABI.
>
Thiemo Seufer wrote:
>That's wrong.
OK. Can someb
Andreas Barth wrote:
Actually, there is one criterion missing: Does this bug really hurt us
bad (enough)? And my current answer to this is no, but of course, you
might want to persuade me. :)
...
So, I think we can say that this bug is even forwarded to upstream, as
mips Inc is aware of it and
or a long time by now. There is no other mention
in the GCC changelog as to why GCJ is disabled for mips and mipsel. The only
other explanation I have found is Thiemo's.)
--
Nathanael Nerode <[EMAIL PROTECTED]>
A thousand reasons. http://www.thousandreasons.org/
Lies, theft, war,
Nathanael Nerode writes:
> This is no way to get a bug fixed. If this is seriously the level of
> attention to mips and mipsel, Debian support for them should be dropped.
Matthias Klose wrote:
>sorry, this attitude has nothing to do with release management, it's
>just ranting.
[EMAIL PROTECTED]:
>The toolchain (more specifically: ld) can't handle the gcj runtime
>build yet. Btw, ghc triggers the same problem, there were several
>reports filed for the various instances of this bug.
Ah, I see. So it's binutils which can't handle it. No wonder I couldn't find
any bug re
ps, unless you
know something I don't?
This would probably make kaffe work on mipsel automatically as well (and
allow it to work with ecj on mips). Cc:ing pkg-java-maintainers in case they'd
like to switch kaffe back to ecj on mips.
--
Nathanael Nerode <[EMAIL PROTECTED]
GCC 4.0 no longer includes the i486-specific code in the C++ include file
atomicity.h. It's no longer inline.
This means we could theoretically go back to compiling everything for i386
rather than i486, support stock i386 kernels, etc.
But there've been so many changes to accomodate the i486 def
Matthias Klose wrote:
>it's pending an upload (as the definition of pending in the BTS
>suggests). I'm sure you did read as well
>http://lists.debian.org/debian-devel-announce/2005/07/msg00013.html
Oh bleck. I forgot about that. Of course nothing can happen until that's
dealt with. :-P At any
>> GCC bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 causes problems
>> for the X.Org X server. We currently have a work around in place for the
>> most noticeable issues, but code potentially displaying this problem is
>> scattered throughout the X.Org codebase, particularly in different
Kurt Roeckx wrote:
> On Mon, Mar 29, 2004 at 11:37:20PM +0200, Matthias Klose wrote:
>> Kurt Roeckx writes:
>> > I'm trying to build the gcc-3.3 package but I seem to have a
>> > dependency problem building it.
>> >
>> > gcc-3.3 depends on gnat-3.3 | gnat-3.2
>> > gnat-3.2 (gcc-3.2) depends on gn
The newest version corresponds to 3.3-branch CVS from December 6.
I added a patch to the branch on December *10th* which is important to
X-Windows (it's this change to cpptrad.c):
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cpptrad.c.diff?r1=1.28.2.1&r2=1.28.2.2&f=h
It would be nice if this could
esired at some point, it can be done as an
architecture-specific transition (requiring mass recompilation, but only on one
architecture). (But presumably nothing like this should be done before
sarge releases.)
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
Etienne Gagnon wrote:
Hi Nathanael,
Could you reply to both parts of this message? Thanks.
PART I
==
Nathanael Nerode wrote:
> There is really nothing wrong with sharing install-sh & friends. Lots
> of packages do it.
This is not true. The GNU GPL version 2, section 2 says:
There are no "deep source dependencies".
There is really nothing wrong with sharing install-sh & friends. Lots
of packages do it.
You can delete all the directories except libffi (and possibly config),
and delete all the files at the top level and 'config' which are under
the GPL, and you can s
Known issue. You need to specify --main on the command line, as follows:
gcj primerprog.java --main=primerprog
This should be downgraded to 'wishlist', since it's documented. In
multi-class projects, it's obvious that you need to do this. There are plans
to eventually make gcj clever enough
The current version built everywhere else (except hppa, which you can't
do anything about since it's glibc's fault), so things are pretty close
to ready
Maybe someone should contact upstream gpc about this.
And/or disable gpc on arm for now. :-P
--
Nathanael Nerode
http://home
-specific part, which isn't anything to
do with upstream gcc. :-/ Evil gpc.
hppa is toast due to glibc, so I don't even know what to say about KDE there.
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
debian-legal has concluded that in its current form the GNU FDL is *never*
free.
If several clauses were fixed, it might become free when no Invariant
Sections were used, but so far the FSF has shown no inclination to fix any of
these clauses in a timely manner.
Accordingly, it is time to remo
The gcj binary packages which are not supported on hppa/mips/mipsel need the
following line:
Architecture: i386 m68k sparc alpha powerpc arm ia64 s390 sh hurd-i386
netbsd-i386 netbsd-alpha freebsd-i386
Or perhaps just:
Architecture: i386 m68k sparc alpha powerpc arm ia64 s390
(forgetting about t
It somehow seems not to have installed doxygen, for unknown reasons.
Hopefully this can be resolved ASAP? ...
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
Steve Langasek wrote (in
http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg7.html):
>Does this mean that the gcc maintainers don't agree with this list's
>interpretation of the GFDL, or that they don't regard this as a high
>priority between now and the release?
I believe that
The -V feature is deprecated upstream and will hopefully be abandoned
sometime soon (though GCC developers generally leave old cruft around for a
*long* time). Just don't use it. :-/
entiumpro];
And the comments in the various patches should be updated accordingly.
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
TARGET_CPU_DEFAULT];
>+ix86_cpu_string = cpu_names [TARGET_CPU_DEFAULT_pentiumpro];
> if (!ix86_arch_string)
>-ix86_arch_string = TARGET_64BIT ? "athlon-4" : "i386";
>+ix86_arch_string = TARGET_64BIT ? "athlon-4" : "i486";
I beli
reason to drop 486 support under Linux. So for Linux,
it would be -mcpu=i486 -mtune-i686 as the default, correct?
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
cted by the Debian project in
favor of the emulator. (I can certainly understand why, since it's a
lot easier!)
>they're not updated that often. Please don't cut their update pathes...
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
D is not present, it can be
treated as 486. So anyone asking for more processor-specific
optimization can be told to write it themselves.) :-)
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
It looks like gcc-defaults depends on gcj-3.2 on sparc. Or at least
the 'testing' scripts think so. Huh? :-/
--
Nathanael Nerode
http://home.twcny.rr.com/nerode/neroden/fdl.html
Package: gcc-3.3
Version: 1:2.2.1ds2-0rc2
Severity: important
Justification: breaks lots of software builds
There's an ICE building ARTS on ia64, which holds up all of KDE among many
other things. It probably affects other software on IA64 as well. This is
fixed on the gcc-3.3 branch in GCC CV
A bug in gcc 3.3 branch on ia64 just bit ARTS. (PR target/10681)
The bug was fixed *today* in GCC CVS. (As of 2 hours ago).
So it would probably be a good idea to upload a new gcc-3.3 incorporating
this fix ASAP so as to delay ARTS and its dependent packages as little as
possible. I know you j
Matthias Klose wrote:
fastjar/fastjar.texi
fastjar/fastjar.info
fastjar/grepjar.1
fastjar/jar.1
Interesting. As I did write these, I do have the right to relicense
and distribute them?
Check the agreement you signed with the FSF; you probably do. But you
should check for modifications made by oth
The GCC source tarball contains, well, a lot of things. The following are
FDLed with invariant sections or cover texts and so non-free:
Entire contents of INSTALL/
fastjar/fastjar.texi
fastjar/fastjar.info
fastjar/grepjar.1
fastjar/jar.1
Entire contents of libstdc++-v3/docs
Entire contents of gc
Important citations:
* Motion to take action on the unhappy GNU FDL issue (by Branden
Robinson)
http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00189.html
(Note that the following discussion contains lots of agreement and no
serious opposition.)
* Proposed statement wrt GNU FDL
to debian-legal, so these packages must
be moved to non-free as soon as possible.
--Nathanael Nerode
(gcc developer)
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux doctormoo 2.4.20ncn #1 SMP Mon May 5 16:46:31 EDT 2003 i686
Locale: LANG=C, LC_CTYPE=C
Package: gcc-3.2-doc
Version: all
This package contains no 'copyright' file, but /usr/share/doc/gcc-3.2-doc
links to /usr/share/doc/gcc-3.2-base. The 'copyright' file there makes no
reference to the copyright which the documentation is under -- a version of
the GNU FDL. This violates Policy 2
Further investigation indicates that it's almost certainly due to bogus line
breaks in the middle of the command line. This appeared when autobuilding
ds3-0pre3, but not ds2-0pre3, and only on ARM.
I still don't know where the line breaks are coming from.
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 embedded
carriage returns in it (though that could be an artifact of the
logging). That's as f
Matthias Klose wrote:
>we need to make g++-3.2 the standard C++ compiler at the same time, or
>else we get problems linking binaries with g++, where some C modules
>are built with gcc-3.2. We are currently working on a transition plan.
Hmm. Care to share what that transition plan looks like so fa
This is a Pascal-specific problem. GPC support for gcc 3 series is still
considered "alpha".
Is there some way to make sure the rest of the packages build even when
Pascal is broken, perhaps?
--Nathanael
Just curious, what exactly still needs to be done before gcc 3.2 can
become the standard system compiler for sid?
Maybe I can do some of it?...
--Nathanael
52 matches
Mail list logo
