Bug#148192: configuration error in gcc 3.1
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 with: /src/gcc/gcc-3.1-3.1ds2/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=$(prefix)/share/man --infodir=$(prefix)/share/info --with-gxx-include-dir=$(prefix)/include/g++-v3-3.1 --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --enable-clocale=gnu --enable-threads=posix --enable-java-gc=boehm --enable-objc-gc powerpc-linux Thread model: posix gcc version 3.1 (Debian) whereas the rpm packages for ppclinux that Franz Sirl did on entropy.crashing.org produce fully expanded entries in the gcc -v response for --mandir, --infodir, --with-gxx-include-dir, etc. That is $(prefix) in the above output should have been expanded to /usr. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148651: gcc 3.1-2 patch breaks binutils builds
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/testsuite/ld-srec/srec.exp ... PASS: S-records FAIL: S-records with constructors It appears the origin of this problem is the use of the g++-cxa-atexit.dpatch patch in the build of gcc-3.1. This patch is not used in the RedHat gcc 3.1 srpms. If I rebuild gcc-3.1-2 with the g++-cxa-atexit.dpatch patch disabled and then install that gcc-3.1-2 and rebuild binutils 2.12.90.0.7 (or 2.12.90.0.9) I find that the unexpected binutils failure has disappeared from the testsuite results. I have forwarded this information to HJ Lu so he can look into whether the use g++-cxa-atexit.dpatch breakage is due to a bug in gcc or binutils. For now unless there is a pressing reason to use it we should disable that patch. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
is g++-cxa-atexit.dpatch still needed
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 I found the following. I can compile it with either gcc 3.0.4 with the g++-cxa-atexit.dpatch patch or with my own local copy of gcc 3.1 which has the g++-cxa-atexit.dpatch removed. In either case I get.. In main In shared object Back in main Shared object going away... Goodbye, world. I also built the test programs on entropy.crashing.org using Franz Sirl's toolchain that uses an srpm that also doesn't use int flag_use_cxa_atexit = 1; In that case it also passes the test case properly. It seems to me that if the only reason we included the g++-cxa-atexit.dpatch was to satisfy the known problem... Global destructors are not run in the correct order. Global destructors should be run in the reverse order of their constructors completing. In most cases this is the same as the reverse order of constructors starting, but sometimes it is different, and that is important. You need to compile and link your p ...that we don't need this patch and it is undesirable because 1) no other distro is using it and FSF has this flag off by default in all compiler releases 2) it currently causes breakage in binutils Jack -- Jack W. Howarth, Ph.D.231 Albert Sabin Way NMR Facility Director Cincinnati, Ohio 45267-0524 Dept. of Molecular Genetics phone: (513) 558-4420 Univ. of Cincinnati College of Medicinefax: (513) 558-8474 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148651: gcc 3.1-2 patch breaks binutils builds
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 am able to pass the original test case from... http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00664.html without the g++-cxa-atexit.dpatch patch in my gcc 3.1 and without using -fuse-cxa-atexit. Apparently debian are the only distro to use the gcc provided __cxa-atexit and it hasn't been throughly tested compared to the glibc provided one. If you have any questions on this you can ask HJ Lu <[EMAIL PROTECTED]>. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148651: gcc 3.1-2 patch breaks binutils builds
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 UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is g++-cxa-atexit.dpatch still needed
Martin,
Have you tried running the orginal test case from
http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00664.html
with gcc 3.1 built without the g++-cxa-atexit.dpatch.
Both HJ Lu and Jakub Jelinek have been trying to make
clear that since glibc 2.2 the -fuse-cxa-atexit is unnecessary
because __cxa_atexit is no provide through the glibc
atexit call. That is why you can build gcc 3.1 without
the patch and it passes the test case with or without
being compiled with -fuse-cxa-atexit. The patch is totally
uncessary.
Jack
---
>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]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sat, Jun 01, 2002
at 09:08:54PM -0400
On Sat, Jun 01, 2002 at 09:08:54PM -0400, Jack Howarth wrote:
> HJ,
> I have gone back over the debian mailing list and found
> the origin of their g++-cxa-atexit.dpatch which does...
>
> --- src/gcc/cp/decl2.c~ Wed Jun 6 23:51:11 2001
> +++ src/gcc/cp/decl2.cSat Jun 23 13:40:36 2001
> @@ -401,7 +401,7 @@
> /* Nonzero to use __cxa_atexit, rather than atexit, to register
> destructors for local statics and global objects. */
>
> -int flag_use_cxa_atexit;
> +int flag_use_cxa_atexit = 1;
>
> /* Nonzero to not ignore namespace std. */
>
> The origin is in...
>
> http://lists.debian.org/debian-gcc/2001/debian-gcc-200106/msg00126.html
> http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00664.html
>
It isn't needed by the current glibc. I will recommend to drop this
patch from Debian's gcc. I won't apply that patch to my gcc 3.1 nor do
any tests with it.
H.J.
-
>From [EMAIL PROTECTED] Sat Jun 1 22:24:27 2002
Date: Sat, 1 Jun 2002 19:23:57 -0700
From: "H . J . Lu" <[EMAIL PROTECTED]>
To: Jack Howarth <[EMAIL PROTECTED]>
Subject: Re: debian
References: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sat, Jun 01, 2002
at 05:32:24PM -0400
On Sat, Jun 01, 2002 at 05:32:24PM -0400, Jack Howarth wrote:
> HJ,
>Debian has just upgraded to gcc 3.1.1-pre1 from the cvs but it seems
> they still have the patch for using __ca_atexit in place. Are you going
> to try a gcc build there with that feature enabled and debug binutils
> to see why the testsuite has the s records failure?
>I ask because the traffic on the gcc mailing list was confused yesterday.
> I got the impression in the end that you had decided to try to help
> regress all use of __ca_atexit out of gcc or was that incorrect? Do other
But Jakub convinced me that Linux doesn't need __ca_atexit from gcc.
I decided not to bother.
> OS's beside linux need that? I know it was claimed that atexit in linux
> was as fast as __ca_atexit but I was unclear if some other OS needed that
> to be retained in gcc. Thanks for any clarification.
Any OS which has __ca_atexit can make its atexit safe. From glibc:
/* This is defined by newer gcc version unique for each module. */
extern void *__dso_handle __attribute__ ((__weak__));
/* Register FUNC to be executed by `exit'. */
int
atexit (void (*func) (void))
{
return __cxa_atexit ((void (*) (void *)) func, NULL,
&__dso_handle == NULL ? NULL : __dso_handle);
}
H.J.
>From [EMAIL PROTECTED] Sat Jun 1 22:43:59 2002
Date: Sat, 1 Jun 2002 19:43:28 -0700
From: "H . J . Lu" <[EMAIL PROTECTED]>
To: Jack Howarth <[EMAIL PROTECTED]>
Subject: Re: PATCH: Add --enable-__cxa_atexit
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sat, Jun 01, 2002
at 10:31:46PM -0400
On Sat, Jun 01, 2002 at 10:31:46PM -0400, Jack Howarth wrote:
> patch is totally unnecessary. I am still quite puzzled as to why
> the test case pases with or without -fuse-cxa-atexit and the
> a.out seems to have _use_cxa_atexit in it in both cases. This
> seems to suggest that gc
Re: Bug#148651: gcc 3.1-2 patch breaks binutils builds
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 __cxa_atexit is totally unneccessary with the newer glibc's. If we want to be difficult we can keep the patch but I think we are on our own in fixing the conflict between the gcc provided __cxa_atexit and binutils. The only reason to keep the patch is if we had an OS which didn't provide __cxa_atexit through glibc (i.e. one that used an alternative to glibc for its libc or was using glibc < 2.2). Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is g++-cxa-atexit.dpatch still needed
Here is another message from Jakub on the complete unnecessity
of debian using the patch...
Jack
---
>From [EMAIL PROTECTED] Sun Jun 2 01:15:44 2002
Date: Sun, 2 Jun 2002 07:15:44 +0200
From: Jakub 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: Mutt/1.2.5.1i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sat, Jun 01, 2002
at 07:21:20PM -0400
On Sat, Jun 01, 2002 at 07:21:20PM -0400, Jack Howarth wrote:
>I've gone back through the debian-gcc mailing list and found
> the origin of debian using --use-cxa-atexit in their gcc 3.x
> compiler builds. It is in the thread starting with...
>
> http://lists.debian.org/debian-gcc/2001/debian-gcc-200106/msg00126.html
>
> which basically says that they are using --use-cxa-atexit because
> global destructors are not run in the correct order. They got this
> from http://gcc.gnu.org/bugs.html#known which has...
>
> Global destructors are not run in the correct order.
>
> Global destructors should be run in the reverse order of their
> constructors completing. In most cases this is the same as the reverse
> order of constructors starting, but sometimes it is different, and that
> is important. You need to compile and link your programs
> with --use-cxa-atexit. We have not turned this switch on by default, as
> it requires a cxa aware runtime library (libc, glibc, or equivalent).
>
> Is this information still accurate for gcc 3.1? It would seem this is the
> only reason debian is using --use-cxa-atexit. Thanks for any clarifications.
It is not about being or not being accurate for gcc 3.1, it is about glibc
2001-02-26 or later having:
/* This is defined by newer gcc version unique for each module. */
extern void *__dso_handle __attribute__ ((__weak__));
/* Register FUNC to be executed by `exit'. */
int
atexit (void (*func) (void))
{
return __cxa_atexit ((void (*) (void *)) func, NULL,
&__dso_handle == NULL ? NULL : __dso_handle);
}
/* Hide the symbol so that no definition but the one locally in the
executable or DSO is used. */
#ifdef HAVE_DOT_HIDDEN
asm (".hidden\tatexit");
#endif
in /usr/lib/libc_nonshared.a (and exporting atexit from libc.so only
as compatibility symbol version, so nothing newly linked can use it).
Jakub
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148651: gcc 3.1-2 patch breaks binutils builds
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 any other os using a libc which provides __cxa_atexit does NOT need to utilize gcc to provide the same thing. HJ Lu is very clear in that he will not debug this issue with binutils because our usage of the __cxa_atexit from gcc instead of the copy provided by glibc via atexit is completely unneccessary. Gee, this is like beating my head against the wall here. Jack ps Just try rebuilding gcc 3.1.1 WITHOUT the patch and try the test case before you close this bug again...please. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc 3.1 vs XF4.2
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 following failure in /var/log/XFree86.0.log (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a No symbols found in this module Failed to load debug_xform.o (EE) Failed to load /usr/X11R6/lib/modules/extensions/libGLcore.a (II) UnloadModule: "GLcore" (EE) Failed to load module "GLcore" (loader failed, 270336000) When I do nm on the gcc 3.1 built libGLcore.a I see... debug_xform.o: compared to... debug_xform.o: t gcc2_compiled. for the gcc 2.95.4 built one. Anyone had any idea why the loader should be having such problems just because one of the object files used to create libGLcore.a has no symbols in it? Thanks for advice. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#154369: gcc 3.1.1 upstream
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 "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#154369: gcc 3.1.1 upstream
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 on the un-announced availibilty of the tarballs. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#154369: gcc 3.1.1 upstream
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.tar.bz2 with the release gcc-3.1.1.tar.bz2 and add a changelog entry. Nice. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re: Coexistence of gcc 3.2 and gcc 2.95
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 through a new libgcc-compat file on ppc. Other arches may have handled this issue in a slightly different manner. Basically on ppc, we make sure that these libgcc symbols that were improperly linked in by gcc < 3.1 are exported from glibc now but only for resolving and not for linking. The problem I see if that it is unclear how many arches for linux have had these changes made. The basic approach is to search all the binaries on a arch for libgcc symbols and when you have the list create a libgcc-compat that provides them for resolving but not for linking. Again without this addition to glibc for every arch debian has you will get massive breakage of existing binaries when you install a gcc > 3.1 built glibc. With it, the problem is a non-issue. As I said these changes have been made in glibc-2-2-branch for ppc, but I'm unclear how many other arches have have the changes migrated back from the glibc cvs trunk into glibc-2-2-branch. Jack ps You can see the overall scheme of this from... http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/libgcc-compat.c?rev=1.1.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc&only_with_tag=glibc-2-2-branch http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/Versions.diff?r1=1.2&r2=1.2.2.1&cvsroot=glibc&only_with_tag=glibc-2-2-branch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc 3.1.1 to 3.2 transition
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 have built under gcc 3.1.1 with 3.2 instead. I mention this because on ppc we have our openoffice.org package currently built under gcc 3.1.1 and it would be a cleaner transition if gcc 3.1.1 didn't instantly disappear when gcc 3.2 arrived in the pool. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.1.1 to 3.2 transition
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. Jack ps The grace period could be shorter, perhaps a week or even a few days, but I don't know if it is good to pull gcc 3.1.1 the moment 3.2 hits. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.1.1 to 3.2 transition
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 PROTECTED]
re: gcc 3.1 vs XF4.2
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' on all of the server extensions. So far it appears that libGLcore.a is the only problem one on ppc. Anyway, at least we have a workaround for that so when sid goes to gcc 3.2 we don't have to worry about XFree86 breakage on ppc now. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc 3.1.1 borked on voltaire
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 as well as Franz Sirls redhat based builds of gcc 3.1.1 release did. I see only 2 unexpected gcc failures here whereas voltaire gets 14. Worse I get 1 unexpected libjava failure here and voltaire gets 697. Wow. The only major difference I can think of is that I am using a locally built binutils 2.12.90.0.15 instead of whats in sid. Jack
Re: gcc 3.1.1 borked on voltaire
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 dir from gcc-3.1-3.1.1-0pre3 with the release gcc 3.1.1 tarball. That built fine last week but I want to make sure something isn't broken somewhere else in sid. I saw that last week the first time when I built it when groff was broken and caused two additional gcc testsuite failures before it was fixed in a -2 release. I also doubt binutils is directly at fault because using dpkg-deb -x I looked at the current binutils-2.12.90.0.14-2 test-summary.gz for the powerpc build and it shows no errors. So it doesn't make much sense for it to be binutils if that is the case. Lastly, looking through which arches passed and failed on their gcc-3.1 builds there is no pattern. Some failed with the .14-2 binutils installed and some passed with the .14-12 binutils installed. Anyway I'll let everyone know if my rebuild of my local gcc 3.1.1 release package is successful...if that is the case the problem should lie in the gcc-3.1-3.1.1-ds3 package and not elsewhere in sid. Jack
Re: gcc 3.1.1 borked on voltaire
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 able to build the gcc 3.1.1 release package I rolled from the release tarball and the debian patches/rules from gcc-3.1-3.1.1ds2-0pre3. So there doesn't appear to be a problem with debian sid in general as far as building gcc 3.1.1 is concerned. The resulting gcc 3.1.1 passes the testsuite as well as it did last week when I last built my custom package. This all suggests that some additional patches have been added to gcc-3.1-3.1.1ds3-1 since gcc-3.1-3.1.1ds2-0pre3 and that is causing the breakage. Jack
Re: How to get Debian to gcc-3.2 ....
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, old binaries will no longer have these symbols resolved for them if linked in. Currently we have a first generation patch checked into glibc-2-2-branch that addresses this on ppc. I believe ia64 only has this change in the main trunk and not backported into glibc-2-2-branch. Franz Sirl just completed a new version of the libgcc-compat patch for glibc-2-2-branch that hasn't made it in yet. The new version is coupled with a versioning fixup for gcc 3.2 which will keep the versioning the same for these libgcc symbols as it was under gcc 2.95.4. Unfortunately this change tickled a bug in binutils which HJ Lu has tentatively fixed and will be in the next binutils. If all goes well, on ppc at least, we should have the second generation libgcc-compat patch in glibc-2-2-branch, the versioning fixup in gcc 3.2 and all the fixes needed in the next binutils from HJ Lu. If you want to read up on these the related threads are... http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html ...original description of the problems with the .hidden symbols was found in this thread (in a convoluted discussion)... http://sources.redhat.com/ml/libc-alpha/2002-05/msg00067.html ...development of the 1st generation libgcc-compat patch on ppc is in this thread... http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html ...thread describe Franz's proposed fixup for the gcc 3.2 libgcc symbol versioning... http://sources.redhat.com/ml/binutils/2002-08/msg00173.html http://sources.redhat.com/ml/binutils/2002-08/msg00173.html http://sources.redhat.com/ml/binutils/2002-08/msg00175.html ...threads describing the binutils bug we tickled when moving to Franz's new revised libgcc-compat patches. For non-ppc arches the binutils stuff probably isn't of interest except that we found some real binutils bugs and got them fixed. However each debian arch will need to evaluate if they have to deal with the .hidden libgcc symbols by adding a libgcc-compat patch to glibc 2.2.5. Again so far glibc-2-2-branch only has this addressed (and not in the most updated form) for ppc. You could look in glibc main trunk and see if any other arches besides ia64 have added patches there as the form is essentially the same in 2.2.90 or 2.2.5. I am hoping we can have ppc go first to gcc 3.2 as we seem to been most aggressive in addressing these backward compatibility issues with libgcc symbols in glibc and should be able to rely on stock release gcc 3.2, release binutils and current glibc-2-2-branch cvs to get all the appropriate fixes in place. Jack ps I have been testing HJ Lu's new binutils fixes to 2.13.90.0.3 with Franz's most recent libgcc-compat patches applied to glibc 2.2.5-13 this weekend. I am able to build binutils and glibc with all passing make check fine. I also just built gcc 3.2 with Franz's proposed fixup for symbol versioning and the resulting test-summary looks fine as well. The gcc failures I get are... FAIL: gcc.dg/20020103-1.c scan-assembler-not LC FAIL: gcc.dg/20020118-1.c execution test FAIL: gcc.dg/format/ext-3.c bad %^# (test for warnings, line 215) FAIL: gcc.dg/format/ext-3.c (test for excess errors) ...unexpected only of course. The rest all look identical to what I get for gcc 3.1.1.
Re: provide symbols .hidden in gcc 3.1/3.2 when building glibc for ppc
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 Franz Sirl that will be going into glibc-2-2-branch. I will attempt to explain the rational of these changes so you understand their importance. Previous to gcc 3.1, gcc was exporting certain libgcc symbols, in error, for linking. Starting with gcc 3.1, these symbols are now .hidden. This means that if glibc is rebuilt with gcc >= 3.1, old binaries expecting to have these symbols resolved will fail. In order to address this, ia64 and ppc have provided libgcc-compat code in glibc to present these symbols for resolution at run-time but not linking. The current glibc-2-2-branch as of yesterday is insufficient to properly do this as Ulrich demands that such symbols not be exported for linking. Unfortunately the current patch there for this libgcc-compat code exports several of these symbols for linking. The attached patch stops this behavior limiting all the libgcc-compat symbols to just run-time resolution. In getting to the patch attached below we tickled several obscure binutils bugs with HJ Lu has been kind enough to fix and check into binutils cvs... http://sources.redhat.com/ml/binutils/2002-08/msg00175.html http://sources.redhat.com/ml/binutils/2002-08/msg00217.html http://sources.redhat.com/ml/binutils/2002-08/msg00221.html ..these patches are essential! Without them binutils will either have problems linking other programs (complaining in error about duplicate symbols with __divdi3) and creating a libgcc_s.so.1 in gcc 3.2 with a properly versioned __divdi3 symbol. As soon as Chris has released the next binutils package and either we use the attached patch or resample upstream from glibc-2-2-branch for the same patch, we will be set to start building with gcc 3.2 on ppc. It would be very good idea for us to get this resolved in 2.2.5-14, because current glibc-2-2-branch is exporting versioned symbols for __divdi3, and few others, with a GLIBC_2.0 versioning. This didn't happen in glibc prior to glibc 2.2.5-14 and it won't after we add the patch below (which makes those symbols run-time resolution only). It would be best if we don't muck around and build a bunch of stuff on ppc against current glibc-2-2-branch without the fix so as not to have to worry about those symbols. Let me know if you have any specific questions. The process is really simple.. 1) updated binutils from HJ or 2.13.90.0.3 with binutils-version-add and bfd-version-dso patches from this weekend and today. 2) add in glibc-libgcc-compat-ppc-8-2_2d from below or resample glibc-2-2-branch once Franz has it in. 3) add a depends to gcc 3.2 for the binutils (>=2.13.90.0.4) and for glibc (>=2.2.5-14). This step is essential to prevent the build machines from using gcc-3.2 to build against the wrong, i.e. old, binutils and/or libc accidentally. Thanks in advance for helping get this transition to gcc 3.2 correctly done on ppc. Jack -- #! /bin/sh -e # All lines beginning with `# DP:' are a description of the patch. # DP: Fix "/usr/include/bits/string2.h:419: # DP: warning: pointer of type `void *' used in arithmetic" if [ $# -ne 2 ]; then echo >&2 "`basename $0`: script expects -patch|-unpatch as argument" exit 1 fi case "$1" in -patch) patch -d "$2" -f --no-backup-if-mismatch -p0 < $0;; -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p0 < $0;; *) echo >&2 "`basename $0`: script expects -patch|-unpatch as argument" exit 1 esac exit 0 Index: sysdeps/powerpc/Makefile === RCS file: /cvs/glibc/libc/sysdeps/powerpc/Makefile,v retrieving revision 1.13.2.1 diff -u -p -r1.13.2.1 Makefile --- sysdeps/powerpc/Makefile21 May 2002 00:28:35 - 1.13.2.1 +++ sysdeps/powerpc/Makefile6 Aug 2002 08:20:52 - @@ -36,6 +36,10 @@ CFLAGS-gmon-start.o = -G0 endif ifeq (yes,$(build-shared)) # Compatibility +ifeq (yes,$(have-protected)) +CPPFLAGS-divdi3.c = -DHAVE_DOT_HIDDEN +CPPFLAGS-libgcc-compat.S = -DHAVE_DOT_HIDDEN +endif sysdep_routines += divdi3 libgcc-compat shared-only-routines += divdi3 libgcc-compat endif --- /dev/null Thu Oct 4 06:30:44 2001 +++ sysdeps/powerpc/libgcc-compat.S Tue Aug 6 01:15:38 2002 @@ -0,0 +1,148 @@ +/* pre-.hidden libgcc compatibility + Copyright (C) 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any l
Re: provide symbols .hidden in gcc 3.1/3.2 when building glibc for ppc
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 [EMAIL PROTECTED]:~$ ...no symbols in /lib/libc.so.6 for __divid3. for glibc 2.2.5-13 plus the glibc-2-2-branch version of the libgcc-compat code... [EMAIL PROTECTED]:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3 000266b0 g DF .text00c8 GLIBC_2.0 __divdi3 ...a __divdi3 exported for linking and run-time resolution. for a glibc 2.2.5-13 plus the proposed new libgcc-compat code (libgcc-compat.S instead of libgcc-compat.c)... [EMAIL PROTECTED]:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3 00026680 g DF .text00c8 (GLIBC_2.0) __divdi3 ...a __divdi3 NOT exported for linking BUT available for run-time resolution (note "()"s on the GLIBC_2.0 versioning). When the libgcc-compat code was discussed one demand Ulrich had was that all the libgcc-compat symbols must NOT be exported for linking! So we really want to avoid using current glibc-2-2-branch's sysdeps/powerpc/libgcc-compat.c but use the sysdeps/powerpc/libgcc-compat.S version instead. Otherwise we will start, temporarily until the correct fix goes into glibc, exporting __divdi3 for linking from libc.so.6 and then stop when the fix goes in. It is better to skip this potential breakage and adopt the correct fix. Again note that the correct fix in the upcoming patch, glibc-libgcc-compat-ppc-8-2_2d, from Franz Sirl avoids this issue by only making the __divdi3, and several other symbols, available for run-time resolution and NEVER for linking from inside glibc. The libgcc-compat.S version also is optimized which the old one isn't. Thanks in advance again. Jack
Bug#156662: gcc 3.2 will need Depends and Build-Depends on binutils and glibc versions for ppc
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, with luck and cooperation, the correct libgcc-compat.S patches will be in glibc 2.2.5-14. Without the Build-Depends on both these versions of binutils and glibc, a libgcc_s.so.1 will be created with missing versioning on the __divdi3 symbol on ppc. Also without the Depends on these versions of glibc and binutils, there can be problems building programs with gcc 3.2 on ppc due to bugs in binutils fixed in current binutils-cvs (and the next release, 2.13.90.0.4). Specifically, binutils will incorrectly report a symbol conflict on __divdi3 which doesn't exist when libc.so.6 is really only providing __divdi3 for run-time resolution and NOT for linking. This has been fixed in binutils-cvs. If we don't add the Build-Depends on binutils (>= 2.13.90.0.4) and glibc (>= 2.2.5-14) for gcc-3.2 , we won't be able to properly build gcc-3.2 against glibc 2.2.5-14 with the corrected libgcc-compat.S code. If we don't add the Depends on the above binutils and glibc versions, when gcc-3.2 becomes the default compiler for builds in debian sid on ppc, we risk the build machine getting out of sync and not building able to link programs. Thanks in advance for slating this for the final gcc-3.2 release (after Chris releases the new 2.13.90.0.4 binutils when it arrives and glibc adopts the needed libgcc-compat patch from bug report 155606 or resamples glibc upstream once Franz Sirl has that added there). Jack ps Franz Sirl should be submitting his patch to libc-alpha today.
Bug#156734: Build-Depends should accept gnat-3.2
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.
how to find symbols needed for libgcc-compat in glibc
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/3.2 rebuilds glibc. Both ia64, in glibc trunk, and ppc, in glibc trunk and glibc-2-2-branch, have this addressed. Franz and Jakub used scripts to search for the list of symbols that needed to go into the sysdeps//libgcc-compat.S code. Jakub describes this procedure as follows... - Basically, you take the list of libgcc.a (formerly) exported symbols and scan all binaries/libraries if they have undefined references to any of these symbols (as libc.so exports those on ia32/sparc and a few others only, they will not be exported on other arches from libc, thus are resolved to some unintentionally exported symbol in some other library which is going away after rebuild with 3.2). Jakub - Unfortunately, both Franz and Jakub have long ago thrown out the scripts they used to do this. It doesn't effect gcc 3.2 going into sid, because gcc 3.1.1. has exactly the same issue. However each arch has to address this before they switch to gcc 3.2 as their default compiler in sid. At the time this was looked at, Jakub only bothered with those arches which he deemed to have a large enough user base to bother with. It is unclear how many arches have been checked at this point other than ia64 and ppc; I am assuming i386 must be okay. Jack ps The threads in libc-alpha discussing this are... http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html http://sources.redhat.com/ml/libc-alpha/2002-05/msg00067.html Note that Franz has just re-written his libgcc-compat code to be in the same form as the ia64 one in gcc trunk. He will be checking the patch in for the new sysdeps/powerpc/libgcc-compat.S version today. On ppc we will have all the fixes in glibc-2-2-branch. The ia64 folks will have to backport from glibc trunk to 2.2.5 on their own as Jakub didn't think it was worth putting in the glibc-2-2-branch.
Re: how to find symbols needed for libgcc-compat in glibc
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 for > (sparc, alpha, etc) for the need for a libgcc-compat? > Or did you really just look at ia64 only? Also I > am assuming that intel is okay. IA-32/Alpha/Sparc (32-bit) should be just fine. Sparc (64-bit) is not common enough yet and 3.2 is good minimal compiler for anybody going 64-bits on SPARC. Don't know about s390/s390x, but no problems have been reported there AFAIK. Jakub -- In case anyone is interested... Jack
Bug#156662: gcc 3.2 will need Depends and Build-Depends on binutils and glibc versions for ppc
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 __divdi3. So building gcc 3.2 with gcc 2.95.4 against that presents no problem. However once glibc 2.2.5-14 is installed, with the corrected sysdeps/powerpc/ libgcc-compat.s code, there will definitely be a Build-Depends on binutils >= 2.13.90.0.4. The libc.so.6, built from the new libgcc-compat.S code, will have a dynamic symbol for __divdi3 (available for run-time resolution but NOT exported for linking). If you try to build gcc 3.2 with a binutils earlier than 2.13.90.0.4 against such a libc.so.6, you will end up with a flawed libgcc_s.so.1 with an unversioned __divdi3 symbol (which, if you look, is not the case with the current gcc 3.2 builds off of voltaire). With the new binutils 2.13.90.0.4 release or later the __divdi3 will be correctly versioned in libgcc_s.so.1 as GLIBC_2.0. So there definitely is at least a Build-Depends for binutils (>= 2.13.90.0.4) required for gcc 3.2 on ppc. Granted it isn't required today, but it will be the moment glibc 2.2.5-14 is installed. Note that this issue is exactly what Franz Sirl's rejected versioning fixup patch was all about... http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html Franz just didn't realize that the problem he was observing ,in building a proper libgcc_s.so.1 against his new corrected libgcc-compat.S code was due to a binutils bug. No changes in gcc 3.2 were required to fix it. Jack ps So gcc-3.2 needs a Build-Depends for binutils (>= 2.13.90.0.4) on ppc. While glibc 2.2.5-14 doesn't need a Build-Depends, it definitely will need a Depends on binutils (>= 2.13.90.0.4). This is because once you install a libc.so.6 with the new libgcc-compat.S code (that presents __divdi3 for run-time resolution but not exported for linking), you will tickle a binutils bug in 2.13.90.0.3 or earlier. This bug causes a bogus symbol conflict on the __divdi3 from libc.so.6... http://sources.redhat.com/ml/binutils/2002-08/msg00173.html http://sources.redhat.com/ml/binutils/2002-08/msg00175.html when attempting to build things against that glibc with gcc 2.95.4 Yes, this is all pretty nasty stuff which is why it was so hard to pinpoint and fix. In any case, I think we minimally need two changes... 1) gcc-3.2 Build-Depends on binutils (>= 2.13.90.0.4) on ppc 2) glibc 2.2.5-14 Depends on binutils (>= 2.13.90.0.4) on ppc The first prevents a flawed libgcc_s.so.1 from getting built for gcc 3.2. The second prevents bogus link errors against glibc 2.2.5-14 when building with gcc 2.95.4.
patched expect needed for gcc 3.2 builds
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 at the redhat bugzilla report... http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43310 and try the associated patch. I extracted this patch from the current rawhide tcltk package and rebuilt the debian expect package with it. Using this expect, the false failures disappeared and I now see exactly the same as Franz Sirl. The bug report for this and attached patch can be found at... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=156854 If anyone is seeing suspicious failures in their gcc-3.2 builds they may want to try such a patched expect to see if they are caused by the same problem. Jack
Re: GCC 3.2 transition
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 local copies that are resolvable at runtime. Currently ia64 and ppc has such code available. This is to prevent breaking old binaries when a gcc 3.2 built glibc is installed. 2) Using something like a gcc 2.95.4 built jdk javaplugin (written in c++) with a gcc 3.2 built mozilla won't currently work although workarounds are said to exist. Since Blackdown JDK 1.4 development is underway a gcc 3.2 build JDK won't be far off. Jack
new ppc libgcc-compat code in glibc-2-2-branch
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-2-branch. In both cases, the glibc builds fine and passes all of make check. On ppc we are set now for you to do your glibc-2-2-branch cvs pull for glibc-2.2.5-15. The only caveat at the moment is that you will need to wait for Chris Chimelis to push his new binutils 2.13.90.0.4-1 packages into sid. Also with this new pull from the cvs we will need a Depends added to glibc on binutils (>=2.13.90.0.4) for the ppc. This is because the new libgcc-compat code tickles some obscure binutils bugs when the libc.so.6 from this code is used to build programs against gcc < 3.1 (e.g. gcc 2.95.4). This bug is described here... http://sources.redhat.com/ml/binutils/2002-08/msg00173.html http://sources.redhat.com/ml/binutils/2002-08/msg00175.html http://sources.redhat.com/ml/binutils/2002-08/msg00180.html With the new binutils 2.13.90.0.4 and a current pull from glibc-2-2-branch, debian ppc will be in excellent shape to be one of the first, if not the first, platform to switch over to gcc 3.2 builds in debian ppc sid. Jack ps FYI, with the new expect 3.80-1 package that was added into debian sid (fixing a bug causing spurious false failures in the gcc testsuite), the current gcc 3.2 package in sid now passes the testsuite correctly (matching the results that are seen by Franz Sirl).
proposal for the gcc 3.2 transition
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 finished ppc in both branches of the glibc cvs. The ia64 arch has a version available in the glibc trunk that could be backported. Jakub also said alpha and sparc32 should be fine (not sure if that needs backported from the trunk though into glibc-2-2-branch). The rest will have to be handled by the arch maintainers here. After talking to Daniel Stone, I found out that the kde 3.0.3 introduction to sid was being delayed until the gcc 3.2 switchover has occurred. Since the scheme above will greatly delay kde 3.0.3 being added to sid, I would like to propose the following. Assuming each arch passes their gcc 3.2 testsuite and the most current binutils is mandated for use with gcc 3.2, we should be able to short-circuit the process as follows. 1) adjust the debian/control in glibc to build all arches at their current gcc < 3.1 regardless if gcc 3.2 is installed. 2) switch the gcc-default to gcc 3.2 3) as each arch can demonstrate that their libgcc-compat issues are resolved, their arch would be switched over in the glibc debian/control file to build glibc with gcc 3.2. This approach has the advantages of making the transition to gcc 3.2 go much faster while removing the need for each arch to immediately resolve their issues with libgcc-compat. All comments and suggestions are welcome. Jack
Bug#156662: gcc 3.2 will need Build-Depends on binutils
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 to binutils(>= 2.13.90.0.4). Currently only ppc absolutely needs this to build a working gcc-3.2 against debian glibc-cvs. However as other arches add libgcc-compat code of their own, they will also fall under this new Build-Depends requirement as well. So I wouldn't really make the Build-Depends arch specific. Thanks in advance. Jack
ppc mozilla patch for gcc 3.1.1/3.2 builds
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... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=158077&repeatmerged=yes ..so that should be one more thing we are set to build once the gcc 3.2 switchover in sid occurs. Jack
gcc-3.2 control
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 another rebuild of gcc-3.2 locally (this time using the release tarball) and the test-summary is holding fine so we definitely have killed the source of those false failures with the expect patch. Jack
Bug#160093: conflicting file ownership in libstdc++4 and gcc-3.2-nof
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 is also in package gcc-3.2-nof dpkg-deb: subprocess paste killed by signal (Broken pipe) I had to remove gcc-3.2-nof for libstdc++4 to install.
openoffice breakage on new gcc 3.2.1 snapshot
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 "LD_DEBUG=statistics openoffice". Jack
patch failures in gcc-3.2
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.dpatch -patch -d /home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/src patching file libstdc++-v3/src/Makefile.am Hunk #1 succeeded at 188 (offset 37 lines). patching file libstdc++-v3/src/Makefile.in Hunk #1 FAILED at 416. Hunk #2 FAILED at 480. Hunk #3 FAILED at 497. 3 out of 3 hunks FAILED -- saving rejects to file libstdc++-v3/src/Makefile.in.rej make: *** [stamps/02-patch-stamp-libstdc++-pic] Error 1 This is quite odd.. Jack
more on patch problem
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: install-info-am - install-exec-am: install-toolexeclibLTLIBRARIES install-exec: install-exec-am install-data-am: --- 416,422 installcheck: installcheck-am install-info-am: install-info: install-info-am + install-exec-am: install-toolexeclibLTLIBRARIES install-exec-local install-exec: install-exec-am install-data-am: *** *** 480,486 clean-libtool maintainer-clean-libtool tags mostlyclean-tags \ distclean-tags clean-tags maintainer-clean-tags distdir info-am info \ dvi-am dvi check check-am installcheck-am installcheck install-info-am \ - install-info install-exec-am install-exec install-data-am install-data \ install-am install uninstall-am uninstall all-redirect all-am all \ installdirs mostlyclean-generic distclean-generic clean-generic \ maintainer-clean-generic clean mostlyclean distclean maintainer-clean --- 480,486 clean-libtool maintainer-clean-libtool tags mostlyclean-tags \ distclean-tags clean-tags maintainer-clean-tags distdir info-am info \ dvi-am dvi check check-am installcheck-am installcheck install-info-am \ + install-info install-exec-local install-exec-am install-exec install-data-am install-data \ install-am install uninstall-am uninstall all-redirect all-am all \ installdirs mostlyclean-generic distclean-generic clean-generic \ maintainer-clean-generic clean mostlyclean distclean maintainer-clean *** *** 497,502 $(LTCXXCOMPILE) -D_GLIBCPP_CONCEPT_CHECKS -fimplicit-templates -c $< concept-inst.o: concept-inst.cc $(CXXCOMPILE) -D_GLIBCPP_CONCEPT_CHECKS -fimplicit-templates -c $< # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. --- 497,506 $(LTCXXCOMPILE) -D_GLIBCPP_CONCEPT_CHECKS -fimplicit-templates -c $< concept-inst.o: concept-inst.cc $(CXXCOMPILE) -D_GLIBCPP_CONCEPT_CHECKS -fimplicit-templates -c $< + + install-exec-local: + $(AR) cru libstdc++_pic.a .libs/*.o ../libsupc++/*.o + $(INSTALL_DATA) libstdc++_pic.a $(glibcpp_toolexeclibdir) # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. It looks like these sections are now moved down to around line 453 in the first part of the patch and rearranged enough to be unrecognizable in both. Any ideas? Jack
Bug#161438: gcc-3.2 needs automake-1.4 Build-Depends
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 automake calls to allow multiple versions of automake to coexist during the build. Otherwise we will have to Build-Conflict the other automake versions. Jack
build failure
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/gcc-3.2-3.2.1ds1/build/gcc/ -nostdinc++ -L/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/l -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g-c /home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/src/libstdc++-v3/src/wstring-inst.cc /home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/xgcc -shared-libgcc -B/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/ -nostdinc++ -L/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/libstdc++-v3/src -L/home/howarth/debian-gcc32/ /home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/xgcc -shared-libgcc -B/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/ -nostdinc++ -L/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/libstdc++-v3/src -L/home/howarth/debian-gcc32/ /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/gcc-3.2-3.2.1ds1/build/gcc/ -nostdinc++ -L/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/l -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g-c codecvt_members.cc /home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/xgcc -shared-libgcc -B/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/gcc/ -nostdinc++ -L/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/libstdc++-v3/src -L/home/howarth/debian-gcc32/ codecvt_members.cc: In member function `virtual std::codecvt_base::result std::codecvt::do_out(mbstate_t&, const wchar_t*, const wchar_t*, const wchar_t*&, char*, char*, char*&) const': codecvt_members.cc:53: `_M_c_locale_codecvt' undeclared (first use this function) codecvt_members.cc:53: (Each undeclared identifier is reported only once for each function it appears in.) make[6]: *** [codecvt_members.lo] Error 1 make[6]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/libstdc++-v3/src' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/libstdc++-v3' make[4]: *** [all-recursive-am] Error 2 make[4]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/powerpc-linux/libstdc++-v3' make[3]: *** [all-target-libstdc++-v3] Error 2 make[3]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build' make[2]: *** [bootstrap-lean] Error 2 make[2]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build' /usr/bin/make -C /home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/fastjar make[2]: Entering directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/fastjar' make[2]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1/build/fastjar' s=`cat status`; rm -f status; test $s -eq 0 make[1]: *** [stamps/05-build-stamp] Error 1 make[1]: Leaving directory `/home/howarth/debian-gcc32/gcc-3.2-3.2.1ds1' make: *** [stamps/05-build-stamp] Error 2 Any idea what this is about? Jack
findsyms results?
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 with Ulrich. Even if it only confirms that the existing libgcc-compat situation if sufficient for an arch it would be polite since we are likely sampling a much larger codebase than they were when the libgcc-compat code went it. Thanks in advance. With glibc 2.3 about to release any moment we might want to give them a heads up on any holes in the libgcc-compat code. Jack ps By information, I mean just the list of hidden libgcc symbols that findsyms found and collated in the final.list file it creates.
binutils requirements for gcc 3.2 rebuild
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 ready. On ppc, a fix was introduced at binutils 2.13.90.0.5 which changed how *r_offset is set so it is no longer a non-zero value. This is critical to prelink being able to unprelink a prelinked binary back to an identical copy of the unprelinked original. The binutils behavior pre-2.13.90.0.5 was such that unpredictable non-zero values were placed in *r_offset making it impossible to predict the original value again. This is solved in 2.13.90.0.5 by adopting a zero value for *r_offset like all the other arches do. The need for binutils 2.13.90.0.6 arises from a glitch I ran across where binutils would produces shared libraries that were not properly -zcombreloc. HJ Lu and Alan Modra added two fixes... the correct ppc-specific one and a general safety net fix to prevent any arch from having this bug in the future. So while the problem has only been demonstrated on ppc, it may impact other arches as well. Thanks in advance for dealing with this. Jack
bison 1.50-1
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 bison 1.35-3 eliminates this problem in the build. Jack - /bin/sh ../../ld/../ylwrap "bison -y" ../../ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h -- -d /home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld/../../ld/ldgram.y:629.12-632.35: type clash (`' `name') on default action /home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld/../../ld/ldgram.y:831.8-847.11: type clash (`' `name') on default action make[3]: *** [ldgram.c] Error 1 make[3]: Leaving directory `/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single/ld' make: *** [all-ld] Error 2 bogus:/home/howarth/debian-binutils/binutils-2.13.90.0.8/build-tree/binutils-2.13.90.0.8/builddir-single# --~v
Re: bison 1.50-1
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
Re: how to find symbols needed for libgcc-compat in glibc
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 arches have even had glibc 2.3.1 built on them. Jack
gcc 3.2.1 in sid?
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 only worrisome arches are hppa (glibc 2.3.1 is still broken there), mips and m68k (those two will need libgcc-compat code added for glibc 2.3.1). Jack
gcc 3.2.1 and bison 1.50
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
new libstdc++ failures
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 for some of those tests. We might want to check the ppc build machines for those. Jack
gcc 3.2 breakage?
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 to become very unhappy. Jack
gcc 3.2.1 switchover
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
Bug#176081: libgcj.so.3.0.0 has non-PIC static code linked in
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 gcc 3.2.2 ppc rpms. This was determined with... objdump --all-headers /lib/libc-2.3.1.so | grep TEXTREL TEXTREL 0x0
Bug#176081: libgcj.so.3.0.0 has non-PIC static code linked in
Typo...the test was... objdump --all-headers /usr/lib/libgcj.so.3.0.0 | grep TEXTREL TEXTREL 0x0 ...of course. Jack
elfutils vs debian gcc
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 prevent header collisions)... if gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../lib -I.. -Wall -Werror -g -O2 -MT elf_version.o -MD -MP -MF ".deps/elf_version.Tpo" \ -c -o elf_version.o `test -f 'elf_version.c' || echo './'`elf_version.c; \ then mv ".deps/elf_version.Tpo" ".deps/elf_version.Po"; \ else rm -f ".deps/elf_version.Tpo"; exit 1; \ fi cc1: warnings being treated as errors In file included from elf_version.c:19: libelfP.h:357: warning: `visibility' attribute directive ignored libelfP.h:358: warning: `visibility' attribute directive ignored libelfP.h:363: warning: `visibility' attribute directive ignored These are lines of the form... extern const xfct_t __elf_xfctstom[EV_NUM - 1][EV_NUM - 1][ELFCLASSNUM - 1][ELF_T_NUM] attribute_hidden; extern const xfct_t __elf_xfctstof[EV_NUM - 1][EV_NUM - 1][ELFCLASSNUM - 1][ELF_T_NUM] attribute_hidden; in libelfP.h. This compiles fine on ppclinux from rawhide using a gcc 3.2.2 snapshot. Just curious why this is happening. Jack
RE: elfutils vs debian gcc
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 with stock gcc 3.2.2. Jack
Bug#176081: libgcj.so.3.0.0 has non-PIC static code linked in
This should be fixed upstream now... http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02409.html
TLS. nptl and gcc/glibc/binutils
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 now that they are focused on nptl and paying less attention to the old linuxthreads code. Do we plan to add backports of the TLS changes to gcc 3.2.3 as redhat has done or should we stick with gcc 3.3 if we want to build glibc with TLS support? Just curious what the plan is on this transition. Jack
possible dejagnu problems???
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 for errors, line 5) FAIL: g++.dg/parse/crash2.C (test for excess errors) as well as an extra gcc test... FAIL: gcc.c-torture/execute/991221-1.c compilation, -O0 You may want to repeat this build with the older dejagnu 1.4.2-1.1 debian package installed rather than the current 1.4.3-0.1 in sid. I say that because I noticed in doing a local build of the new binutils 2.14.90.0.1 on debian ppc sid, that I was getting 4 binutils tests UNTESTED which didn't happen on YDL ppclinux. After regressing dejagnu down to 1.4.2-1.1, those UNTESTED binutils tests became normal passes again. Apparently HJ and other using redhat are still on 1.4.2 and haven't run into these oddities yet. Jack ps I have reported this already against debian dejagnu.
re: planning binutils NMU (testing wanted ...)
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 === binutils Summary === # of expected passes31 # of expected failures 1 This difference of 4 untested test cases is due to you having dejagnu 1.4.3 installed and my having downgraded to 1.4.2. The other divergence is... your build... === ld Summary === # of expected passes171 # of unexpected failures6 # of unexpected successes 4 # of expected failures 8 and my build... === ld Summary === # of expected passes177 # of unexpected successes 4 # of expected failures 8 These 6 unexpected failures strongly suggest that the ppc sid build machine you used had been prelinked. Currently we are waiting for Jakub to debug why prelinking causes these 6 unexpected failures. Since I have unprelinked my machine they aren't triggered. In any case, they are non-fatal for us. Jack
no anonymous cvs access for debian-gcc
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]:/cvs/debian-gcc co gcc-3.3 ...which fails with... ? gcc-3.3/debian cvs server: warning: cannot write to history file /cvs/debian-gcc/CVSROOT/history: Permission denied cvs server: Updating gcc-3.3 cvs server: failed to create lock directory for `/cvs/debian-gcc/gcc-3.3' (/cvs/debian-gcc/gcc-3.3/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/cvs/debian-gcc/gcc-3.3' cvs [server aborted]: read lock failed - giving up Thanks in advance for any information. Jack
Bug#193953: /usr/lib/libgcj.so.2 improperly linked
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 => /lib/libgcc_s.so.1 (0x6ffd4000) libc.so.6 => /lib/libc.so.6 (0x0fe8) /lib/ld.so.1 => /lib/ld.so.1 (0x0800) undefined symbol: GC_least_plausible_heap_addr (/usr/lib/libgcj.so.2) undefined symbol: GC_greatest_plausible_heap_addr (/usr/lib/libgcj.so.2) undefined symbol: GC_arrays (/usr/lib/libgcj.so.2) undefined symbol: GC_allocate_lock (/usr/lib/libgcj.so.2) undefined symbol: GC_java_finalization (/usr/lib/libgcj.so.2) undefined symbol: GC_n_mark_procs (/usr/lib/libgcj.so.2) undefined symbol: GC_n_kinds(/usr/lib/libgcj.so.2) undefined symbol: GC_obj_kinds (/usr/lib/libgcj.so.2) undefined symbol: GC_find_start (/usr/lib/libgcj.so.2) undefined symbol: deflate (/usr/lib/libgcj.so.2) undefined symbol: GC_disable(/usr/lib/libgcj.so.2) undefined symbol: GC_lock (/usr/lib/libgcj.so.2) undefined symbol: GC_generic_malloc (/usr/lib/libgcj.so.2) undefined symbol: inflate (/usr/lib/libgcj.so.2) undefined symbol: deflateSetDictionary (/usr/lib/libgcj.so.2) undefined symbol: GC_gcollect (/usr/lib/libgcj.so.2) undefined symbol: GC_signal_mark_stack_overflow (/usr/lib/libgcj.so.2) undefined symbol: GC_add_to_black_list_normal (/usr/lib/libgcj.so.2) undefined symbol: GC_pthread_create (/usr/lib/libgcj.so.2) undefined symbol: GC_get_heap_size (/usr/lib/libgcj.so.2) undefined symbol: GC_init_gcj_malloc(/usr/lib/libgcj.so.2) undefined symbol: GC_get_free_bytes (/usr/lib/libgcj.so.2) undefined symbol: GC_expand_hp (/usr/lib/libgcj.so.2) undefined symbol: deflateInit2_ (/usr/lib/libgcj.so.2) undefined symbol: inflateReset (/usr/lib/libgcj.so.2) undefined symbol: deflateReset (/usr/lib/libgcj.so.2) undefined symbol: GC_enable (/usr/lib/libgcj.so.2) undefined symbol: GC_malloc_atomic (/usr/lib/libgcj.so.2) undefined symbol: GC_malloc (/usr/lib/libgcj.so.2) undefined symbol: GC_gcj_malloc (/usr/lib/libgcj.so.2) undefined symbol: GC_find_header(/usr/lib/libgcj.so.2) undefined symbol: GC_dlopen (/usr/lib/libgcj.so.2) undefined symbol: GC_invoke_finalizers (/usr/lib/libgcj.so.2) undefined symbol: GC_set_max_heap_size (/usr/lib/libgcj.so.2) undefined symbol: GC_register_finalizer_no_order(/usr/lib/libgcj.so.2) undefined symbol: GC_finalize_all (/usr/lib/libgcj.so.2) undefined symbol: deflateParams (/usr/lib/libgcj.so.2) undefined symbol: GC_generic_malloc_inner (/usr/lib/libgcj.so.2) undefined symbol: inflateSetDictionary (/usr/lib/libgcj.so.2) undefined symbol: inflateEnd(/usr/lib/libgcj.so.2) undefined symbol: inflateInit2_ (/usr/lib/libgcj.so.2) undefined symbol: deflateEnd(/usr/lib/libgcj.so.2) This suggests that the library needs to be linked with "-lz -lgcjgc" to eliminate this problem. Also, the shared lib, /usr/lib/libgcjgc.so.1, shows undefined non-weak symbols as well... ldd -r /usr/lib/libgcjgc.so.1 libpthread.so.0 => /lib/libpthread.so.0 (0x0fbc) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x6ffd4000) libc.so.6 => /lib/libc.so.6 (0x0fe8) /lib/ld.so.1 => /lib/ld.so.1 (0x0800) undefined symbol: dlopen which indicates it needs linked with "-ldl".
Bug#193953: /usr/lib/libgcj.so.2 improperly linked
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 (0x0f08) libc.so.6 => /lib/libc.so.6 (0x0fe8) /lib/ld.so.1 => /lib/ld.so.1 (0x0800)
Bug#196090: gcc-3.3: miscompiles XDM-AUTHORIZATION-1 key generation and/or validation in XFree86 at -O2
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 from RedHat that only we tickled the gcc bug. However I did find out that the gcc 3.3 that RedHat uses is not a patched version of the gcc 3.3 branch but rather a special rh branch of gcc-3.3. One wonders if they would see the problem if they used the stock gcc-3.3 branch instead and if there are any fixes trapped in the gcc-3.3 rh branch that haven't been put into the main gcc-3.3 branch. Jack
gcc 2.95.4 VERY broken on ppc
Package: gcc-2.95 Version: 2.95.4-0.010407 Hello guys. The move of gcc 2.95.4-0.010407 has majorly broken woody on ppc. For example update_menus now has an undefined symbol for __throw and can't run. Also kconqueror from kde 2.1.1 has undefined symbols to __throw and malfunctions. Also libdb2 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 fails as follows... cc -o db_archive db_archive.o err.o getlong.o -L. -ldb2 db_archive.o: In function `main': /home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix/../dist/../db_archive/db_archive.c:94: undefined reference to `db_appexit' /home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix/../dist/../db_archive/db_archive.c:94: relocation truncated to fit: R_PPC_REL24 db_appexit /home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix/../dist/../db_archive/db_archive.c:103: undefined reference to `db_appexit' /home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix/../dist/../db_archive/db_archive.c:103: relocation truncated to fit: R_PPC_REL24 db_appexit db_archive.o: In function `db_init': /home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix/../dist/../db_archive/db_archive.c:130: undefined reference to `db_appinit' /home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix/../dist/../db_archive/db_archive.c:130: relocation truncated to fit: R_PPC_REL24 db_appinit collect2: ld returned 1 exit status make[1]: *** [db_archive] Error 1 make[1]: Leaving directory `/home/howarth/debian2/db2-2.7.7/build-tree/db-2.7.7/build_unix' make: *** [stampdir/build] Error 2 Build command 'cd db2-2.7.7 && dpkg-buildpackage -b -uc' failed. E: Child process failed not good. -- Jack W. Howarth, Ph.D. 231 Bethesda Avenue NMR Facility Director Cincinnati, Ohio 45267-0524 Dept. of Molecular Genetics phone: (513) 558-4420 Univ. of Cincinnati College of Medicinefax: (513) 558-8474
gcc 2.95.4 workaround
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' must be public");
+#if 0
+ /* Due to a bug this error was never active, enabling it now would break
+ glibc. */
else if (TREE_ASM_WRITTEN (decl))
error_with_decl (decl, "weak declaration of `%s' must precede
definition");+ /* This would be a new error, but it would break glibc too :-(.
*/
+ else if (TREE_USED (decl))
+error_with_decl (decl, "weak declaration of `%s' must precede its uses");
+#endif
else if (SUPPORTS_WEAK)
DECL_WEAK (decl) = 1;
#ifdef HANDLE_PRAGMA_WEAK
that disables the errors which had not triggered before. I don't believe
Franz has seen any bad side-effects of this change.
Jack
missing tarball
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
Re: new gcc-2.95 packages
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
combreloc
Hello,
In case you aren't aware a rather significant
change was made recently to binutils. The -z combreloc
support in binutils has been enabled on almost all
arches as of binutils 2.11.92.0.5-3. This coupled with
the recent rebuild of glibc 2.2.4-4 has enabled combreloc
in glibc. Combreloc sorts the cached relocations to speed
up their access and can dramatically reduce the load time
spent in the dynamic linker particularly for large programs
with lots of relocations such as qt/kde.
For example on Debian ppc sid we find that with combreloc
disabled in glibc that the linker statistics for the t1 tutorial
program in qt 2.3.1 shows the following...
01338:
01338: runtime linker statistics:
01338:total startup time in dynamic loader: 17486340 clock cycles
01338: time needed for relocation: 13139203 clock cycles (75.1%)
01338: number of relocations: 32391
01338:number of relocations from cache: 0
01338: time needed to load objects: 567645 clock cycles (3.2%)
which is reduced by about 90% when combreloc is enabled in glibc (and
the binary for t1 and all support libs have been built against the
-z combreloc enabled binutils)
14355:
14355: runtime linker statistics:
14355:total startup time in dynamic loader: 1978861 clock cycles
14355: time needed for relocation: 1904007 clock cycles (96.2%)
14355: number of relocations: 9647
14355:number of relocations from cache: 22744
14355: time needed to load objects: 65247 clock cycles (3.2%)
Experimental prelinking of the t1 binary in addition can take the time
spent in the dynamic loader down to 1% of the original value...
14356:
14356: runtime linker statistics:
14356:total startup time in dynamic loader: 135185 clock cycles
14356: time needed for relocation: 57254 clock cycles (42.3%)
14356: number of relocations: 0
14356:number of relocations from cache: 2555
14356: time needed to load objects: 67923 clock cycles (50.2%)
So with the current binutils and glibc in sid we can obtain a 90% reduction
in the load time for programs using the existing tools in Debian sid. In
the future an even better reduction will be obtainable with prelinking.
I am bringing this to your attention since every maintainer should
be aware that if he chooses to do a minor version bump of his packages
they will be rebuilt against the latest devtools (not a bad thing) and
a -z combreloc enabled binutils. This will provide the immediate
advantage of combreloc support and a reduced load time as well as making
the binary prelink ready for a future addition of prelinking support
to glibc and sid. I just wanted everyone to be aware of what was available
here with the new binutils in case they weren't planning a new release
before Woody is shipped but would be interested in obtaining this
improved load time from combreloc.
Jack Howarth
combreloc
Hello,
In case you aren't aware a rather significant
change was made recently to binutils. The -z combreloc
support in binutils has been enabled on almost all
arches as of binutils 2.11.92.0.5-3. This coupled with
the recent rebuild of glibc 2.2.4-4 has enabled combreloc
in glibc. Combreloc sorts the cached relocations to speed
up their access and can dramatically reduce the load time
spent in the dynamic linker particularly for large programs
with lots of relocations such as qt/kde.
For example on Debian ppc sid we find that with combreloc
disabled in glibc that the linker statistics for the t1 tutorial
program in qt 2.3.1 shows the following...
01338:
01338: runtime linker statistics:
01338:total startup time in dynamic loader: 17486340 clock cycles
01338: time needed for relocation: 13139203 clock cycles (75.1%)
01338: number of relocations: 32391
01338:number of relocations from cache: 0
01338: time needed to load objects: 567645 clock cycles (3.2%)
which is reduced by about 90% when combreloc is enabled in glibc (and
the binary for t1 and all support libs have been built against the
-z combreloc enabled binutils)
14355:
14355: runtime linker statistics:
14355:total startup time in dynamic loader: 1978861 clock cycles
14355: time needed for relocation: 1904007 clock cycles (96.2%)
14355: number of relocations: 9647
14355:number of relocations from cache: 22744
14355: time needed to load objects: 65247 clock cycles (3.2%)
Experimental prelinking of the t1 binary in addition can take the time
spent in the dynamic loader down to 1% of the original value...
14356:
14356: runtime linker statistics:
14356:total startup time in dynamic loader: 135185 clock cycles
14356: time needed for relocation: 57254 clock cycles (42.3%)
14356: number of relocations: 0
14356:number of relocations from cache: 2555
14356: time needed to load objects: 67923 clock cycles (50.2%)
So with the current binutils and glibc in sid we can obtain a 90% reduction
in the load time for programs using the existing tools in Debian sid. In
the future an even better reduction will be obtainable with prelinking.
I am bringing this to your attention since every maintainer should
be aware that if he chooses to do a minor version bump of his packages
they will be rebuilt against the latest devtools (not a bad thing) and
a -z combreloc enabled binutils. This will provide the immediate
advantage of combreloc support and a reduced load time as well as making
the binary prelink ready for a future addition of prelinking support
to glibc and sid. I just wanted everyone to be aware of what was available
here with the new binutils in case they weren't planning a new release
before Woody is shipped but would be interested in obtaining this
improved load time from combreloc.
Jack Howarth
