Re: Bug#588391: gcc-4.4: please automatically use -ffunction-sections when necessary with -fPIC
On 08.07.2010 01:42, brian m. carlson wrote: Package: gcc-4.4 Version: 4.4.4-6 Severity: wishlist Because the ELF ABI for hppa requires relative jumps which are limited to 17 bits[0], programs frequently require the use of -ffunction-sections. It would be preferable if (on hppa or otherwise) -ffunction-sections were implied by -fPIC when otherwise gcc would generate text sections that are too large. After all, there's really no reason to generate .o files that are, for all practical purposes, useless. It would also make numerous package maintainers and hppa porters very happy, I suspect. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999#15 as this specific example shows, -ffunction-sections isn't enough, but -mlong-calls is needed. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5b2626.5090...@debian.org
Re: Bug#588391: gcc-4.4: please automatically use -ffunction-sections when necessary with -fPIC
On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote: On 08.07.2010 01:42, brian m. carlson wrote: Package: gcc-4.4 Version: 4.4.4-6 Severity: wishlist Because the ELF ABI for hppa requires relative jumps which are limited to 17 bits[0], programs frequently require the use of -ffunction-sections. It would be preferable if (on hppa or otherwise) -ffunction-sections were implied by -fPIC when otherwise gcc would generate text sections that are too large. After all, there's really no reason to generate .o files that are, for all practical purposes, useless. It would also make numerous package maintainers and hppa porters very happy, I suspect. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999#15 as this specific example shows, -ffunction-sections isn't enough, but -mlong-calls is needed. In that particular instance -mlong-calls is needed, but in the general case it appears not to be, judging from the numerous cases where only -ffunction-sections (and not -mlong-calls) is in use already in the archive. For example, #160538. My wishlist request still stands. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Releasability of the HPPA port
Dear HPPA porters, dear HPPA port users, the Release Team is currently wondering if it makes sense to release with HPPA as a regular stable architecture with squeeze. It might be that it is not up to the standards of a regular Debian release. We seem to chase random segmentation faults, causing multiple give-backs to eventually yield a built package. Especially this is also causing concerns from a security building point of view, as autobuilding has to work for this. If it's not entirely up to our standards, would a separate suite, like it has been done in the past for etch-m68k, help having some sort of release that can be updated independently from the main stable release? Such a suite could also be useful to land larger changes than normally allowed for stable and maybe to continue the hppa port from a stable foundation for some time. I think we do agree that it will be included into stable for the last time. Kind regards, Philipp Kern signature.asc Description: Digital signature
Re: Releasability of the HPPA port
On Fri, Aug 06, 2010 at 03:30:41AM +0200, Philipp Kern wrote: Dear HPPA porters, dear HPPA port users, the Release Team is currently wondering if it makes sense to release with HPPA as a regular stable architecture with squeeze. It might be that it is not up to the standards of a regular Debian release. We seem to chase random segmentation faults, causing multiple give-backs to eventually yield a built package. I realize this doesn't address the larger concerns you mention, but.. I've found that a workstation I recently acquired (a c3700) seems to reliably build packages that reliably fail on our existing buildds (subversion, for one). I assume CPU architecture differences allow this box to be immune to the issues causing these builds to fail. Due to the formfactor, I don't think HP would be able to host it and my upstream bandwidth at home is too limited. If the project wanted to make this machine a buildd and find hosting for it, I'd be willing to maintain the buildd. Especially this is also causing concerns from a security building point of view, as autobuilding has to work for this. If it's not entirely up to our standards, would a separate suite, like it has been done in the past for etch-m68k, help having some sort of release that can be updated independently from the main stable release? Such a suite could also be useful to land larger changes than normally allowed for stable and maybe to continue the hppa port from a stable foundation for some time. I think we do agree that it will be included into stable for the last time. Kind regards, Philipp Kern -- dann frazier -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100806014649.ga18...@lackof.org
