enabling link time optimizations in package builds
Link time optimizations are an optimization that helps with a single digit percent number optimizing both for smaller size, and better speed. These optimizations are available for some time now in GCC. Link time optimizations are also at least turned on in other distros like Fedora, OpenSuse (two years) and Ubuntu (one year). Details at https://wiki.debian.org/ToolChain/LTO The proposal is to turn on LTO by default on most 64bit release architectures. Not proposing to do this on 32bit architectures because of the limited address space at link time, and up to now nobody tested LTO on 32bit archs. In test rebuilds, there were 373 packages (dd-list in the wiki page) found not to build with link time optimizations for various reasons. These range from easily fixable issues in symbols files to some upstream issues. The idea is to fix as many of these as possible, and then change the packaging for the others to just turn off LTO in the package build. To explicitly turn on LTO for a package build: export DEB_BUILD_MAINT_OPTIONS=optimize=+lto to explicitly disable LTO: export DEB_BUILD_MAINT_OPTIONS=optimize=-lto The idea is to file wishlist bug reports for those 373 packages and then see how far we get, and if it's feasible to already turn on LTO for bookworm. If not, it should be turned on by default for the following release. Matthias
Re: Porter roll call for Debian Bullseye
On 12/1/20 5:02 AM, YunQiang Su wrote: > I am sorry for the later response. >Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Bullseye release (est. end > of 2024): > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
GCC and binutils plans for bullseye
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream branch, and binutils based on a binutils package taken from the 2.35 branch. I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available (upstream targets mid July). binutils will be updated before making the GCC switch. The GCC 10 switch involves some minor library transitions for D, gccgo, M2, which should be no-brainers. The gnat transition will be handled separately by the debian Ada maintainers. binutils should be pretty stable until the bullseye release, not planning an update to 2.36. GCC 10 should be updated to 10.3, or close to 10.3 (the release date is not yet known, could be Feb 2021). I'd like to get rid off GCC 8 and GCC 9 for the bullseye release. Matthias
Same procedure as every year: GCC defaults change (GCC 9)
GCC 9 was released earlier this year, it is now available in Debian testing/unstable. I am planning to do the defaults change in mid August, around the time of the expected first GCC 9 point release (9.2.0). There are only soname changes for rather unused shared libraries (libgo) involved, and the gnat defaults change will be handled separately by the Debian Ada maintainers. The fortran module changes look ok according to Alastair McKinstry. The gcc-9 package still ftbfs on kfreebsd-*. We still have local patches for at least the various mips, kfreebsd and hurd targets. Please forward these upstream and make sure that these are applied upstream. powerpcspe support is removed upstream. I will keep pointing the default to GCC 8 for this target. Matthias
gcc-8 and gcc-9 builds using pgo and lto optimization
The recent gcc-8 and gcc-9 uploads to unstable are now built using pgo and lto optimization. Not on all architectures, see debian/rules.defs. On the plus side the compilers are 7-10% faster, however the build time of the compiler is much longer, adding 10-20 hours. If people feel that this isn't worth the extra build time, please file an issue for the package to disable those optimizations. Matthias
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 13.04.19 17:01, Joerg Jaspert wrote: > On 15371 March 1977, Aurelien Jarno wrote: > >>> How is the move to debian-ports supposed to happen? I won't have the >>> time to do anything about it within the 2 weeks. > >> The process to inject all packages to debian-ports is to get all the >> deb, udeb and buildinfo files from the archives (main and debug) and >> associate them with the .changes files that are hosted on coccia. We'll >> also need to fetch all the associated GPG keys used to sign the changes >> files. Then we can inject that in the debian-ports archive. > >> It would be nice to have a bit more than 2 weeks to do all of that. > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this > is on the table already, it doesn't make much difference if its 2 or 8. > Just something thats clear defined and not some random, non-clear > "sometime in the future" point. well, please go back in history to see the same short notice for the hppa removal, and then do the exercise how long it took to integrate that architecture on debian-ports. >
Bug#921512: GCC 9 ftbfs on alpha
Package: src:gcc-9 Severity: important At least in a cross build according to https://launchpadlibrarian.net/409942596/buildlog_ubuntu-disco-amd64.gcc-9-cross-ports_0ubuntu1_BUILDING.txt.gz The native alpha build wasn't yet started. dh_movefiles -plibgfortran-9-dev-alpha-cross usr/lib/gcc-cross/alpha-linux-gnu/9/include/ISO_Fortran_binding.h dh_movefiles: debian/tmp/usr/lib/gcc-cross/alpha-linux-gnu/9/include/ISO_Fortran_binding.h not found (supposed to put it in libgfortran-9-dev-alpha-cross) tar: /<>/gcc/debian/movelist: Cannot stat: No such file or directory tar: Error is not recoverable: exiting now tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors
Bug#920161: openjdk-11 ftbfs on alpha with
Package: src:openjdk-11, src:binutils Severity: important openjdk-11 ftbfs on alpha, linking libjvm. full build log at https://buildd.debian.org/status/fetch.php?pkg=openjdk-11=alpha=11.0.2%2B7-1=1547859652=0 [...] Linking libjvm.so ( /bin/rm -f /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_link.log && /usr/bin/alpha-linux-gnu-g++-8 -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,noexec stack -Wl,-O1 -Wl,-z,relro -Xlinker -z -Xlinker relro -Xlinker -Bsymbolic-functions -shared -Xlinker -z -Xlinker relro -Xlinker -Bsymbolic-functions -Wl,-version-script=/<>/openjdk-11-11.0.2+ 7/build/hotspot/variant-zero/libjvm/gtest/mapfile -Wl,-soname=libjvm.so -o /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/gtest/libjvm.so @/<>/openjdk-11-11.0.2+7/build/h otspot/variant-zero/libjvm/gtest/objs/_BUILD_GTEST_LIBJVM_objectfilenames.txt -lm -ldl -lpthread -lffi_pic > >(/usr/bin/tee -a /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/gtest/ objs/BUILD_GTEST_LIBJVM_link.log) 2> >(/usr/bin/tee -a /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_link.log >&2) || ( exitcode=$? && /bin/cp /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_link.log /<>/openjdk-11-11.0.2+7/build/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_ objs_BUILD_GTEST_LIBJVM_link.log && /bin/cp /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_link.cmdline /<>/openjdk-11-11.0.2+7/build/make-s upport/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.cmdline && exit $exitcode ) ) ; /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4633:(.text+0x1050): relocation truncated to fit: GPR EL16 against symbol `AllowUserSignalHandlers' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/globals.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4713:(.text+0x1268): relocation truncated to fit: GPR EL16 against symbol `CheckJNICalls' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/globals.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4715:(.text+0x1284): relocation truncated to fit: GPREL16 against symbol `PrintJNIResolving' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/globals.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4720:(.text+0x12a8): relocation truncated to fit: GPREL16 against symbol `AllowUserSignalHandlers' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/globals.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4721:(.text+0x12b8): relocation truncated to fit: GPREL16 against symbol `PrintJNIResolving' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/globals.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4713:(.text+0x1310): relocation truncated to fit: GPREL16 against symbol `CheckJNICalls' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/globals.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4716:(.text+0x1350): relocation truncated to fit: GPREL16 against symbol `tty' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/ostream.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/os/linux/os_linux.cpp:4722:(.text+0x1380): relocation truncated to fit: GPREL16 against symbol `tty' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/ostream.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/share/runtime/os.hpp:244:(.text+0x1de8): relocation truncated to fit: GPREL16 against symbol `os::_processor_count' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os.o /usr/bin/ld: /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/os_linux.o:./make/hotspot/./src/hotspot/share/runtime/arguments.hpp:607:(.text+0x1fac): relocation truncated to fit: GPREL16 against symbol `Arguments::_sun_boot_library_path' defined in .sbss section in /<>/openjdk-11-11.0.2+7/build/hotspot/variant-zero/libjvm/objs/arguments.o /usr/bin/ld:
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 07.07.18 17:24, YunQiang Su wrote: > Niels Thykier 于2018年6月28日周四 上午4:06写道： >> List of concerns for architectures >> == >> >> The following is a summary from the current architecture qualification >> table. >> >> * Concern for ppc64el and s390x: we are dependent on sponsors for >>hardware. >>(Raised by DSA; carried over from stretch) >> >> * Concern for armel and armhf: only secondary upstream support in GCC >>(Raised by the GCC maintainer; carried over from stretch) I don't think anybody objected about the status for armhf. I didn't follow armel issues too closely. >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) >> > > This is a misunderstanding as MIPS company had some unrest in recent half > year. > Currently we are stable now, and the shape of gcc upstream is also good. This is an optimistic view. While currently not having any RC issues, we still see mips* specific issues popping up more often than on other release architectures. According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux* target listed as either primary or secondary platform. As far as I understand the mips porters argue that this is covered by mipsisa64-elf, a bare metal target. I don't agree with this view, because - testing is missing on mips*-linux-* targets. If you look at the gcc-testresults ML, you see only test reports submitted for the Debian GCC packages, nothing else. - A bare metal target is usually only built/used for C and C++. I doubt that other frontends are tested. - Configurations like libgcjit are not tested/used upstream, and not addressed. See #798710. The Debian bug tracking for the MIPS port could be better, I usually need some pings to the MIPS porters to get things forwarded or addressed. To me it looks sometimes that Debian is used for testing by upstream, and for that the mips architectures don't need to be release architectures. Matthias
ada bootstrap error on alpha
gnat currently fails to build on alpha-linux-gnu, apparently not yet reproducible upstream. An idea? See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88200 Matthias
GCC and binutils updates for buster
GCC 8 is available in testing/unstable, and upstream is approaching the first point release. I am planning to make GCC 8 the default at the end of the week (gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC are already used in the version built from GCC 8, so I don't expect runtime incompatibilities anymore. There is one more transistion involved, bumping the libgfortran version. A pre-release version of binutils 2.31 is in testing now, and the final 2.31 release in unstable. These are the major versions for the upcoming buster release, still planning updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils 2.31.1 release, or doing equivalent updates from the release branches. There are still a bunch of build failures triggered by GCC 8 [1], so fixing these should get some priority now. See [2] for changes in GCC 8, and the porting guide [3]. I'll be at DebCamp for the second half of the week, and at DebConf, so if there is interest for bug squashing sessions, feel free to grab me, and we can schedule such sessions on a short notice. GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as there are upstream kernel and glibc releases which are released after the GCC 8.1.0 release from April. The Debian release team lists toolchain support for our release architectures, and according to [4], the amd64, i386, armel, armhf, arm64 architectures are supported as primary architectures, and s390x is supported as a secondary architectures. Some notes on other candidates for release architectures: - armel: The armv4t default isn't used very much anymore, and we had issues in the past. - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary architecture, I'm told that the arm-linux-armeabi triplet covers the hard float variants as well. - ppc64el: Not documented as primary architecture, but according to the backend maintainers the powerpc64-linux-gnu triplet includes the le variant. - mips*: There is no support for any mips-linux target either as a primary or secondary release architecture (only bare metal), which matches the experience with mips specific issues for the past Debian releases. I understand that port maintainers want to have their port included as a release architecture, however it becomes a burden if neither the upstream nor the Debian port maintainers can keep up with the general upstream development. Maybe we need something in between the alternatives of being a release arch or not, having the benefit of packages in testing/stable, but not being supported in a release. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;users=debian-...@lists.debian.org [2] https://gcc.gnu.org/gcc-8/changes.html [3] https://gcc.gnu.org/gcc-8/porting_to.html [4] https://gcc.gnu.org/gcc-8/criteria.html signature.asc Description: OpenPGP digital signature
preparing for binutils-2.31
According to [1], binutils 2.31 (currently in experimental) will branch in about a week, and I'll plan to upload the branch version to unstable. Test results are reported to [2], these look reasonable, except for the various mips targets, however as seen in the past, it doesn't make a difference if you wait with the introduction of a new binutils version early or later with the release. These tend to be only fixed as Debian porters report them. Matthias [1] https://sourceware.org/ml/binutils/2018-06/msg00158.html [2] https://sourceware.org/ml/binutils/2018-06/msg00170.html
gdc bootstrap failure on alpha-linux
seen on the gcc-7 branch, and now on trunk as well, with the gdc frontend merged. https://buildd.debian.org/status/fetch.php?pkg=gcc-8=alpha=8-20180130-1=1517382957=0 make[5]: Entering directory '/<>/build' rm -f stage_current make[5]: Leaving directory '/<>/build' Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! gcc/d/lexer.o differs Makefile:24128: recipe for target 'compare' failed make[4]: *** [compare] Error 1 make[4]: Leaving directory '/<>/build' Makefile:24107: recipe for target 'stage3-bubble' failed make[3]: *** [stage3-bubble] Error 2 make[3]: Leaving directory '/<>/build' Makefile:24170: recipe for target 'bootstrap' failed make[2]: *** [bootstrap] Error 2 the object files seem to be different ones on the branch and trunk.
Bug#888394: GCC bootstrap comparison failure build the D frontend on alpha
Package: src:gcc-7 Version: 7.2.0-20 Severity: important Seen with the last GCC 7 build from the branch on alpha, make[4]: Entering directory '/<>/build' make[5]: Entering directory '/<>/build' rm -f stage_current make[5]: Leaving directory '/<>/build' Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! gcc/d/lexer.o differs Makefile:23293: recipe for target 'compare' failed make[4]: *** [compare] Error 1 make[4]: Leaving directory '/<>/build' Makefile:23272: recipe for target 'stage3-bubble' failed make[3]: *** [stage3-bubble] Error 2 last successful build was on 20180107 (r256317). No changes in the gdc code.
Re: Enabling PIE by default for Stretch
[CCing porters, please also leave feedback in #835148 for non-release architectures] On 29.09.2016 21:39, Niels Thykier wrote: > Hi, > > As brought up on the meeting last night, I think we should try to go for > PIE by default in Stretch on all release architectures! > * It is a substantial hardening feature > * Upstream has vastly reduced the performance penalty for x86 > * The majority of all porters believe their release architecture is >ready for it. > * We have sufficient time to solve any issues or revert if it turns out >to be too problematic. > > As agreed on during the [meeting], if there are no major concerns to > this proposal in general within a week, I shall file a bug against GCC > requesting PIE by default on all release architectures (with backing > porters). please re-use #835148 > If there are only major concerns with individual architectures, I will > simply exclude said architectures in the "PIE by default" request. > > * Deadline for major concerns: Fri, 7th of October 2016. > > Fall-out > > > There will be some possible fall-out from this change: > > * There will be some FTBFS caused by some packages needing a rebuild >before reverse dependencies can enable PIE. These are a subset of >the bugs filed in the [pie+bindnow] build tests. > > * Some packages may not be ready for PIE. These will have to disable >it per package. A notable case being ghc (#712228), where we can >reuse the patch from Ubuntu to work around the issue. > > * A possible issue from Matthias was that no one has done a large scale >"PIE by default" on "arm* mips*". > > * There was concern about whether the 32bit arm architectures would be >notably affected by the PIE slow down (like x86 used to be). >It is not measured, but two arm porters did mention a possible >slowdown > > * It was questioned whether it made sense to invest time and effort in >enabling PIE for architectures which would not be included in Buster >(armel?). Personally, I do not see an issue, if the porters are >ready to put in the effort required. > > Thanks, > ~Niels > > [meeting]: > http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html > > [pie+bindnow]: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable > > > >
Re: Porter roll call for Debian Stretch
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote: > On 09/20/2016 11:16 PM, Niels Thykier wrote: >>- powerpc: No porter (RM blocker) > > I'd be happy to pick up powerpc to keep it for Stretch. I'm already > maintaining powerpcspe which is very similar to powerpc. No, you are not maintaining powerpcspe as a release architecture, and that's something different than building packages for some of the ports architectures. If you can get powerpcspe accepted as a release architecture, then maybe you gain some credibility to maintain another release architecture ;) Matthias
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 15.09.2016 22:43, Helge Deller wrote: > Hi Matthias, > > On 10.09.2016 00:48, Matthias Klose wrote: >> While the Debian Release team has some citation about the quality of the >> toolchain on their status page, it is not one of the release criteria >> documented >> by the release team. I'd like to document the status how I do understand it >> for >> some of the toolchains available in Debian. > >> Java/OpenJDK >> >> >> For the stretch release openjdk-8 will be fine as the default java >> implementation. For buster, gcj (to be removed in GCC 7) won't be available >> anymore, and we'll end up with architectures without a java implementation. >> At >> the same time I'd like to consider to stop providing OpenJDK zero builds, >> leaving powerpc and mips* without a java implementation as well (currently >> not >> building for openjdk-9). armhf (not armel) and s390x have Hotspot ports >> underway. > > Can you explain the reason why you consider stopping OpenJDK zero builds? the zero builds usually break on various architectures when the hotspot version is updated. So the zero ports require extra work and hinder migration of the packages to testing when they ftbfs. Afaiu the security team also doesn't care about these ports when they fail to build for security updates. > I'm asking, because on hppa we currently use gcj and we don't have any > OpenJDK port yet. > My hope was to fix at some point in future the old existing OpenJDK zero port > patches to get some newer > JDK even if it's slower. With your intention to stop zero builds, we probably > won't have any > JDK at all... I can't care for all ports which are not release architectures. Feel free to - send patches for the openjdk-8 package - look at the openjdk-9 build failures and send patches for the openjdk-9 package - Prepare to get these patches into openjdk-10, do regular builds of openjdk-10 when it becomes open for development, and continue to do so as long as you want to have it building. Matthias
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 10.09.2016 09:59, Paul Gevers wrote: > Hi, > > On 10-09-16 00:48, Matthias Klose wrote: >> - fpc not available on powerpc anymore (may have changed recently) > > For whatever it is worth, this was finally fixed this week. It is > missing on mips*, ppc64el and s390x though, while at least some form of > MIPS is supported upstream. the trunk/3.1 works at least for ppc64el too.
The (uncalled for) toolchain maintainers roll call for stretch
While the Debian Release team has some citation about the quality of the toolchain on their status page, it is not one of the release criteria documented by the release team. I'd like to document the status how I do understand it for some of the toolchains available in Debian. I appreciate that the release criteria are somehow "reset" for the stretch release, and not copied from previous release decisions. GNU toolchain (GCC / binutils) -- GCC upstream has the notation of primary and secondary platforms, with the commitment to fix issues on these platforms [1], [2]. Debian architectures within the set of these platforms are: - aarch64-none-linux-gnu (starting with GCC 7) - arm-linux-gnueabi - i686-pc-linux-gnu - powerpc64-unknown-linux-gnu - x86_64-unknown-linux-gnu - s390x-linux-gnu Release architectures missing in the primary and secondary platforms: - armhf - mips* - powerpc - ppc64el As you see with arm64, new architectures become primary or secondary platforms only after a while, so that may explain the absence of powerpc64le-unknown-linux-gnu. The arm-linux-gnueabi is not that well defined, so it may include the hard float variant as well. However Debian default to armv4t, while the default configuration for upstream is armv5. However with the selected defaults Debian's libstdc++::future module is not complete and causes build failures on this architecture (same for sparc). Uncovered by the upstream primary and secondary platforms are the mips* architectures and powerpc. For the uncovered archs I would expect somehow more and pro-active Debian maintenance, however I fail to see this happen. - see the history of ftbfs on the buildd page of the gcc-snapshot package - see the status of the gcc-6 package for the pre-release uploads - see the number of RC issues for binutils which came up with 2.27, some still open. - Toolchain packages are not watched by porters, and I can't track every regression myself, however this is not done well by porters. On the recent Porter's call I didn't see any toolchain support for the powerpc architecture. For the mips* architectures we apparently have five or more active toolchain maintainers. I very much doubt that view. From my point of view these architecture would be perfect candidates for partial architectures, and until then should be removed from the set of the release architectures. For mips* that shouldn't be no news; please see my comments regarding both the toolchain and buildd status since at least DebConf 12 (release meetings during DebConfs). Java/OpenJDK For the stretch release openjdk-8 will be fine as the default java implementation. For buster, gcj (to be removed in GCC 7) won't be available anymore, and we'll end up with architectures without a java implementation. At the same time I'd like to consider to stop providing OpenJDK zero builds, leaving powerpc and mips* without a java implementation as well (currently not building for openjdk-9). armhf (not armel) and s390x have Hotspot ports underway. Other toolchains - clang/llvm not available on armel since 3.8. - fpc not available on powerpc anymore (may have changed recently) - mono not available more on powerpc Being demoted as a release architecture certainly is not a nice thing, and looking at past demotions, these were not done very coordinated, not allowing builds in the ports archive for some months. It would be good to find some middle-ground such that a port's demotion isn't a final thing, and it has a chance to become a release architecture again, maybe even as a partial architecture if we can define the meaning of such a thing. Matthias [1] https://gcc.gnu.org/gcc-6/criteria.html [2] https://gcc.gnu.org/gcc-7/criteria.html
Re: preparing for GCC 4.9
sorry, can't help with this. setting up a pbuilder or sbuild, and start building packages from the base system? Matthias Am 13.05.2014 03:26, schrieb David Gosselin: I'm in the same boat as Patrick, except with a PowerMac G5. Please let us know how to begin. Thanks, Dave On May 12, 2014, at 16:02, Patrick Baggett baggett.patr...@gmail.com wrote: Hi Matthias et al, I'd like to try to do some of this using my sparc box and see how far I get. Is there a link that explains how to set up these steps? Others seem to just know what to do, but I haven't the slightest idea of where to begin. I have a box with gcc-4.9, plenty of disk space, and electricity to burn. Where do I start? Patrick On Thu, May 8, 2014 at 10:25 AM, Matthias Klose d...@debian.org wrote: With gcc-4.9 now available in testing, it is time to prepare for the change of the default to 4.9, for a subset of architectures or for all (release) architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already point to 4.9 and are used on all architectures. Issue #746805 tracks the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5371fb4e.9090...@debian.org
preparing for GCC 4.9
With gcc-4.9 now available in testing, it is time to prepare for the change of the default to 4.9, for a subset of architectures or for all (release) architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already point to 4.9 and are used on all architectures. Issue #746805 tracks the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org
Re: Roll call for porters of architectures in sid and testing
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar: For mips/mipsel, I - fix toolchain issues together with other developers at ImgTec It is nice to see such a commitment, however in the past I didn't see any such contributions. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52de6b8b.2060...@debian.org
gcc-4.9 uploaded to experimental
gcc-4.9 is uploaded to experimental, asking the porters to watch for build failures and corresponding patches. See https://buildd.debian.org/status/package.php?p=gcc-4.9suite=experimental These are already fixed in the vcs. - fixed the gospec.c ftbfs on archs without ld.gold - fixed the g++ b-d on armel/armhf Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Re: Bug#731069: gcc-defaults: Please resume considering to change using unified version of gcc
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto: Hi, I don't know whether it is appropriate that I remark, I have no objection to moving to gcc-4.8 on ppc64, too. this is not a question about any objections, but about a call to the ppc64 porters if they are able to maintain such a port in Debian. There is no response yet. I did check http://gcc.gnu.org/gcc-4.9/criteria.html and apparently ppc64 is a primary release architecture, so I did make it the default for sid (and will make 4.9 the default for jessie once uploaded to unstable). Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529e7cc6.1030...@debian.org
Re: Bug#731069: gcc-defaults: Please resume considering to change using unified version of gcc
Control: tags -1 + moreinfo Afaics, the situation didn't change. There is nobody committing to work on the toolchain for these architectures. At least for release architectures the alternative is to drop the port unless somebody wants to maintain the toolchain for this port. This is the current status, please correct me if I'm wrong. - alpha, no feedback, CCing Michael Cree. - hppa, no feedback, CCing John David Anglin - ia64, no feedback, likely to be removed. - powerpc, found some feedback from the porters, but unrelated to toolchain issues, see https://lists.debian.org/debian-powerpc/2013/11/msg00050.html - powerpcspe, no feedback, CCing Roland Stigge. - ppc64, no feedback - s390x, pending upload - sparc, no feedback - sh4, no feedback, doesn't build, CCing Nobuhiro Iwamatsu Am 01.12.2013 16:45, schrieb Hiroyuki Yamamoto: Source: gcc-defaults Version: 1.123 Severity: wishlist Tags: patch Please resume considering to change using unified version of gcc, because FTBFS of many packages occur by e.g. c++11 on ports which stayed using gcc-4.6 and g++-4.6, ia64, powerpc, s390x, sparc, alpha, powerpcspe, ppc64, sh4. And using unified version of gcc must bring happiness to many package maintainers. On the other hand, I understand that this changing depends on the correspondence status of gcc porting, so I leave decision to you. This is a decision for the porters. If there are no active porters, there shouldn't be a port. Unfortunately, building gcc-4.8 source package on sh4 has not succeeded yet, so here is a patch which changes gcc-4.8 using on ports except sh4. Regards, -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529c7999.2040...@debian.org
Re: Bits from the Release Team (Jessie freeze info)
Am 29.10.2013 17:48, schrieb Ian Jackson: (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. that's not enough. GCC has some primary and some secondary release architectures. Toolchain support for primary architectures in Debian should be waived, for the secondary and other architectures, Debian needs somebody who is maintaining the relationship between Debian and upstream. Surprisingly this is the case for many non-release Debian architectures like kfreebsd, the Hurd, alpha, hppa, m68k, but not for Debian release architectures like s390, sparc, ia64 and mips*. So we really need somebody to care about this, where the port is considered a secondary citizen or no citizen, or we should demote a port to the ports archive. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c2170.8020...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 15.06.2013 03:22, schrieb Stephan Schreiber: GCC-4.8 should become the default on ia64 soon; some other changes are desirable: - The transition of gcc-4.8/libgcc1 to libunwind8. - A removal of the libunwind7 dependency of around 4600 packages on ia64 - when they are updated next time after the transition. The libc6.1 should (likely) depend on libunwind8 after that in order to guarantee that libunwind8 is installed. unless some ia64 porter steps up, it doesn't make sense to invest time into the ia64 port. So better drop ia64 now, and don't bother with libunwind on ia64. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bf06cd.3070...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 21:47, schrieb Thorsten Glaser: Matthias Klose dixit: The Java and D frontends now default to 4.8 on all architectures, the Go frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. I’d like to have gcj at 4.6 in gcc-defaults for m68k please, until the 4.8 one stops FTBFSing. please send a patch. From me nothing against switching C/C++ to 4.8 for m68k at this point, but I’d like to hear at least Wouter’s opinion on that, and possibly Mikael since he’s not just doing work upstream on gcc but also using it (for ColdFire) heavily. same as well, please send a patch. For Ada, I’d like to see a successful build of gnat-4.8 (from src:gcc-4.8, if I understand the recent changes right) first; gnat-4.6 mostly works at the moment, but I’m not sure about the upstream situation wrt. patches from Mikael. try it and send a patch please. thanks for your cooperation, Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51baf88c.3080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 16:46, schrieb Steven Chamberlain: Hi, On 13/06/13 13:51, Matthias Klose wrote: GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. I trust these are the architectures that are okay so far: | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386 no, they are probably not ok, and there surely are yet undiscovered regressions, but at least the ARM porters did agree to address these. Same seems to be true for the kfreebsd and hurd porters. They did change GCC defaults usually at the same time as this was done for the x86 linux archs. So the following would be the architectures for which some response is requested urgently from port maintainers, to confirm they are ready for GCC 4.8 as default: Release arches: ia64 mips mipsel powerpc s390 s390x sparc All the above have built gcc-4.8.1-2 or higher. and nobody committing to scan the bts for architecture specific issues, nobody to prepare test cases, nobody to forward these. Other ports: alpha hppa* m68k powerpcspe ppc64 sh4* sparc64* * these ports don't appear to have successfully built GCC 4.8 yet. afaics, alpha, powerpcspe and ppc64 did build. Note that you cannot trust the hppa status, this port is still denied access to ports.debian.org and is kept in another place. So yes, some of these ports are in better shape than the ports released with wheezy. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bafa9e.5080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 07.05.2013 15:25, schrieb Matthias Klose: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. [...] Information on porting to GCC 4.8 from previous versions of GCC can be found in the porting guide http://gcc.gnu.org/gcc-4.8/porting_to.html It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove 4.4, 4.6 and 4.7 from jessie. GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. The Java and D frontends now default to 4.8 on all architectures, the Go frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b9c05f.8050...@debian.org
changing the java default to java7, and dropping java support for some architectures
It's time to change the Java default to java7, and to drop java support on
architectures with non-working java7.
Patches for the transition to Java7 should be available in the BTS, mostly
submitted by James Page. Some may be still lurking around as diffs in Ubuntu
packages, apologies for that. There are a few cases, where Java7 is not yet an
alternative to Java6, so the transition should not be blocked on these missing
bits. However it should be clear that this is an interim solution, and OpenJDK 6
will be removed for jessie.
Currently java bindings/packages are built for all architectures, however some
architectures still use gcj as the (only available) Java implementation, and
some OpenJDK zero ports are non-functional at this point, and Debian porters
usually don't care about that. So the architectures to drop java support would
be
kfreebsd-any, hurd-i386, mips, mipsel, s390, ia64
- kfreebsd may gain java 7 support at some time, however this shouldn't
be relied on yet.
- hurd never had openjdk support, and afaik, nobody is working on that.
- openjdk support for mips and mipsel is currently broken, with several
requests for help on debian-mips left unanswered.
- I fixed openjdk on s390 for the release, however this architecture is
time comsuming to maintain, and again no answers on debian-s390 asking
for help.
- same experience on ia64, however the zero ports seems to work there.
The list of java archs is a bit changing, and to avoid hardcoding this list into
every source package, I propose to something similiar like done for the gcj
architectures (/usr/share/gcj/debian_defaults). Let the packages be still
architecture any, and decide whether to build arch dependent packages on a make
macro java_archs.
Build dependencies would still need hard-coding of the architecture list, so
another idea would be to keep the default-{jre,jdk} packages on all
architectures and only use them if the architecture is found in java_archs.
Matthias
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5187bca6.3010...@debian.org
GCC 4.7 is now the default for x86 architectures
GCC 4.7 is now the default for x86 architectures for all frontends except the D frontends, including KFreeBSD and the Hurd. There are still some build failures which need to be addressed. Out of the ~350 bugs filed, more than the half are fixed, another quarter has patches available, and the remaining quarter isn't blocking any other 4.7 build failures. Many thanks to the patch submitters and NMUers, including Cyril Brulebois, Gregor Herrmann, Paul Tagliamonte for the fixes. This will add one more transition for x86 (libobjc3 - libobjc4), which needs starting with uploads of some GNUstep base packages. The D v2 frontend is likely to be updated to 4.7 before the freeze (no build dependencies). Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7ffd8.9010...@debian.org
targeting GCC 4.7.0 as the wheezy default for some architectures
GCC-4.7 packages are now available in testing and unstable; thanks to Lucas' test rebuild, bug reports are now filed for these ~330 packages which fail to build with the new version [1]. Hints how to address the vast majority of these issues can be found at [2]. I'm planning to work on these issues (help is welcome) in April, and then decide at the of April to change the default for some architectures; input from port maintainers is welcome if and when to change the default for any other archs. The current rebuild was done on amd64 only, any other (maybe partial) rebuild test on other architectures is welcome. The Java and Go frontends already default to 4.7, the D frontend may be updated for 4.7 in time (currently unused, as all D packages are built using gdc-v1). As I understand Ludovic, the Ada frontend will stay with 4.6. GCC-4.4 will stay in wheezy (D v1 frontend, somehow broken gcj-4.6 on release architectures like sparc). GCC-4.5 should be removed before the freeze. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-...@lists.debian.org [2] http://gcc.gnu.org/gcc-4.7/porting_to.html -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7bfdac.4040...@debian.org
please update patches / investigate build failures for gcc-4.7 snapshot builds
Please have a look at the gcc-4.7 package in experimental, update patches (hurd, kfreebsd, ARM is fixed in svn), and investigate the build failures (currently ia64, but more will appear). Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee7d60.9000...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be used for the next Fedora and OpenSuse releases, and a test rebuild of Ubuntu natty doesn't look too bad (mostly adding new easily fixable C++ build failures). A test rebuild of the unstable archive is still outstanding, but these build failures will have to be fixed anyway. From my point of view it's important to expose GCC 4.6 early in the release cycle to fix issues like #617628 (which are issues in the packages itself) now. With GCC 4.6 comes one soname change, bumping the libobjc version from 2 to 3, which is not easily detachable from the GCC version change. However this change only affects GNUstep, which can be dealt with NMU's, or migration to a new GNUstep version. It's unlikely that GCC 4.5 will be released with wheezy, as the Debian Ada and D maintainers are already working on GCC 4.6 support. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6dea5.5010...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote: On 26 April 2011 18:03, Matthias Klosed...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? yes, forgot about that. with GCC 4.6, armhf is built again from the 4.6 fsf branch, and lets us drop the GCC 4.5 Linaro variant. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6eb11.2080...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 09:28 PM, Kurt Roeckx wrote: On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I don't know, and I will not invest time to check. If you did check, and if you are confident to fix issues on these architectures, then please tell here. At least for other ports this seems to be possible (s390: Bastian Blank, kfreebsd-*: Aurelian, Petr). I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. I will not work on toolchain issues specific to these architectures for the wheezy release, so if nobody steps forward, then at least I will not change the default for these architectures. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db73b0c.4000...@debian.org
Re: gcc build failures on alpha
On 21.03.2011 13:19, Uros Bizjak wrote: On Sun, Mar 20, 2011 at 4:16 PM, Matthias Klose d...@debian.org wrote: https://buildd.debian.org/status/package.php?p=gcc-4.6suite=experimental Bootstrap comparison failure! gcc/opts.o differs make[4]: *** [compare] Error 1 Hm, 4.6.0-prerelease works for me [1]. maybe alpha-no-ev4-directive.diff targeting to ev4 makes a difference? https://buildd.debian.org/status/package.php?p=gcc-snapshot fails to build with a link error. Also mainline, but ATM a patch from [2] is needed. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02077.html [2] http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg02185.html -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d87452e.6080...@debian.org
gcc build failures on alpha
https://buildd.debian.org/status/package.php?p=gcc-4.6suite=experimental Bootstrap comparison failure! gcc/opts.o differs make[4]: *** [compare] Error 1 https://buildd.debian.org/status/package.php?p=gcc-snapshot fails to build with a link error. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d861a4b.4020...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 02.03.2011 07:36, Konstantinos Margaritis wrote: On 2 March 2011 03:34, Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Could you add armhf to the list? keeping armhf to build from the linaro branch? Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e5293.8060...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 02.03.2011 17:54, Martin Guy wrote: On 2 March 2011 02:34, Matthias Klose d...@debian.org wrote: armel (although optimized for a different processor) Hi For which processor (/architecture) is it optimized, and do you mean optimized-for, or only-runs-on? I ask in case this would mean dumping all the armv4t systems that are using Debian armel. I didn't propose changing the minimum required processor for armel. I said that 4.5 looks ok, although I can only say that for another processor default (armv7-a). Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e787c.9090...@debian.org
GCC-4.5 as the default for (at least some) architectures
I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.5;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6d9e89.8080...@debian.org
Re: DSO linking changes for wheezy
On 16.11.2010 10:42, Roger Leigh wrote: On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote: On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. This change is one I can agree with on technical grounds, though it will cause a great deal of pain in the short term. Have we got any estimates on exactly how much breakage will result before the change gets made? see http://wiki.debian.org/ToolChain/DSOLinking#Furtherinformation referenced in the first email of this thread. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce2c7c5.5040...@debian.org
Re: DSO linking changes for wheezy
On 15.11.2010 07:16, Roland McGrath wrote: mattst88 airlied_, does Fedora use --as-needed by default? Fedora 14 too? airlied_ mattst88: yes The naming of the options makes people easily confused. --no-add-needed is the only option Fedora's gcc passes. yes, OpenSuse is using --as-needed, but not --no-add-needed. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1acb3.1090...@debian.org
Re: DSO linking changes for wheezy
On 14.11.2010 16:06, Roger Leigh wrote: While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. It's not a very widely used feature. I'm sure it's trivial to make such a test case. Portable software tends not to make use of ELF- specific features like this, but that's not an excuse for breaking perfectly legitimate code. But whether or not there are real life examples, --as-needed is *fundamentally wrong*. It's deliberately *not doing what the user requested*, and to make that misfeature the system-wide default would be entirely inappropriate. If a package wishes to make use of such a feature after understanding the implications, then they are free to do so. But to make it the default--I don't think that's a technically sound decision. maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The point of injection is for discussion. I would prefer having this set in dpkg-buildflags, and then disabled by these ~100 packages. Note that this is probably the same like modifying the N - ~100 packages, as almost no package respects dpkg-buildflags yet. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ae11.2010...@debian.org
Re: DSO linking changes for wheezy
On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ccd1.8010...@debian.org
DSO linking changes for wheezy
For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. Thanks, Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ccacf9d.9080...@debian.org
Re: Bug#556790: gcc-4.3: unrecognizable insn on alpha
Version: 4.3.5-1 On 12.12.2009 14:43, Kurt Roeckx wrote: On Sat, Dec 12, 2009 at 12:30:57PM +0100, Kurt Roeckx wrote: On Sat, Dec 12, 2009 at 02:33:28PM +1300, Michael Cree wrote: What is the timeframe for getting the Alpha buildds updated to a fixed version of gcc? We've switched to 4.4 as default gcc a few days ago, and the buildds are also running it already. I've given back the packages that were known to fail, they should get build again soon. They were all succesful, except for wireshark which seems to be a known issue with the package and not alpha specific. So it's my understanding that PR8603 got applied to the4.3.4, 4.4.2 and the 4.5 branches which caused PR42113 and that that one is now fixed in the current 4.4.2 and 4.5 versions, but tht 4.3.4-6 still has this issue. fixed upstream on the 4.3 branch as well. this should be fixed at least in 4.3.5-1 (and 4.4). -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c02da42.3040...@debian.org
Re: icedtea6 build failures on alpha and armel using gcj
On 08.03.2010 13:34, Andrew John Hughes wrote: further, is it correct that the -ecj patch is applied to *both* the openjdk and openjdk-ecj directory? $ ls -l build/openjdk*/jdk/src/share/classes/sun/misc/FloatConsts.java -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14 build/openjdk-ecj/jdk/src/share/classes/sun/misc/FloatConsts.java -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14 build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java these are still hard links. No it's specifically only applied to -ecj patches. Wrong. The patch is applied in the openjdk-ecj directory, but because all files are hard links, it's applied in the openjdk directory as well. I don't see a way to have patch break the hard links while patching. You should only ever ship a build created from the openjdk tree and not openjdk-ecj/boot (i.e. the second stage of a full build or the result of a --with-openjdk/--disable-bootstrap build), which has a number of features turned off (including Nimbus). sure, this is always done in the Debian/Ubuntu builds. I didn't check this for other distributions. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b94f065.60...@ubuntu.com
icedtea6 build failures on alpha and armel using gcj
Building icedtea6 on alpha and armel using a two stage bootstrap fails with
different errors. These are no new errors, just rechecked the two stage
bootstrap, because the one stage build fails to build cacao after the b18
update. On alpha:
mkdir -p lib/rt
/home/doko/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/javac -g -d
lib/rt \
-source 1.5 \
-sourcepath \
'openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/corba/src/share/classes:/home/doko/openjdk/openjdk-6-6b18~pre1/build/generated'
\
-classpath /usr/lib/jvm/java-gcj/jre/lib/rt.jar \
-bootclasspath \'\' @rt-source-files.txt ;
incorrect classpath: ''
--
1. ERROR in
/home/doko/openjdk/openjdk-6-6b18~pre1/build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
(at line 52)
public static final float MIN_NORMAL = 1.17549435E-38f;
^^^
The literal 1.17549435E-38f of type float is out of range
--
1 problem (1 error)make[1]: *** [stamps/rt-class-files.stamp] Error 255
I vaguely remember we had a patch in the past to back out some of the constants
stuff.
On armel:
touch stamps/rewriter.stamp
mkdir -p rhino/rhino.{old,new}
(cd rhino/rhino.old ; jar xf /usr/share/java/js.jar)
/home/packages/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/java -cp
/home/packages/openjdk/openjdk-6-6b18~pre1/build/rewriter \
com.redhat.rewriter.ClassRewriter \
/home/packages/openjdk/openjdk-6-6b18~pre1/build/rhino/rhino.old
/home/packages/openjdk/openjdk-6-6b18~pre1/build/rhino/rhino.new \
org.mozilla sun.org.mozilla
Exception in thread main java.lang.ExceptionInInitializerError
No stacktrace available
Caused by: java.lang.RuntimeException:
java.lang.ArrayIndexOutOfBoundsException: 3
No stacktrace available
Caused by: java.lang.ArrayIndexOutOfBoundsException: 3
No stacktrace available
make[1]: *** [stamps/rewrite-rhino.stamp] Error 1
make[1]: Leaving directory `/home/packages/openjdk/openjdk-6-6b18~pre1/build'
This is reported as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
Matthias
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b894d27.5080...@ubuntu.com
any objections from port maintainers to make gcc-4.4 the default?
Besides the open license issue, are there any objections from port maintainers to make GCC-4.4 the default? As a first step that would be a change of the default for C, C++, ObjC, ObjC++ and Fortran. I'm not sure about Java, which show some regressions compared to 4.3. Otoh it's not amymore the default java compiler for all architectures except hurd(?), kfreebsd(?) and hppa. hppa already defaults to 4.4, what about the hurd and kfreebsd? Ada will still stay at 4.3 until Ludovic is ready to switch the default to 4.4. Matthias -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
OpenJDK Cacao GCJ Java defaults in unstable
Hi,
openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.
There are two new binary packages offering additional JVMs:
- openjdk-6-jre-zero: built on amd64 and i386. This is the JVM used by
default on the non-hotspot archs (armel, alpha, s390, mips, mipsel,
powerpc, m68k?). Maybe useful for debugging issues with the zero JVM on
archs which are more accessible.
- icedtea-6-jre-cacao: built on alpha, armel, mips, mipsel, s390, i386,
amd64, powerpc). The Cacao JVM and JIT is not yet feature complete
compared to the hotspot JVM, but is much faster than the Zero JVM
and offers an alternative on platforms which don't have the Hotspot
JVM.
The additional JVM's can be called with
java [-cacao|-zero]
or for the java tools with
tool name [-J-cacao|-J-zero]
This is currently a Debian/Ubuntu only option; integration into IcedTea is in
progress.
To make a JVM the default, make it the first one in /etc/java-6-openjdk/jvm.cfg.
GCJ is still the work horse to build and bootstrap OpenJDK. IMO it still does
make sense to keep the '-gcj' packages for software which is known to work with
GCJ. I plan to have a recent GCJ-4.x release for the next Debian release.
Once openjdk-6 moves to testing, I propose to change the default in the
default-{jre,jdk} packages to point to the openjdk-6 packages. This works well,
except for one thing: packages will be built with -source 1.6 by default, which
makes the resulting .class/.jar files unusable with older java versions (1.4 and
1.5). I would like to propose a change in the Debian java policy, that java
packages must be built for the version which is sufficient for a sucessful
build. The changes are trivial; I already did check in changes for ant and ant
build- and runtime dependencies into the debian-java svn.
There is currently work-in-progress to extend the Zero JVM with a JIT (called
shark). This is still experimental work, currently requires llvm-2.4 (unstable
has 2.5). I would welcome feedback from port maintainers about zero/shark.
Please consider to join the IcedTea mailing list.
Matthias
PS: I would appreciate some help with openjdk in Debian; the current maintainer
team is MIA or inactive.
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#472852: gnat-4.3 ftbfs on alpha
Package: gnat-4.3 Version: 4.3.0-1 Severity: serious see http://buildd.debian.org/fetch.cgi?pkg=gnat-4.3ver=4.3-20080202-1arch=alphastamp=1202775192file=log upstream builds to bootstrap. please fix this asap, the migration of gcc-defaults to testing depends on it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[alpha, hppa] GCC-4.3 as the default compilers for lenny?
For all ports besides alpha and hppa we plan to make GCC-4.3 the default compilers for lenny. - both alpha and hppa show regressions in the glibc testsuite when built with GCC-4.3 - gcj has a lot of regressions in 4.3 on alpha (but doesn't work in 4.2 either). - gij/gcj shows bus errors on hppa (either 4.2 or 4.3). Please could the porter teams give some advice (drop the architecture for the lenny release, use another (which?) compiler version, drop gcj/java support, or fix things)? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
java status on the ports
Besides m68k hopelessly being behind we do have serious problems on alpha, arm and hppa. - on arm, the bytecode compiler (ecj) doesn't produce correct code. there is currently a workaround to build the package on arm using byte-compiled code built on another architecture. Aurelian has more information on that issue. Afaik not a problem on armel. - on alpha, we do have testsuite failures, leading to a non-working interpreter (see http://bugs.debian.org/464156). We can build gcj-4.3 and ecj, but nothing more (if ecj is built with gcj-4.3). - on hppa, we do see bus errors trying to run the interpreter, plus new testsuite failure (see http://bugs.debian.org/464160). Any help to fix these ports is appreciated, having a replacment for gcj on these archs is fine as well. Test results on all other architectures look fine. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GCC 4.2 transition
The plans for the GCC 4.2 transition were described in http://lists.debian.org/debian-devel-announce/2007/06/msg8.html Does any port still need to stick with GCC 4.1 for a while? Feedback from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show objections against the transition. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gnat-4.1/gcj-4.1 manual builds needed on alpha, arm, m68k, mips, mipsel, s390, sparc
While having built and uploaded things correctly for experimental, I didn't do the same for unstable, which now needs some manual intervention building gnat-4.1 and gcj-4.1. gnat-4.1 (mips mipsel s390 sparc): - work in a sid chroot - install gnat-4.1-base libgnat-4.1 libgnatprj4.1 libgnatvsn4.1 from etch - fetch gnat-4.1 from etch - dpkg -x gnat-4.1_4.1.1-22_*.deb - rm -rf usr/lib/gcc/*/4.1.3 - tar cf - usr | (cd /; tar xfv -) - ln -sf ../4.1.2/gnat1 /usr/lib/gcc/$arch-linux-gnu/4.1/gnat1 - ln -sf ../4.1.2/adalib /usr/lib/gcc/$arch-linux-gnu/4.1/adalib - ln -sf ../4.1.2/adainclude /usr/lib/gcc/arch-linux-gnu/4.1/adainclude - build with dpkg-buildpackage -b -B -d (ignoring the gnat-4.1 b-d) - undo at least the symlinks in the chroot, or throw away the chroot gcj-4.1 (alpha arm m68k mips mipsel s390 sparc): - needs gcc-4.1_4.1.2 (not yet built on arm and m68k) - work in a sid chroot - install gcj-4.1-base libgcj7-0 libgcj7-jar libgcj7-dev libgcj7-awt gij-4.1 from etch - install other b-d's from sid - build as an extra check, build the package with itself (although this will be done with the next uploads anyway). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel build dependency on gcc-4.0?
Will gcc-4.0 be dropped as a build dependency for etch, or be kept? And on which architectures? Would you mind dropping gcc-4.0 from etch for some architectures? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358924: [alpha] libmudflap testsuite killed
Package: gcc-4.1 Version: gcc-4.1.0-0 Seen on two machines, the make -k check just terminates with Killed. dmesg shows: pass37-frag.exe(12520): unaligned trap at 000120026820: 00012aac 29 1 pass37-frag.exe(12520): unaligned trap at 0001200268a0: 00012794 29 5 pass37-frag.exe(12520): unaligned trap at 000120026820: e45fffc0b029034c 29 1 pass37-frag.exe(12520): unaligned trap at 000120026820: e45fffc0b029034c 29 1 tail of build/alpha-linux-gnu/libmudflap/testsuite/libmudflap.log: Executing on host: /home/doko/gcc/gcc-4.1-4.1.0/build/gcc/xgcc -B/home/doko/gcc/gcc-4.1-4.1.0/build/gcc/ -ggdb3 -DDEBUG_ASSERT -I/home/doko/gcc/gcc-4.1-4.1.0/src/libmudflap/testsuite -I/home/doko/gcc/gcc-4.1-4.1.0/src/libmudflap/testsuite/.. -I.. -L/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs /home/doko/gcc/gcc-4.1-4.1.0/src/libmudflap/testsuite/libmudflap.cth/pass39-frag.c -static -DSTATIC -fmudflapth -lmudflapth -lpthread -Wl,--noinhibit-exec -L/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/testsuite -ldl -lm -o ./pass39-frag.exe(timeout = 450) PASS: libmudflap.cth/pass39-frag.c (-static -DSTATIC) (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libstdc++-v3/src/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs:.:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libstdc++-v3/src/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libstdc++-v3/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libmudflap/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libssp/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/./gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/./prev-gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc/ada/rts Overriding timeout = 10 WARNING: program timed out. FAIL: libmudflap.cth/pass39-frag.c (-static -DSTATIC) execution test FAIL: libmudflap.cth/pass39-frag.c (-static -DSTATIC) output pattern test Output pattern 100 100 100 100 100 100 100 100 100 100 Setting LD_LIBRARY_PATH to .:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libstdc++-v3/src/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs:.:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libstdc++-v3/src/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libstdc++-v3/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libmudflap/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libssp/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/./gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/./prev-gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc/ada/rts Overriding timeout = 10 WARNING: program timed out. FAIL: libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 1) execution test FAIL: libmudflap.cth/pass39-frag.c (-static -DSTATIC) (rerun 1) output pattern test Output pattern 100 100 100 100 100 100 100 100 100 100 Setting LD_LIBRARY_PATH to .:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libstdc++-v3/src/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs:.:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libstdc++-v3/src/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/./libmudflap/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libstdc++-v3/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libmudflap/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/alpha-linux-gnu/libssp/.libs:/home/doko/gcc/gcc-4.1-4.1.0/build/./gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/./prev-gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc:/home/doko/gcc/gcc-4.1-4.1.0/build/gcc/ada/rts Overriding timeout = 10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-PIC objects in libglut.so built on alpha
tags 248091 -fixed thanks alpha porters, please could someone investigate why libglut.so does contain non-PIC objects? The build log [1] shows the object files beeing built with -fPIC, but pike7.4's build log [2] thinks otherwise. [1] http://buildd.debian.org/fetch.php?pkg=freeglutver=2.2.0-6.1arch=alphastamp=1084091296file=logas=raw [2] http://buildd.debian.org/fetch.php?pkg=pike7.4ver=7.4.47-2.1arch=alphastamp=1084320198file=logas=raw Thanks, Matthias
Re: Bug#212912: gcc-3.3: [alpha] Linux linker/loader does not support -mieee-conformant
[CCing to debian-alpha] As Chris (currently listed as package maintainer for gcc alpha) seems to be away, I'll ask on debian-alpha (Falk?), if this patch should be included. In that case the documentation should be changed to explicitely mention Debian instead of Linux. Tyson Whitehead writes: On Sunday 28 September 2003 14:54, you wrote: did you submit this patch upstream? If not, please can you do and attach the upstream PR? Thanks, Matthias Hi Matthias. I'm not quite sure by what you mean be upstream. Is it a Debian thing or a GNU thing. If it's the later, I posted a message on GNU GCC mailing list about it a month or two ago. It didn't go anywhere. Richard Henderson (the Alpha fellow from Red Hat) said he wouldn't accept it into the general GCC unless all users of GCC (i.e. BSD, etc) came forward and said they wanted it. He also gave three reasons why he personally didn't like it: 1- The default under DEC C is to not IEEE compliance 2- IEEE compliance leads to 'severe' performance penalties 3- The vast majority of SIGFPEs are due to unitialized data reads While one and three might be true (timing tests show that two is just plain wrong), they miss the point of the patch. The patch is intended to help achieve the goal of having as many packages as possible run on the Debian Alpha distribution as possible (without needing to specify Alpha specific flags). This means matching the GNU defaults on the other Debian architectures, and that just happens to be IEEE compliant libraries and code. Thanks -T -- Tyson Whitehead ([EMAIL PROTECTED] -- WSC-) Computer EngineerDept. of Applied Mathematics, Graduate Student- Applied MathematicsUniversity of Western Ontario, GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada
Re: Bug#202762: gcc-3.3: fails to compile kernel 2.4.22-pre8 on alpha
root writes: Package: gcc-3.3 Version: 1:3.3.1-0rc1 Severity: normal trying to compile kernel 2.4.22-pre8 on alpha i get: fork.c: In function `dup_mmap': fork.c:144: error: unrecognizable insn: (insn 59 52 61 0 0x2ce7760 (set (reg/f:DI 82) (symbol_ref:DI (@Smmlist_nr))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref:DI (@Smmlist_nr)) (nil))) fork.c:144: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. please the bug reporting instructions: with preprocessed source if appropriate. and you are missing the command line.
Re: GCC Alpha IEEE patch
Please can you submit this patch upstream ([EMAIL PROTECTED]) against the HEAD branch of gcc (which you can find as the gcc-snapshot package in Debian). Add the documentation to gcc/doc/invoke.texi. It's up to Chris Chimelis or Falk, if it should be applied to the gcc package. Tyson Whitehead writes: Here's a patch that makes IEEE compliant math operations (support for denormalization, nan, inf, etc) the default on the Alpha unless it is specifically turned off with -mno-ieee. It arose out of a discusion on the Alpha port list about packages SIGFPEing on the Alpha (see the thread 'SIGFPE and -mieee').
Re: gcc -O2 on alpha miscompiles ifupdown?
Please check with a gcc-2.95.3 prerelease compiled by Chris (http://master.debian.org/~doko/alpha) or with the test release currently in incoming. Current gcc snapshots (2.97) can be found in experimental (currently in incoming). Jim Crilly writes: Anthony Towns (aj@azure.humbug.org.au) wrote: Like the subject says; if I build ifupdown (0.6.4-1) on alpha with -O2 it breaks, if I build it with -O0, it's fine. With -O2, trying to trace what's going on with gdb doesn't seem to work (it jumps all over the place, fairly meaninglessly). In theory, ifupdown should just be a fairly normal ANSI C program. Most of the data structures aren't too complicated, and at worse there are a few function pointers. I think everything's fully typed, and there shouldn't be any weird casting. There was some buggy realloc's in the past (reallocing 4 bytes, instead of 4*sizeof(obj) bytes, mainly), but I believe they're all gone. I haven't looked at this (yet?), but I would guess it to be more bugs in gcc 2.95 we are using. If you look at the gcc 2.96 changelog you'll see there are quite a few bug fixes, a lot of them on Alpha. We've been plauged with bad gcc optimization on Alpha for about as long as I can remember. If no one knows for sure, I may have time in the next couple of days to play with it and see. Chris Chimelis ([EMAIL PROTECTED]) is the one to talk to about gcc bugs on Alpha. I would say either don't use -O2 (duh) or use a different gcc (probably not gonna happen anytime soon). Ron Just wanted to note I see a similar problem compiling the DAC960 driver in the 2.4 (2.2.X one works fine) kernel, with -O2 gcc segfaults, with -O0 it works. Sorry for not giving more information but my Alpha's at work right now and I'm not, I can send more on Monday if anyone want.
