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
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.1
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
null password
cvs -z 9 -d
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
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
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
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
Typo...the test was...
objdump --all-headers /usr/lib/libgcj.so.3.0.0 | grep TEXTREL
TEXTREL 0x0
...of course.
Jack
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
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
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.
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,
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
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
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
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
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
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:
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
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
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
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
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
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
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
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 shipped a linux
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
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.
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
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
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
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
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
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
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
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
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
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
Content-Disposition: inline
User-Agent
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
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
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
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
.
Jack Howarth
.
Jack Howarth
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'
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 libdb2
51 matches
Mail list logo
