Franz Sirl, the ppclinux devtool maintainer, has kindly
built the current rawhide XFree86 4.3.0 srpms against
gcc-3.3 from 6/18/03 on Yellow Dog Linux. He is unable to
reproduce the authentication problems we see on debian
under either xdm or kdm. Perhaps we build XFree86 differently
enough fro
Matthias,
This issue doesn't exist for /usr/lib/libgcj.so.4
ldd -r /usr/lib/libgcj.so.4
libpthread.so.0 => /lib/libpthread.so.0 (0x0fae)
libdl.so.2 => /lib/libdl.so.2 (0x0fdd)
libz.so.1 => /lib/libz.so.1 (0x0fc8)
libgcc_s.so.1 => /lib/libgcc_s.so.
Package: libgcj2
Version: 3.0.4-12
The shared library, /usr/lib/libgcj.so.2, has undefined
non-weak symbols as shown with below...
ldd -r /usr/lib/libgcj.so.2
libpthread.so.0 => /lib/libpthread.so.0 (0x0fbc)
libdl.so.2 => /lib/libdl.so.2 (0x0fdd)
libgcc_s.so.1 =>
Does anyone know if the anonymous cvs access to the
different branches of debian-gcc on cvs.debian.org has
been disabled on purpose? I am trying to checkout the
current gcc-3.3 package with...
cvs -z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/debian-gcc login
cvs -z 9 -d :pserver:[EMAIL PROTECTED]
Matthias,
I rebuilt your test debian binutils 2.14.90.0.1-0.1 package
on my debian ppc sid box and it looks fine. The places where we diverge
are...
your build...
=== binutils Summary ===
# of expected passes28
# of untested testcases 4
and my build
Matthias,
In comparing the current failures in the new build of 3.3-0pre9
on debian ppc sid to those Mark Mitchell obtained on a YDL ppclinux
box (http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00553.html)
I noticed that we are failing 2 extra c++ tests...
FAIL: g++.dg/parse/crash2.C (test
I am wondering if there is a gameplan on adding the support for
enabling TLS support in the devtools in sid. In particular, in trying
to build the current debian glibc cvs 2.3.2-1 release I noticed that
linuxthreads support was broken upstream. Uli seems to think this
will happen more frequently
This should be fixed upstream now...
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02409.html
In case anyone is interested Jakub responded on this compile warning
in elfutils. RedHat apparently is backporting support for the
visibility attribute directive from gcc 3.3 into their gcc 3.2. The
other options are to use gcc 3.3 itself or, easiest, to not use
-Werror when building elfutils wi
Has anyone tried to build elfutils 0.72 from rawhide on debian
using our gcc-3.2? I thought I would try to build it since redhat
is using that instead of libelf from now on to link into their
prelink binary. I found that on debian ppc sid we get a build failure
(with libelf0-dev deinstalled to p
Typo...the test was...
objdump --all-headers /usr/lib/libgcj.so.3.0.0 | grep TEXTREL
TEXTREL 0x0
...of course.
Jack
Package: libgcj3
Version: 3.2.2-0pre3
On debian ppc sid, the /usr/lib/libgcj.so.3.0.0 shared lib
appears to have non-PIC static lib code linked in which is
a violation of debian policy. This probably is a upstream
(non-debian) problem as I see this on the same lib from
Franz Sirl's redhat based gc
I assume that we were waiting on gcc 3.2.1 to arrive for
the switchover of sid to to gcc-3.2 to happen. Once all the arches
have gcc 3.2.1 release built for them what is the plan for the
migration? I haven't seen it mentioned lately.
Jack
Is anyone else seeing this? On doing an apt-get dist-upgrade
on debian ppc sid tonight I had a bunch of problems with libstd-c++
going missing. It appears that we have stopped using the name
/usr/lib/libstdc++-libc6.2-2.so.3 and changed it to
libstdc++libc6.2-2.so.3 causing a bunch of binaries t
Dan,
We seem to be suddenly failing 7 additional libstd-c++ tests
in last nights gcc-3.2 build. This isn't happening on entropy so
I am wondering if we have lost those keymaps essential for the
testsuite to pass. If I recall correctly keymaps for French, German
and Itailian have to be installed
Matthias,
Have you tried using the new bison 1.75 release from ftp.gnu.org?
Perhaps you might have better luck with the gcc 3.2.1 builds using that
one.
Jack
Now that glibc 2.3.1 is in sid, what are the plans
for the transition to gcc 3.2.1? I am assuming we are
waiting for the official gcc 3.2.1 release. That should
be soon however. Are we still planning a bulk rebuild
of each arch? I believe ppc should be in excellent shape
for the transition. The
Matthias,
I'm not sure. I know I was told that hppa was okay. Also from my
conversations with Jakub it appears i386, ia-64, alpha and sparc32
should be fine. So I would suggest we focus on checking the status
of arm, hurd-i386, m68k, mips, mipsel, s390 and sh. I'm not sure
how many of those arch
Matthias,
It appears this problem is specific to binutils. Alan Modra has a
fix applied to binutils cvs. While the fix didn't make it into
binutils 2.13.90.0.10, I passed it along to Chris for our deb packages
of 2.13.90.0.10.
Jack
Matthias,
You might want to do a test build of gcc-3.2.1 against the new
bison 1.50-1. I have found that this new bison breaks the binutils
build. Not sure yet if this is a bison bug or a flaw in the binutils
build process. Hopefully not that may packages will be bit by this.
Regressing to biso
Matthias,
Ben Collins suggest this should be passed off to you as a
Build-Depends and Depends for gcc-3.2. On ppc (and perhaps all
arches) we should have the minimal binutils set to 2.13.90.0.6
or greater once Chris Chimelis solves his hardware problems
and can get new debian binutils packages
Hi,
If anyone has run my findsyms perl script..
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00148.html
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00164.html
...and has results for a particular arch, they may want to share this
information upstream wit
On debian ppc sid, with glibc 2.2.93 installed and Linux 2.4.20pre7
I am seeing a new build failure in the current gcc 3.2.1pre2 source
package...
/bin/sh ../libtool --tag CXX --mode=compile
/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/xgcc -shared-libgcc
-B/home/howarth/debian-gcc32
Package: gcc-3.2
Version: 3.2.1ds1-0pre2
The current source package will fail to patch properly if
any automake other than automake-1.4 is installed. We need to
change the debian/control file to Build-Depends on automake-1.4
and change all of the dpatches to have automake-1.4 instead of
automak
It appears the rej I am seeing in trying to build the
current gcc-3.2 packages from source is...
bogus:/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/src/libstdc++-v3/src# more
Makefile.in.rej
***
*** 416,422
installcheck: installcheck-am
install-info-am:
install-info: in
Has anyone tried rebuilding the gcc 3.2.1-0pre2 package since
coreutils went in yesterday? I am seeing a patching failure now
on debian ppc sid...
if [ -f stamps/02-patch-stamp-libstdc++-pic ]; then \
echo "libstdc++-pic patches already applied."; exit 1; \
fi
debian/patches/libstdc++-pic.dpat
Hello,
Is anyone else seeing breakage of OpenOffice.org 1.0.1-5 after
updating gcc-3.2 to the latest 3.2.1-0pre2 from 20020912? I see
lots of errors of the form...
14922: /usr/lib/openoffice/program/libsal.so.3: error: relocation error:
undefined symbol: component_canUnload (fatal)
when I do
Package: libstdc++4
Version: 3.1.1-3
This newest version conflicts with the current gcc-3.2-nof as follows..
Unpacking replacement libstdc++4 ...
dpkg: error processing
/var/cache/apt/archives/libstdc++4_1%3a3.1.1-3_powerpc.deb (--unpack):
trying to overwrite `/usr/lib/nof/libsupc++.la', which
Matthias,
On reflection, you might want to add a Build-Depends on
expect (>= 3.80-1) to the gcc-3.2 debian/control file to
ensure that none of the build machines ever build against the
older expect from woody which will give spurious false failures
in the test-summary. FYI, I have done yet anot
Daniel,
Just a heads up that Franz Sirl revised his mozilla 1.1 patch
for building with either gcc 3.1.1 or 3.2 on ppc. I have tested
this patch with gcc 3.2-0pre4 on mozilla-snapshot from 07/16/02
and it works fine. A bug report with the attached patch has been
filed against mozilla-snapshot..
Matthias,
Now that binutils 2.13.90.0.4-1 is installed on the build machines
and debian glibc-cvs has a new pull from the glibc-2-2-branch containing
the new ppc libgcc-compat code, we need to set a Build-Depends
in gcc-3.2 for the next release of the package. This Build-Depends
should be set t
Hello,
I would like to make a proposal for one aspect of the
gcc 3.2 migration in sid. A critical part of this transition
will be the discovery of how many arches still require creation
of libgcc-compat code in glibc. Currently we are told by Jakub
Jelinek that i386 is fine. Franz Sirl has just
gotom,
The revised gcc-3.2-compatible sysdeps/powerpc/libgcc-compat.S code
is now checked into glibc-2-2-branch. I have built both the straight
glibc-2-2-branch checkout as well as debian glibc packages based off
of the 2.2.5-14 source package, by creating a new cvs patch vs the
current glibc-2-
Steve,
There shouldn't be huge issues in the gcc 2.95.4 to gcc 3.2 transition.
Currently the only two major ones I know if are...
1) Rebuilding glibc with gcc 3.2 *may* require an arch to add a libgcc-compat
section to provide libgcc symbols, now .hidden in gcc 3.2's libgcc_s.so,
with lo
I noticed in building the current debian gcc-3.2 packages that
I was getting a couple failures that Franz Sirl wasn't seeing
on his ppclinux development machine. HJ Lu logged in and confirmed
that these tests were reporting false falures and were in fact passing.
He suggested I consider looking
Matthias,
Well actually it will effect builds as soon as glibc 2.2.5-14
goes in with the correct sysdeps/powerpc/libgcc-compat.S code
(which hopefully Franz will push today into glibc-2-2-branch).
The current glibc 2.2.5-13, built under gcc 2.95.4, in libc.so.6
doesn't have a dynamic symbol for
Actually Jakub sent me the following e-mail just
a few moments ago...
--
On Thu, Aug 15, 2002 at 08:28:18AM -0400, Jack Howarth wrote:
> Jakub,
>Can I assume you actually checked all the other
> arches that redhat has shippe
Hi,
I am not filing a bug on this right now, but you should
all be aware that any arch that wants to switch to gcc 3.2
as its default compiler will need to address the following
issue. The libgcc symbols starting in gcc 3.1 are now .hidden
which means breakage of old binaries occurs when gcc 3.1
Package: gcc-3.2
Version: 3.2ds0-0pre4
The Build-Depends in debian/control should have
gnat-3.1 [!arm !hurd-i386 !m68k] | .gnat-3.2 [!arm !hurd-i386 !m68k]
since gcc-3.2 might already be installed.
Package: gcc-3.2
Version: 3.2_3.2-0pre4
Severity: grave
On ppc, there will be version requirements, for properly building
and installing gcc-3.2, on the glibc and binutils installed. See
bug report 155606 for a description of this issue. The needed binutils
will likely be version 2.13.90.0.4-1 and
To give you fellows a better idea of the symbol issues we are
dealing with on powerpc in glibc for the transition to gcc 3.2,
consider the differences below...
for stock glibc 2.2.5-13 (no libgcc-compat code at all)...
[EMAIL PROTECTED]:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3
[EM
Okay, HJ Lu has helped resolve the remaining issues in our transition to
building glibc under gcc 3.2. There have been several critical binutils
bugs fixed related to this issue that Chris Chimelis will get into the
next binutils package. The remaining portion of this is the attached patch
from Fra
Jan,
There definitely will be an issue with rebuilding glibc against
either gcc 3.1.1 or 3.2 on at least two, if not more, arches. The
problems arise from the change in gcc 3.1 which makes libgcc symbols
.hidden now. This means that if you rebuild the current glibc
2.2.5-13 with gcc 3.1.1/3.2,
Chris and Matthias,
It appears that binutils is definitely not the culprit with
gcc-3.1-3.1.1ds3-1's failure on debian ppc sid. I see the same
failure with the build of gcc-3.1-3.1.1ds3-1 on my machine with
a locally built binutils 2.12.90.0.15 installed as we do on
voltaire. However, I still am
Well it doesn't look like its binutils so far. I tried building
the current gcc-3.1-3.1.1-ds3 source package against current debian
sid and my local 2.12.90.0.15 binutils and it fails in the same
manner. I am now rebuilding my local gcc-3.1.1 package which is based
on the debian rules/patches d
What happened to the gcc 3.1.1 build on debian ppc sid? It looks
horribly broken from the log. I ask because I built locally a
gcc 3.1.1 package using the previous pre3 debian packaging patches
and rules and the gcc 3.1.1 official release tarballs. It built
fine and passes all of the test suite
In case anyone is interested, I finally pinned down why the
GL server extension, libGLcore.a, from the XFree86 4.2.0-0pre1v1
package built under gcc 3.1.1 doesn't load properly. It appears
that when building under gcc 3.1.1, we become like alpha on ppc
and can no longer do a 'strip --strip-debug
Daniel,
What about the libgcc_s.so.1? I assume we are assured of compatibility
in using a libgcc_s.so.1 from gcc 3.2 with binaries built with gcc 3.1.1
then?
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
Daniel,
Well if gcc 3.1.1 instantly disappears the moment gcc 3.2 hits the pool,
won't that force openoffice/stl to deinstall on a dist-upgrade? It would
nicer if we allows folks a grace period for their apps to get rebuilt
before yanking the supporting libs they need.
I noticed that the new gcc-3.1_3.1.1ds3-1 changelog notes that
gcc 3.1.1 will go away when 3.2 arrives. Do we plan on having a period
of time (say a month) where both 3.1.1 and 3.2 will co-exist in the
sid pool? That might be a good idea to allow folks to recompile any
packages that they might
Martin,
I think the primary problem debian will have with gcc 3.2 (or
3.1.1 for that matter) is dealing with rebuilding glibc under it.
Because the gcc 3.1 fixed a bug relating to incorrectly linking in
libgcc symbols into binaries, glibc trunk and glibc-2-2-branch have
fixes to address this thr
Phil,
Actually, it looks like it will be trivial to build these packages
anyway. Using the release tarball and the current debian directory from
the last gcc-3.1-3.1.1ds2 pre3 build, all of the patches apply cleanly.
So all anyone needs to is 'apt-get source gcc-3.1', replace the
gcc-20020703.ta
Sorry. I posted it because there appears to be a lag
between when the tarballs are posted and the announcement
of their availablity. The gcc 3.1.1 announcement still hasn't
been made...perhaps to allow the mirrors to populate. In any
case, this was more of a wishlist bug report and a heads up
o
Package: gcc-3.1
Version: 1:3.1.1-0pre3
The official gcc 3.1.1 release tarballs are now available
at gcc.gnu.org's ftp site in /pub/gcc/releases/gcc-3.1.1.
Can we get a new build with of this package with the official
release?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
Hello,
Has anyone else tried to rebuild Branden's test xfree86 4.2.0-0pre1v1
packages against the current gcc 3.1.1? On debian ppc sid, I find that
while the build appears to work in general there is at least one glitch
compared to the gcc 2.95.4 build. I see under the gcc 3.1 packages the
follo
Hello. Will you guys actually try building a gcc 3.1 without
the patch and testing a test case before you close this bug
again. Please reference the slew of quoted messages in the
debian-gcc mailing list from HJ Lu and Jakub Jelinek. The current
glibc (>= 2.2) provides __cxa_atexit and Linux and
kub Jelinek <[EMAIL PROTECTED]>
To: Jack Howarth <[EMAIL PROTECTED]>
Cc: gcc@gcc.gnu.org
Subject: Re: why debian uses --use-cxa-atexit
Reply-To: Jakub Jelinek <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Conte
Martin,
As I said in my previous message, we are NOT losing __cxa_atexit.
By dropping the current patch we are using the __cxa_atexit
provided by glibc >= 2.2 instead of the one provided by gcc itself.
That is what HJ and Jakub are trying to make debian understand.
The using gcc to provide __c
---
>From [EMAIL PROTECTED] Sat Jun 1 22:16:07 2002
Date: Sat, 1 Jun 2002 19:15:36 -0700
From: "H . J . Lu" <[EMAIL PROTECTED]>
To: Jack Howarth <[EMAIL PROTECTED]>
Subject: Re: PATCH: Add --enable-__cxa_atexit
References: <[EMAIL PROTECTED]> <[E
One other thing. When we drop the g++-cxa-atexit.dpatch
patch from gcc 3.1, we should change the debian/control to make
gcc build depend and depend on a glibc >= 2.2. This is the
requirement to ensure that __cxa_atexit is provided via
atexit from glibc.
Jack
--
To
HJ Lu has requested that we regress out the g++-cxa-atexit.dpatch
patch. He says that he doesn't intend to fix binutils to resolve
the breakage because all glibc > 2.2 have been providing a completely
usable __cxa_atexit via atexit making the use of -fuse-cxa-atexit
unncessary. That is also why I
I went back and looked at the origin of this g++-cxa-atexit.dpatch
patch...
http://lists.debian.org/debian-gcc/2001/debian-gcc-200106/msg00162.html
http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00664.html
and decided to try the test case (it needs a correction...test.C is
missing a
#include
Package: gcc-3.1
Version: 3.1-2
In rebuilding binutils 2.12.90.0.7-1 with gcc-3.1-2 on debian ppc sid
I discovered that this causes binutils to have a new unexpected failure
in its testsuite...
Running /home/howarth/debian-binutils/binutils-2.12.90.0.7/build-tree/binutils-2
.12.90.0.7/ld/testsuit
Package: gcc
Version: 3.1-2
It appears that the build scripts for the gcc 3.1 package are
flawed in setting the configure paramaters. I find that when
I build this package on debian ppc sid, the resulting gcc shows
gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/3.1/specs
Configured wit
combreloc.
Jack Howarth
combreloc.
Jack Howarth
Matthias,
The new gcc-2.95.4 package builds fine on debian ppc woody.
Also I am able to now build glibc 2.2.3-1 using the resulting
gcc 2.95.4.
Jack
Is there a particular reason why the tarball for building gcc-2.95
2.95.4.ds1-0.010502 was not uploaded to incoming.debian.org? Could
someone please get it up there with the rest of the files for that
version of the package? Thanks.
Jack
Hello,
In case Franz Sirl hasn't passed this along the problem with
current gcc 2.95.4 building glibc 2.2.3 can be worked around
with a hack similar to gcc/varasm.c
@@ -4344,8 +4350,15 @@ declare_weak (decl)
{
if (! TREE_PUBLIC (decl))
error_with_decl (decl, "weak declaration of `%s' m
ibdb2
can no longer be built. I regress from sid to woody last night
for this very reason and now the flaw has migrated over.
Can you please regress the ppc version of woody back to the last
gcc 2.95.3 version that was there yesterday.
Jack Howarth
ps the build of l
70 matches
Mail list logo
