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
Re: Bug#950550: libgcc1: upgrade from 1:9.2.1-25 to libgcc1 1:10-20200202-1 breaks gcc
On 2/3/20 2:27 PM, Anatoly Pugachev wrote:
> Package: libgcc1
> Version: 1:10-20200202-1
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> apt update && apt upgrade -y
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> before upgrade libgcc1:
>
>ii libgcc1:sparc64 1:9.2.1-25 sparc64 GCC support library
>
> after upgrade:
>
>ii libgcc11:10-20200202-1 sparc64 GCC support library
> (dependency package)
>
>* What was the outcome of this action?
>
> $ cat hello_world.c
> #include
>
> int main() {
> printf("%s \n", "hello world!");
> }
>
> $ gcc hello_world.c
> /usr/bin/ld: cannot find -lgcc_s
> collect2: error: ld returned 1 exit status
>
>* What outcome did you expect instead?
>
> able to compile c source codes files.
>
> Downgrading package back to version 9.2.1-25 helps
needs some kind of manual intervention. Adrian, please could you build gcc-9 -26
or -27 in a testing chroot?
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: openjdk-8 re-uploaded to unstable (currently in NEW)
On 26.05.19 21:13, Matthias Klose wrote: > The openjdk-8 packages which were unfortunately removed from unstable > (although > the issue #915620 only asked for the removal of some binaries), are now again > in > NEW, targeting unstable. One of the FTP assistants is objecting to the upload > to unstable, apparently because somebody (security team, Moritz?) asked to > restore these packages in experimental instead of unstable. Otoh, we still > need > these packages in unstable to bootstrap kotlin (yes we can bootstrap in > experimental, but then it's not assured how to build kotlin for unstable with > an > experimental build). > > I honestly don't understand why FTP master would have such an objection, so > please clarify what prohibits the acceptance to unstable with an RC issue to > not > propagate these packages to testing. The packages are now accepted and the 8u212-b03 upstream version is now uploaded as well. The changes and buildinfo files didn't exist anymore for the powerpc, ppc64, sparc64 and x32 binaries, so if a porter wants to restore those, please rebuild them with manually installed openjdk-8 packages from snapshot.debian.org. 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. >
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
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
Re: Bug#845461: gcc-6: Please build with --with-cpu=ultrasparc on sparc
On 24.11.2016 19:10, Jose E. Marchesi wrote: > > I'm pretty confident that --with-cpu=ultrasparc won't do any harm in > 64-bit mode, but Jose (CC'ed as gcc upstream) will hopefully correct > me here if I'm wrong. > > The cpu selected in --with-cpu impacts both -m64 and -m32 in a biarch > compiler. However, I can't say anything about the patch since I lack > the most basic context here, i.e. I have no idea what the contents of > that rules2 file are. The patches to configure --with-cpu-32= and --with-cpu-64= are availabe in GCC 6, so we should use them and ensure that the defaults for the sparc/64 and sparc64, and sparc and sparc64/32 targets match. Just forcing ultrasparc for all multilib variants seems to be questionable. Btw, is there any business with the Debian sparc port, or is this just some exercise? Matthias
Re: Bug#845461: gcc-6: Please build with --with-cpu=ultrasparc on sparc
Control: tags -1 - patch On 23.11.2016 18:58, John Paul Adrian Glaubitz wrote: > Hi Matthias! > > On 11/23/2016 06:09 PM, Matthias Klose wrote: >> why do you set this for the 64bit multilib as well? > > I was actually hoping you would comment on this :). I wasn't sure whether the > conditional is correct, I just had a look at a previous change in > debian/rules2 > which mentioned v9 in 32-bit mode [1]. It's the $biarch64 what confuses me. > > So, it would be great if you could correct me and make the rules2 pass the > proper > --with-mcpu=ultrasparc configure option on sparc-linux-gnu so that Helmut will > be able to rebootstrap on this target again. I haven't looked at this, and probably won't do it for a while. Best thing would be to build a package and check the generated code for both the 32bit and 64bit multilibs. The patch in its current form feels wrong.
Re: Bug#840574: Please backport libgo fixes for sparc64
Control: tags -1 - patch James, based on your feedback, I tried to apply these revisions on the branch, had to update some of these, and got a failed build. I'm not intending to work on this, and would like to ask you to prepare a tested debdiff for a backport or to get the backport upstream if you want to include the libgo port into the gcc-6 Debian packages. Matthias proposed patches, please really check On 16.10.2016 19:40, James Clarke wrote: > Control: tags -1 - help + patch > > Hi Matthias, > On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote: >> Control: tags -1 + help >> Control: tags -1 - patch >> >> James, please could you name the revisions in the GCC subversion repository? >> Afaics these are r241084, r241077, r241051. Even better, could you test and >> propose this backport upstream? > > To confirm, they are the following revisions: > > * r241171 (sparc64 relocations, e1fc2925 in go master, now also in >gofrontend/gccgo) > * r241084 (don't use pt_regs; unnecessary, and seemingly not defined by >the included headers on arm64) > * r241072 (make rawClone no_split_stack) > * r241051 (fix getrandom on sparc64 and clone on sparc*) > * r240457 (add getrandom for MIPS/SPARC) > > We've been using the latest gcc-6 package with these patches (other than > no_split_stack and pt_regs fixups) applied on top for sparc64 (uploaded > to unreleased) for the past few days, and the only packages which fail > to build seem to be because Debian currently has an out-of-date x/sys > package without sparc64 definitions. I haven't been aware of any > regressions. > > Ian: I imagine the getrandom and elf changes would be fine for gcc-6, > but what about the clone changes? I can understand if that's too > invasive, but backporting would be great. > > Regards, > James > >> On 12.10.2016 23:35, James Clarke wrote: >>> Source: gcc-6 >>> Version: 6.2.0-6 >>> User: debian-sparc@lists.debian.org >>> Usertags: sparc64 >>> X-Debbugs-Cc: debian-sparc@lists.debian.org >>> Tags: patch fixed-upstream >>> >>> Hi, >>> Could you please backport the patches listed below so that we can have a >>> working gccgo? They fix the (minor) issue of using the wrong syscall >>> number for getrandom (if code uses it), add support for sparc64's >>> relocations, and also the following error when running go build: >>> >>> /usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes >>> /usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1 >>> >>> The patches are: >>> >>> https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf >>> (not yet pulled into gofrontend's libgo) >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27 >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356 >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd >>> >>> With all but the last patch (a minor fixup after my patches), I have >>> been able to successfully build and run go programs on sparc64. >>> >>> Regards, >>> James >>> >>
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: Bug#777169: FTBFS on sparc64: symbol errors
On 06/18/2015 10:54 PM, John Paul Adrian Glaubitz wrote: On 06/17/2015 11:47 PM, John Paul Adrian Glaubitz wrote: Send a patch if you feel it is worth it. Currently working on that. Will throw in a patch once I got a working build which I will be uploading to unreleased. Attached patch fixes the FTBFS for me on sparc64. I'm about to upload a fixed version to unreleased now. The transfer of the compiled packages from the build machine is a bit slow at the moment. this doesn't look correct. You simply allow the libstdc++ build without these symbols. Please could you address this upstream, and ask to create a baseline symbols file, and then see if the build is supposed to be done without these symbols? thanks, Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55833837.5060...@debian.org
Re: Bug#777169: FTBFS on sparc64: symbol errors
On 02/05/2015 10:05 PM, Helmut Grohne wrote: Source: gcc-4.9 Version: 4.9.1-17 User: helm...@debian.org Usertags: rebootstrap gcc-4.9 currently FTBFS on sparc64 due to symbol errors. While the last two builds on sompek failed due to -ENOSPC the build of 4.9.1-17 shows proper symbol diffs: http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9arch=sparc64ver=4.9.1-17stamp=1413678403 The very same issue is reproducible with 4.9.2-10 in a cross-build setting: https://jenkins.debian.net/job/rebootstrap_sparc64_gcc49/105/console You can find the relevant excerpt from the native build at the end of this mail. Reporting during freeze without any expectation of having this fixed before the jessie release. sparc64 is not a release architecture, and with the current level of support I don't recommend making it a release architecture. This is probably just the first issue, so expect that more work is required. Send a patch if you feel it is worth it. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d3fa20.4070...@debian.org
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-sparc-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-sparc-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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52de6b8b.2060...@debian.org
Re: Bug#732282: stop building java for sparc, sparc64, s390, kfreebsd-any
Am 16.12.2013 11:34, schrieb Matthias Klose: Package: java-common Version: 0.50 Severity: serious Tags: jessie, sid openjdk-7 currently ftbfs on sparc, sparc64, s390, kfreebsd-any. So please either remove the default-* packages on these archs, or fall back to gcj. - the hotspot port for linux sparc isn't maintained anymore by upstream. If a porter is interested, maybe investigate how to build the zero vm on these architectures. - s390 needs an update of the s390 debian specific patch. Not working on this myself. - the debian kfreebsd patches need an update. I don't think it's feasible to burden the openjdk maintainers or the security team with patch maintenance. I understand that the bsd support is found upstream in openjdk-8, so maybe try that again for the next upstream version. ia64, sparc, sparc64, kfreebsd-i386 and kfreebsd-amd64 are now demoted to gcj on the VCS. Had to demote ia64 too, and don't want to investigate anymore. I'll upload java-common later this week. The good news is that arm64, mips, mipsel, powerpcspe, ppc64el and x32 are now promoted to use openjdk-7. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d24e65.5000...@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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Removing openjdk-7 for kfreebsd and sparc
please see http://bugs.debian.org/732282 Is there anybody who wants to maintain openjdk for these architectures? If not, I'll go ahead and make gcj-jdk the default again on those architectures and request removal of the kfreebsd and sparc binaries. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bf3db0.9040...@ubuntu.com
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-sparc-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: default-java and openjdk-7 on sparc
Am 23.11.2013 14:01, schrieb Aurelien Jarno: The patch I sent for MIPS also mentions SPARC as it has the same alignment constraints. That said the patch fixes zero, while SPARC is using hotspot by default instead. Maybe using zero on SPARC is a possibility, though it will decrease performances. sure, however last time I checked (maybe still with OpenJDK-6) it failed to build. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5290c858.4030...@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-sparc-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-sparc-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-sparc-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-sparc-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-sparc-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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5187bca6.3010...@debian.org
Re: [PPL-devel] ppl-1.0 tests fail to build on s390/s390x
Am 31.01.2013 10:11, schrieb Roberto Bagnara:
On 01/31/13 00:01, Matthias Klose wrote:
Am 30.01.2013 01:17, schrieb Matthias Klose:
[CCing the debian s390 porters]
Am 29.01.2013 09:32, schrieb Roberto Bagnara:
I just hit the wrong button on the administrative interface
of the ppl-devel mailing list. So the message has gone
forever before I could read it.
Please resend it to the list and accept my apologies.
Kind regards,
P.S. This is the failure, right?
https://buildd.debian.org/fetch.cgi?pkg=pplarch=s390xver=1.0-1stamp=1359396092file=log
yes, and the one for s390.
and apparently on sparc too.
This patch should fix them all:
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=3822e9ecd0783a5743dd48cda86ae17ba702c468
Please let us know how it goes.
PPL 1.1 will of course contain the fix and should be released
in a couple of months.
seems to work, however there is now a test failure on s390x
/bin/bash: line 5: 15154 Segmentation fault ${dir}$tst
FAIL: memory2
[...]
==
1 of 203 tests failed
Please report to ppl-de...@cs.unipr.it
==
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory
`/build/buildd-ppl_1.0-3-s390x-TUIydR/ppl-1.0/tests/Polyhedron'
make[3]: *** [check-am] Error 2
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511265ff.4070...@debian.org
Re: ppl-1.0 tests fail to build on s390/s390x
Am 30.01.2013 01:17, schrieb Matthias Klose: [CCing the debian s390 porters] Am 29.01.2013 09:32, schrieb Roberto Bagnara: I just hit the wrong button on the administrative interface of the ppl-devel mailing list. So the message has gone forever before I could read it. Please resend it to the list and accept my apologies. Kind regards, P.S. This is the failure, right? https://buildd.debian.org/fetch.cgi?pkg=pplarch=s390xver=1.0-1stamp=1359396092file=log yes, and the one for s390. and apparently on sparc too. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5109a636.8020...@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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7ffd8.9010...@debian.org
Re: GCC 4.7 is now the default for x86 architectures
On 07.05.2012 19:35, Thorsten Glaser wrote: Matthias Klose dixit: GCC 4.7 is now the default for x86 architectures for all frontends except the D frontends, including KFreeBSD and the Hurd. How are the plans for other architectures? I don't have plans to change any other architectures. If a port is not a release architectures (and port maintainers don't plan to make it a release architecture), people can change the default at any time from my point of view. As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_ runtime) told me that it dropped support for an old method of doing things while not fulfilling the promise to get the new method of doing it (don’t exactly remember what it was, /msg js on freenode for details) fixed, with the effect that gobjc-4.7 is virtually useless/broken. This is hearsay, but ask him for details, and check them against reality. I didn't rely on hearsay, but did ask the GNUstep maintainers for feedback. Please join the Debian GNUstep package maintainers ML if you want to add something, or review the past discussion. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa80a89.8070...@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-sparc-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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee7d60.9000...@debian.org
openjdk-7 7~b136-2.0~pre1-2 ftbfs on sparc
Package: openjdk-7 Version: 7~b136-2.0~pre1-2 Severity: important fails to build hotspot in stage1 g++-4.6 -DLINUX -D_GNU_SOURCE -DSPARC -DPRODUCT -I. -I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/share/vm/prims -I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/share/vm -I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/cpu/sparc/vm -I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm -I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os/linux/vm -I/build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION=\21.0-b07\ -DHOTSPOT_BUILD_TARGET=\product\ -DHOTSPOT_BUILD_USER=\buildd\ -DHOTSPOT_LIB_ARCH=\sparc\ -DJRE_RELEASE_VERSION=\1.7.0_136-b136\ -DHOTSPOT_VM_DISTRO=\OpenJDK\ -DDERIVATIVE_ID=\IcedTea7 2.0pre\ -DDEB_MULTIARCH=\sparc-linux-gnu\ -DDISTRIBUTION_ID=\Debian GNU/Linux unstable (sid), package 7~b136-2.0~pre1-2\ -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_sparc -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_linux_sparc -DTARGET_OS_ARCH_MODEL_linux_sparc -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 -mcpu=v9 -pipe -g -O3 -fno-strict-aliasing -Wpointer-arith -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/ostream.o.d -o ostream.o /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/share/vm/utilities/ostream.cpp /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp: In static member function 'static void os::print_register_info(outputStream*, void*)': /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:318:40: error: 'sc' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:318:60: error: 'CON__G1' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:319:60: error: 'CON__G2' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:320:60: error: 'CON__G3' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:321:60: error: 'CON__G4' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:322:60: error: 'CON__G5' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:323:60: error: 'CON__G6' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:324:60: error: 'CON__G7' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:327:60: error: 'CON__O0' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:328:60: error: 'CON__O1' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:329:60: error: 'CON__O2' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:330:60: error: 'CON__O3' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:331:60: error: 'CON__O4' was not declared in this scope /build/buildd-openjdk-7_7~b136-2.0~pre1-2-sparc-6bB1aS/openjdk-7-7~b136-2.0~pre1/build/openjdk-boot/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp:332:60: error: 'CON__O5'
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-sparc-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-sparc-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-sparc-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-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-sparc-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-sparc-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-sparc-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-sparc-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-sparc-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-sparc-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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ccd1.8010...@debian.org
Re: DSO linking changes for wheezy
On 16.11.2010 01:24, Roger Leigh wrote: On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote: 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. What's the actual problem --as-needed is trying to solve? why did I explain it in the wiki? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! and add more .pc files? Definitely not. I didn't see that many packages where different binaries/libaries were linked with a different set of libraries. Usually this is already introduced by upstreams. Using --as-needed is merely papering over the actual root problem. It fixes the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. Other libraries being linked unnecessarily can be removed on a per-package basis. lintian is warning about this, so most developers should be aware of the problem. Damaging our toolchain to work around buggy build scripts is wrong; we should just fix the scripts! again, this is not a script/pkgconfig problem only. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1d23f.7000...@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-sparc-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#566242: gcc-4.4: ICE when building polybori 0.5~rc1-2.1 on sparc: in change_address_1, at emit-rtl.c:1954
tag 566242 + wontfix tag 566242 + upstream tag 566242 + fixed-upstream fixed in 4.5. won't fix in 4.4. Use -mcpu=v9 as a workaround for gcc-4.4. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c20cf3d.9040...@debian.org
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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 06.09.2009 16:49, Jurij Smakov wrote: On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote: On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias, can you please make a definite statement on whether you, as a toolchain maintainer, are willing to support the existing 32-bit userland with a 64-bit kernel, or you consider a transition to 64-bit userland a necessary condition for sparc to be released with squeeze. This will be an important factor for the release team to determine what is going the port is currently using 4.3 as the default, I do plan to make 4.4 the default unless port maintainers object [1]. Ubuntu karmic already uses 4.4 as the default, but as a community port sparc doesn't get the same attention as other ports. Please see [2] for current problems with sparc. I do not plan to invest significant time in fixing build issues on sparc for squeeze. I do commit to prepare binutils and gcc-4.4 for a sparc64 port if this should happen for squeeze. Matthias [1] http://lists.debian.org/debian-release/2009/09/msg00239.html [2] http://qa.ubuntuwire.org/ftbfs/ -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 20.08.2009 16:52, Aurelien Jarno wrote: Bastian Blank a écrit : On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. If we are not sure that sparc and s390 (ie 32-bit versions) would be suitable for squeeze, this is almost sure they won't be suitable for squeeze+1. Isn't it the right moment to start a sparc64 and an s390x port, and if they are ready for squeeze release with them? Almost whatever upgrade solution you offer will require to have at least one release with both old and new architecture (like we did for arm - armel). Given that we already have sparc and s390 in the archive and that we also already have 64-bit ports, I don't expect any major problem for those new ports. Also given quite fast hardware exists for those architectures, it can probably be done relatively quickly. this seems to be the way to go, but port maintainers seem to lack enthusiasm or resources. I'm willing to help, if somebody commits to these ports. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 18.08.2009 22:43, Jurij Smakov wrote: Hello, I would like to point out that sparc release requalification is currently placing it in at risk position for squeeze release. The most serious problems with the port are lack of developer involvement (there is currently one active porter/developer known to the release team, Bernd Zeimetz) and the fact that current mixed 64-bit kernel with 32-bit userspace setup is not supported upstream (CC'ing doko for comment). The current configuration for a biarch toolchain defaulting to 32-bit isn't that well supported. The 32-bit compiler defaults to v8 hardware which isn't available anymore. The biarch setup tightly couples v9 and newer processor support to 64-bit, so switching to a 64-bit userland would offer better use of current hardware besides targeting a comparable setup as other distributions. Newer projects like llvm don't target 32-bit sparc anymore, while they do for 64-bit. I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. For both variants the toolchain is almost in place. glibc and binutils don't need modifications, gcc needs some libraries be built as biarch on sparc. zlib is already built as biarch on sparc. gmp and mpfr are already built as biarch on other archs, ppl and cloog would be good to have, but we could start without the graphite optimizations as well. I can prepare the changes for gcc, but will not help with any other transition work. [CCing debian-s390, because there are plans for a switch to s390x as well] Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Mike Hommey schrieb: On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote: Luk Claes schrieb: Matthias Klose wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. There are issues with the hppa port where the release team considered dropping it since 2005 communicated to the porter list... hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? I'm not aware of current toolchain issues on sparc and the issues on mips* still seem to be manageable, no? sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests to move to v9 optimization by default, which requires some work in the compiler. I don't plan to update this for upcoming GCC versions, and there's no interest by upstream to help with this kind of setup. You can't buy v8 software for years now, but afaik all our machines run 64bit kernels. Maybe it's time to acknowledge this, remove sparc from the list of release architectures and go on with sparc64? Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64, where the pros of the added registers overcome the cons of bigger pointers. In other words, 64 bits code is slower, fatter and more memory hungry than 32 bits code on sparc. which of the previous statements did you check? E.g. speed comparing the current 32bit v8 with 64bit ultrasparc code? and even then I wouldn't care that much if it becomes maintainable. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Luk Claes schrieb: Matthias Klose wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. There are issues with the hppa port where the release team considered dropping it since 2005 communicated to the porter list... hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? I'm not aware of current toolchain issues on sparc and the issues on mips* still seem to be manageable, no? sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests to move to v9 optimization by default, which requires some work in the compiler. I don't plan to update this for upcoming GCC versions, and there's no interest by upstream to help with this kind of setup. You can't buy v8 software for years now, but afaik all our machines run 64bit kernels. Maybe it's time to acknowledge this, remove sparc from the list of release architectures and go on with sparc64? there are currently binutils issues outstanding, reported upstream. plus the non-availability of developer machines seems to be an issue. Sadly we don't have the mips support for squeeze as we had for lenny. there are issues pointed out and not addressed like the -dev / -headers packages built as binary independent packages just to save disk space, which have an impact on slow architectures, and which are not addressed by the release team. would the release team mind addressing these real issues, or should we drop slow architectures as well? Well, this Packages issue is clearly a responsability from the FTP Team and the Release Team would indeed be very happy to have that resolved. So it seems to be ok to ignore an issue, if you can work around it? Fine, then I'll build all compiler front ends from one source again. Matthias -- To UNSUBSCRIBE, email to debian-sparc-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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Help for a FTBFS on sparc
tag 479185 + moreinfo severity 479185 important thanks this fails with 4.1, 4.2 and 4.3. At least 4.1 wasn't changed at all, so I assume the main reason is not GCC, but something else. The configury of this package uses the running kernel, which is 64bit. Does this lead to some wrong assumptions? -- 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]
g77-3.4 testsuite failures on sparc-linux
This is reported as http://gcc.gnu.org/PR17180 . Please could somebody on the list try to identify the patch mentioned in the followups which triggers these failures? Thanks, Matthias
Re: Bug#254626: gcc-3.3: wrong optimization on sparc32 when building linux kernel
Martin Habets writes: Package: gcc-3.3 Version: 1:3.3.4-1 Severity: normal Am building linux kernel 2.6.6 with CONFIG_CC_OPTIMIZE_FOR_SIZE=y set in .config. This results in -Os parameter to gcc. Resulting kernel does not boot and causes an oops (see below). This comes from this code in lib/vsprintf.c function vsnprintf: Do you know earlier gcc versions not showing the miscompilation? Please can you recheck with gcc-3.4 (found in the experimental distribution, or http://http.us.debian.org/debian/pool/main/g/gcc-3.4/) Thanks, Matthias
Re: G++ 3.2 breakage on sparc
[ok, this is a Debian self made problem, so don't read on ...]
The cause is the patch we apply to build a compiler for
sparc-linux, supporting -m64 as well. In the configury, the
_GLIBCPP_HAVE_funcL detect the /lib64/libc.so.6 ...
The testcase in #169497 works fine when compiled with g++-3.2 -m64.
Not sure why s390/s390x doesn't experience similiar problems ...
I will disable sparc64 support for the next upload. this is the last
bug before we can begin the gcc-3.2/g++-3.2 transition. So the safe
way seems to be to build the C compiler twice to provide a 64bit
compiler for sparc. Anyone on debian-sparc to take care of that or fix
the multilib build?
Matthias
Martin v. Loewis writes:
Matthias Klose [EMAIL PROTECTED] writes:
ok, I'm forwarding this to Martin and Phil, two upstream developers
(hopefully still ;-) listening on debian-gcc.
I would suggest that the libstdc++ autoconf test should be enhanced:
_GLIBCPP_HAVE_ACOSL should not be defined if no prototype is
available. I'm not quite sure though why the test program passes.
AFAICT, it tries to compile
#include math.h
int main()
{
acosl(0);
}
That is compiled using g++.
I'd be curious whether this compiles; it should not because no
prototype is declared for acosl.
If it does compile, the reason should be understood; if it is a good
reason, the test program should be modified to detect that no
prototype is available.
If this code does not compile, it should be investigated why configure
still defines _GLIBCPP_HAVE_ACOSL.
I don't have the time to design a patch, but the relevant macros is
GLIBCPP_CHECK_MATH_DECL_AND_LINKAGE_1, from libstdc++/acinclude.m4.
Regards,
Martin
Re: Gcc 3.2 64-bit mode on Sparc?
Roy Bixler writes: I am running Sid and have recently been compiling many kernels in an effort to get the 'ncpfs' filesystem to work on the Ultrasparc. Using the egcs64 package works for kernel 2.4.19 but it chokes on 2.4.20-pre5 with an internal compilation error. I then tried to compile the kernel with gcc-3.2, but was very surprised to find that it doesn't support 64-bit compilations. I found even gcc-3.1 doesn't support 64 bit mode. I did succeed in compiling 2.4.20-pre5 with gcc-3.0 but I shortly got a panic with the resulting kernel and am not confident that gcc-3.0 is good for compiling kernels. Does anyone know when I'll be able to compile kernels with a non-ancient (i.e. newer than egcs-2.92) GCC? There is a patch in debian/patches/sparc64-build.dpatch to build the 64bit binaries, which is broken since 3.1. The Debian packages are built with the alias sparc-linux, but somewhere unknown-sparc-linux-gnu gets in the way... To apply the currently disabled patch, edit debian/rules.patch. It would be nice, if someone interested in sparc64 could reenable the sparc64 build. Maybe building for sparc64-linux with code defaulting to sparc-linux could be done.
Bug#107569: gcc-3.0-sparc64_3.0.1-0pre010801_sparc fail apt-get install
I'm unable to test this on sparc (Ben?). Anyway: - which packages and versions are installed before? (gcc-3.0, gcc-3.0-sparc64, gcc-3.0-base) - does removing the old packages (gcc-3.0, gcc-3.0-sparc64) work around the problem? [EMAIL PROTECTED] writes: Package: gcc-3.0-sparc64 Version: 1:3.0.1-0pre010801 Severity: grave [EMAIL PROTECTED]:~$ sudo apt-get -yf install gcc-3.0-sparc64 Reading Package Lists... Done Building Dependency Tree... Done 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 packages not fully installed or removed. Need to get 0B/1101kB of archives. After unpacking 4096B will be used. (Reading database ... 20695 files and directories currently installed.) Preparing to replace gcc-3.0-sparc64 1:3.0-4 (using .../gcc-3.0-sparc64_1%3a3.0.1-0pre010801_sparc.deb) ... Unpacking replacement gcc-3.0-sparc64 ... dpkg: error processing /var/cache/apt/archives/gcc-3.0-sparc64_1%3a3.0.1-0pre010801_sparc.deb (--unpack): trying to overwrite `/usr/lib/gcc-lib/sparc-linux/3.0.1/cc1', which is also in package gcc-3.0 dpkg-deb: subprocess paste killed by signal (Broken pipe) dpkg-divert: rename involves overwriting `/usr/lib/gcc-lib/sparc-linux/3.0/cc1' with different file `/usr/lib/gcc-lib/sparc-linux/3.0/cc1.32', not allowed dpkg: error while cleaning up: subprocess post-removal script returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/gcc-3.0-sparc64_1%3a3.0.1-0pre010801_sparc.deb E: Sub-process /usr/bin/dpkg returned an error code (1) So, there is overwriting problem. -- Ma Tanuki -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gcc-3.0 on sparc
Please could someone look at #103568 and see if the proposed fix let's gcc-3.0 bootstrap on sparc?
bash for sparc: Release-critical bug inventory
Richard Braakman writes: Package: bash (main). Maintainer: Matthias Klose [EMAIL PROTECTED] [STRATEGY] Matthias Klose has bash 2.03 almost ready. 51188 bash: fails miserably on sparc Please could someone verify this with bash-2.03-1 ?
sparc libc5 support (report #29585).
I saw a bug filed against libreadline2 (libc5), that this package should not be built anymore for sparc. Is altgcc still needed for sparc (and the patch from report #29585) ?
Bug#50048: libg++2.8.2-dev: empty package on sparc
severity 50048 normal thanks this package will be removed soon ... Ben Collins writes: On Sat, Nov 13, 1999 at 11:02:32AM +0100, Matthias Klose wrote: There is a bug against ftp.debian.org to remove egcs (and libg++2.8.2-dev) from potato. The current libg++, which works with gcc-2.95 ist libg++2.8.1.3. Are there problems, that gcc-2.95 does not correctly work on sparc? Is this really a grave bug for sparc? Gcc 2.95 works perfectly on sparc afaik. I'll check into the empty package though.
Bug#50048: libg++2.8.2-dev: empty package on sparc
There is a bug against ftp.debian.org to remove egcs (and libg++2.8.2-dev) from potato. The current libg++, which works with gcc-2.95 ist libg++2.8.1.3. Are there problems, that gcc-2.95 does not correctly work on sparc? Is this really a grave bug for sparc? Madarasz Gergely writes: Package: libg++2.8.2-dev Version: 2.91.66-2 Severity: grave [EMAIL PROTECTED]:/var/cache/apt/archives$ dpkg -c libg++2.8.2-dev_2.91.66-2_sparc.deb drwxr-xr-x root/root 0 1999-06-03 16:34:56 ./ drwxr-xr-x root/root 0 1999-06-03 16:32:35 usr/ drwxr-xr-x root/root 0 1999-06-03 16:32:29 usr/doc/ drwxr-xr-x root/root 0 1999-06-03 16:33:10 usr/doc/libg++2.8.2/ -rw-r--r-- root/root 9475 1998-08-31 12:56:33 usr/doc/libg++2.8.2/NEWS.gz lrwxrwxrwx root/root 0 1999-06-03 16:32:29 usr/doc/libg++2.8.2-dev - libg++2.8.2 -- System Information Debian Release: potato Kernel Version: Linux debella 2.2.13 #17 SMP Tue Nov 9 18:17:19 CET 1999 sparc unknown Versions of the packages libg++2.8.2-dev depends on: ii libg++2.8.2 2.91.66-3 The GNU C++ extension library - old runtime
Re: libgcj-2.95 and Linux/sparc
[CC to some Debian places; anybody who has time to backport it?] Tom Tromey writes: Matthias == Matthias Klose [EMAIL PROTECTED] writes: Matthias Now that libgc5 is merged in the HEAD brnach of libgcj, it Matthias should build. But: Debian potato will ship with Matthias gcc-2.95.2. What libgcj should be built with this compiler? Matthias Can the boehm-gc from the libgcj-2_95-branch be replaced Matthias with the boehm-gc from the head branch? Can the HEAD branch Matthias be built with gcc-2.95.2? gcc-2.95.2 won't compile the CVS head of libgcj. You should use libgcj-2.95.2 (did we release that? I suddenly am not sure.) If you want to back-port sparc patches for Boehm GC, I'll check them in. I'm afraid I don't have time to look at this myself. Matthias http://www.debian.org/Bugs/db/48/48741.html Matthias libgcj depends on a non-free package Matthias This report suggests to work with minizip found in the zlib Matthias package. Is it possible to replace the standard zip with Matthias minizip? Probably. Can you give me a pointer to minizip? It's in the zlib's contrib directory. The README points to minizip/by Gilles Vollant [EMAIL PROTECTED] Mini zip and unzip based on zlib See http://www.winimage.com/zLibDll/unzip.html
new egcs-snapshot-19981110
You can find a new egcs snapshot on master in http://master.debian.org/~doko/ (soon to be moved to project/experimental). What's new? - rewritten sparc backend (includes ultrasparc support). - major (?) performance increase at least for dhrystone on ppro (9%) (see http://www.cygnus.com/ml/egcs/1998-Oct/1166.html). - new frontends (chill and java). - pascal front end currently disabled. I would like to get information about package builds on architectures other than i386. Please run the testsuite! (Needs dejagnu from project/experimental).
