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: Same procedure as every year: GCC defaults change (GCC 9)
On Jul 28 2019, Aurelien Jarno wrote: > The two MIPS libffi patches have been accepted upstream (i.e. in the > libffi git repository) 1.5 years ago for one and 4 years ago for the > other. I know there hasn't been any recent libffi release, so what can > be done to sync the gcc repository? Would it be possible to stop using > that outdated embedded copy and use the debian libffi package instead? The gcc copy of libffi accepts backports. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Same procedure as every year: GCC defaults change (GCC 9)
On 2019-07-27 17:28, Matthias Klose wrote: > 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 To be more exhaustive, for release architectures there are also patches concerning the arm target and for other architectures patches concerning the alpha, ia64 and sparc targets. > targets. Please forward these upstream and make sure that these are applied > upstream. The two MIPS libffi patches have been accepted upstream (i.e. in the libffi git repository) 1.5 years ago for one and 4 years ago for the other. I know there hasn't been any recent libffi release, so what can be done to sync the gcc repository? Would it be possible to stop using that outdated embedded copy and use the debian libffi package instead? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
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
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
Bug#854074: gcc-6: please enable PIE hardening flags by default on kfreebsd-*
Hi, Matthias Klose wrote: > [CCing porters, please also leave feedback in #835148 for non-release > architectures] Since that bug is done/closed/actioned, I've cloned a new one for this request. > On 29.09.2016 21:39, Niels Thykier wrote: > > 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). I think we are ready for this now; please enable PIE by default on kfreebsd-* when it is practical (or rather, allow dpkg-buildflags to enable it). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: preparing for GCC 4.9
Hello and apologies for the cross-post, I've built GCC 4.9 on my PowerMac G5 (ppc64) running Debian 7.3. I'd like to support the port of Debian to this platform using GCC 4.9 and would appreciate a pointer on where to begin if possible. Additionally, I could provide a SSH login to the machine. Thanks, Dave -Original Message- From: Matthias Klose Sent: Tuesday, May 13, 2014 7:00 AM To: David Gosselin ; Patrick Baggett Cc: debian-po...@lists.debian.org Subject: 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 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 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-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5371fb4e.9090...@debian.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/B91D376632C449D19144C06F2D3226D4@Sam
Re: preparing for GCC 4.9
I tested to build kernel for Loongson 3 with gcc-4.9. it works fine. On Fri, May 30, 2014 at 6:00 PM, Adam Conrad wrote: > On Thu, May 08, 2014 at 05:25:02PM +0200, Matthias Klose wrote: >> >> 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'm confident that other than one or two potential outliers, test build > results on powerpc and ppc64 should have the same number of regressions > as ppc64el, and also quite confident that where that's not the case, we > can get it fixed in a hurry, so please do those arches in lockstep with > the rest. > > ... Adam > > PS: Switching hats to arm64, that one should also rev with the rest, > but I think that's probably a no-brainer anyway, given that it's > a new ports, where staying on the cutting edge is usually sanee. > > > -- > To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20140530100040.gw28...@0c3.net > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKcpw6WZjC=2ivjhkflif1dix+p7pqgd-qrpj8y6zqcjzxm...@mail.gmail.com
Re: preparing for GCC 4.9
On Thu, May 08, 2014 at 05:25:02PM +0200, Matthias Klose wrote: > > 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'm confident that other than one or two potential outliers, test build results on powerpc and ppc64 should have the same number of regressions as ppc64el, and also quite confident that where that's not the case, we can get it fixed in a hurry, so please do those arches in lockstep with the rest. ... Adam PS: Switching hats to arm64, that one should also rev with the rest, but I think that's probably a no-brainer anyway, given that it's a new ports, where staying on the cutting edge is usually sanee. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530100040.gw28...@0c3.net
Re: preparing for GCC 4.9
Hi, On 08/05/14 16:25, Matthias Klose wrote: > 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 rebuilt 105 source packages on kfreebsd-amd64 comprising minbase and build-essential (except for GCC itself) using GCC 4.9 and did not notice any new build failures introduced by it. I'll continue to check that the binaries compiled by GCC 4.9 are actually okay. The issue with running the GCC testsuite on kfreebsd-amd64 buildds is being fixed by FreeBSD upstream, and on Debian buildds within 1-2 weeks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5381122c.3010...@pyro.eu.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 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 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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5371fb4e.9090...@debian.org
Re: preparing for GCC 4.9
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 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 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 >
Re: preparing for GCC 4.9
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 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 > >
Re: preparing for GCC 4.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matthias Klose 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 OK. I will cooperate in ppc64 port as possible as i do, at least, tests of rebuilding the packages of buildd with gcc-4.9. Regards, - -- Hiroyuki Yamamoto A75D B285 7050 4BF9 AEDA 91AC 3A10 59C6 5203 04DC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTbXdtAAoJEDoQWcZSAwTcH04P/ixcu5J5qvYu6jgiB4E6NjaQ 6be0mrGI26KYv+h2jJ09+5bgPx4JS/JBlvM9ACK1XHnOGovgTG21CXumPmvwLZ3T ePO54VsyARPgElZ/ZQg8V8rNozxN+sMtQSKZ2F72a6v/xE5ydNHPQpG5/ecewDzY 0LB/Sy+EZoPYQJ9GExWaVLscAjxMLko9GvMwB19Ol48It2UygtXDD0XL+RUiMMWJ tBbwZ+djAVDII1auqroicaeurXEXYrDkYKt5ECxlsJyWP7YaX8h9T9rTNePIxho9 kgDbTW8R4Jcscxzv1rE11fomQeJDft5LqpW0go1tLOjKm4W4N44uC7FI8TdSyART DYVvW3GZJvMroNNATkFJMopEVsPOr5KIAzmmIlqNT1NsBKzfLQGkSZ/yrdpZl2r4 khUMXELPCMkpv1PibvcB/BszH+eP1/AQ/clwk1sRl1oeeyKXiwD3k9WzIq3f+D1+ rMzocwwy9U3gSntubt0cYElWmpb5cYbZELlBNiIE6zyYNZe9e4DC3adjREAkto8j 7fYdmoytih7hX+hJ2iiS8l9mf65uGDG7fyH5+ZL1Q/OZcd7QrrgdfhYR6ravJtcQ KyWX3a0Qud2BRHhkTQQl79rHNkeYnKJtnKkd/63GamznuRXF6qa+UWQ4CJsGMX3C K4deC7n0232ZuW9qj2hq =n4y4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536d776e.6020...@gmail.com
Re: [m68k] preparing for GCC 4.9
On Thu, May 08, 2014 at 03:49:51PM +, Thorsten Glaser wrote: > Matthias Klose dixit: > > >I would like to see some partial test rebuilds (like buildd or minimal chroot > > Haven???t tried yet, but Helmut Grohne does automated rebootstrapping of > some ports using what he can get his hands on, and he said m68k was the > best-(cross)bootstrappable port, and was using gcc-4.9 for it, so there > are probably at least no ICEs. I should note that rebootstrap builds much less than a minimal chroot. It also does not try to execute any of the results. I did not encounter any ICEs during any builds for any architecture with rebootstrap yet. > If Helmut can publish the *.deb files that fall out of such a (cross) > rebootstrap, we could try debootstrapping (natively, in ARAnyM) from > them, then boot (a VM) into them, to check basic usage. You have two options to achieve that: 1) Check out the rebootstrap git repository, debootstrap a fresh throw-away chroot and run bootstrap.sh in there. Takes 6 hours. Pointers at https://wiki.debian.org/HelmutGrohne/rebootstrap 2) Submit a patch for git.debian.org:/srv/qa/jenkins.debian.org.git to collect build artefacts. Then tell me, so I can trigger a rebuild. Helmut -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140508160731.ga1...@alf.mars
Re: [m68k] preparing for GCC 4.9
(excluding d-release for what they hatingly call “debian-ports spam”) Matthias Klose dixit: >I would like to see some partial test rebuilds (like buildd or minimal chroot Haven’t tried yet, but Helmut Grohne does automated rebootstrapping of some ports using what he can get his hands on, and he said m68k was the best-(cross)bootstrappable port, and was using gcc-4.9 for it, so there are probably at least no ICEs. If Helmut can publish the *.deb files that fall out of such a (cross) rebootstrap, we could try debootstrapping (natively, in ARAnyM) from them, then boot (a VM) into them, to check basic usage. This sounds pretty few work. Other than that… we’ve built src:gcc-4.9 now, which means that at least the C/C-- part survives the three-stage bootstrap AFAICT. >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. … that runs it. I have no idea how to set up such a test rebuild setup, but we have somewhat clonable VMs (and a VM base image that “just” needs to be dist-upgraded to latest sid before using it), so “anybody” can do that for m68k (provided they install the aranym package from sid, as it contains FPU emulation bugfixes required by Python 3.5 at least). Also, I’d be interested in a way to run GCC’s testsuite against an installed compiler, i.e. without taking the five days needed for the bootstrap (plus adding dejagnu and removing disabling the testsuite from the package rules) again. bye, //mirabilos -- Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405081543370.28...@herc.mirbsd.org
Re: preparing for GCC 4.9
On Thu, May 8, 2014 at 11:25 PM, Matthias Klose 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 set a build farm with gcc-4.9 for mips64el. It works well: it has no more failures than your amd64 one. All the buildlogs can be found in http://mips.wicp.net:9998/mips2/buildlog/ I noticed ctpp2 failed due to symbols problems on both amd64(pbuilder) and mips64el(sbuild). It seems that you didn't report bug on it. > > 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-bsd-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/536ba1ce.9070...@debian.org > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKcpw6Ve=nbetyywgw+qm99bohki2q+1dvxw6fzazfna9wc...@mail.gmail.com
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-amd64-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: cross-building gcc stage3 fails due to wrongly placed libvtv
On Sat, Apr 19, 2014 at 10:26:21AM -0700, Daniel Schepler wrote: > I've seen the same thing on gcc-4.9 buildd logs on x32. And no, I > don't know of any fix for this. doko would probably know better than > I do. #745267 Thanks anyway Helmut -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140420050116.ga11...@alf.mars
Re: cross-building gcc stage3 fails due to wrongly placed libvtv
I've seen the same thing on gcc-4.9 buildd logs on x32. And no, I
don't know of any fix for this. doko would probably know better than
I do.
(Unfortunately, my x32 buildd's hard drive is dying, so I've decided
to take that buildd offline until I can get a warranty replacement.)
--
Daniel Schepler
On Sat, Apr 19, 2014 at 2:26 AM, Helmut Grohne wrote:
> Hi,
>
> I am trying to cross build gcc-4.9 for x32 on amd64 and run into this
> error:
>
> mv debian/tmp/usr/lib/x86_64-linux-gnux32/libvtv*.a
> debian/libgcc-4.9-dev/usr/lib/gcc/x86_64-linux-gnux32/4.9/
> mv: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnux32/libvtv*.a': No such
> file or directory
>
> This is due to vtv being placed in the wrong directory:
>
> make[7]: Entering directory
> `/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/build/x86_64-linux-gnux32/libvtv'
> true DO=install multi-do # /usr/bin/make
> test -z "/usr/x86_64-linux-gnux32/lib/../lib" || /bin/mkdir -p
> "/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib"
> /bin/bash ./libtool --mode=install /usr/bin/install -c libvtv.la
> '/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib'
> libtool: install: /usr/bin/install -c .libs/libvtv.so.0.0.0
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.so.0.0.0
> libtool: install: (cd
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
> && { ln -s -f libvtv.so.0.0.0 libvtv.so.0 || { rm -f libvtv.so.0 && ln -s
> libvtv.so.0.0.0 libvtv.so.0; }; })
> libtool: install: (cd
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
> && { ln -s -f libvtv.so.0.0.0 libvtv.so || { rm -f libvtv.so && ln -s
> libvtv.so.0.0.0 libvtv.so; }; })
> libtool: install: /usr/bin/install -c .libs/libvtv.lai
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.la
> libtool: install: /usr/bin/install -c .libs/libvtv.a
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
> libtool: install: chmod 644
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
> libtool: install: /usr/x86_64-linux-gnux32/bin/ranlib
> /tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
> libtool: install: warning: remember to run `libtool --finish
> /usr/x86_64-linux-gnux32/lib/../lib'
>
> More context can be found at
>
> https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_x32_gcc49/lastFailedBuild/console
>
> Is a fix to this issue already known?
>
> Please CC me in replies.
>
> Thanks in advance
>
> Helmut
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CADf0C44HM1v6AHYExBeY1=pucsxdbw4gbglpbs7a8k_hi+b...@mail.gmail.com
cross-building gcc stage3 fails due to wrongly placed libvtv
Hi,
I am trying to cross build gcc-4.9 for x32 on amd64 and run into this
error:
mv debian/tmp/usr/lib/x86_64-linux-gnux32/libvtv*.a
debian/libgcc-4.9-dev/usr/lib/gcc/x86_64-linux-gnux32/4.9/
mv: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnux32/libvtv*.a': No such
file or directory
This is due to vtv being placed in the wrong directory:
make[7]: Entering directory
`/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/build/x86_64-linux-gnux32/libvtv'
true DO=install multi-do # /usr/bin/make
test -z "/usr/x86_64-linux-gnux32/lib/../lib" || /bin/mkdir -p
"/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib"
/bin/bash ./libtool --mode=install /usr/bin/install -c libvtv.la
'/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib'
libtool: install: /usr/bin/install -c .libs/libvtv.so.0.0.0
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.so.0.0.0
libtool: install: (cd
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
&& { ln -s -f libvtv.so.0.0.0 libvtv.so.0 || { rm -f libvtv.so.0 && ln -s
libvtv.so.0.0.0 libvtv.so.0; }; })
libtool: install: (cd
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib
&& { ln -s -f libvtv.so.0.0.0 libvtv.so || { rm -f libvtv.so && ln -s
libvtv.so.0.0.0 libvtv.so; }; })
libtool: install: /usr/bin/install -c .libs/libvtv.lai
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.la
libtool: install: /usr/bin/install -c .libs/libvtv.a
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
libtool: install: chmod 644
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
libtool: install: /usr/x86_64-linux-gnux32/bin/ranlib
/tmp/buildd/gcc3/gcc-4.9-4.9-20140411/debian/tmp/usr/x86_64-linux-gnux32/lib/../lib/libvtv.a
libtool: install: warning: remember to run `libtool --finish
/usr/x86_64-linux-gnux32/lib/../lib'
More context can be found at
https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_x32_gcc49/lastFailedBuild/console
Is a fix to this issue already known?
Please CC me in replies.
Thanks in advance
Helmut
--
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140419092605.GA18471@localhost
Re: gcc-4.9 uploaded to experimental
On Fri, Jan 10, 2014 at 7:23 PM, Matthias Klose wrote: > 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.9&suite=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 The build log on mips64el can be found from: http://mips64el.debian.net/attempted/gcc-4.9-mips64el.log.xz > > Matthias > > > -- > To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/52cfd843.1010...@debian.org > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6VzmezVP+6LFsb7Afs=xmhs9e295ybriksp0sn7aa0...@mail.gmail.com
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.9&suite=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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Re: GCC 4.7 is now the default for x86 architectures
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? The m68k status (which obviously can’t influence the release decisions) is as follows: gcc-4.7 builds, last time I looked gcj-4.7 didn’t but it is currently building again (so let’s see whether it does this time); gcc-4.6 and gnat-4.6 are getting development and bugfixes (I’ve queued up some patches, but am not entirely ready with all of them, plus some for binutils and gdb), and I’ve asked for help re. the gcj-4.4/gcj-4.6 recent problems. But nothing has tested gcj-4.7, and I fear of new and old bugs… so I’d rather not switch default compiler to it anytime soon. 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. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205071730550.28...@herc.mirbsd.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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa80a89.8070...@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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7ffd8.9010...@debian.org
targeting GCC 4.7.0 as the wheezy default for some architectures
GCC-4.7 packages are now available in testing and unstable; thanks to Lucas' test rebuild, bug reports are now filed for these ~330 packages which fail to build with the new version [1]. Hints how to address the vast majority of these issues can be found at [2]. I'm planning to work on these issues (help is welcome) in April, and then decide at the of April to change the default for some architectures; input from port maintainers is welcome if and when to change the default for any other archs. The current rebuild was done on amd64 only, any other (maybe partial) rebuild test on other architectures is welcome. The Java and Go frontends already default to 4.7, the D frontend may be updated for 4.7 in time (currently unused, as all D packages are built using gdc-v1). As I understand Ludovic, the Ada frontend will stay with 4.6. GCC-4.4 will stay in wheezy (D v1 frontend, somehow broken gcj-4.6 on "release" architectures like sparc). GCC-4.5 should be removed before the freeze. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-...@lists.debian.org [2] http://gcc.gnu.org/gcc-4.7/porting_to.html -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7bfdac.4040...@debian.org
Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
On 19 December 2011 14:55, Konstantinos Margaritis wrote: > On 19 December 2011 01:55, Matthias Klose wrote: >> 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). > > Attached is the build failure on armhf (clean chroot with all bdeps > satisfied). Just tested 4.7-20111222-1 as well, it built fine, installed and tested 5 known gcc ICEs (ace, webkit, 2 neon-related ones, a gfortran one) and all but one neon ICE were fixed :) Regards Konstantinos -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabsevwt_qdasf6hg_ev2e3vvexdnnrxdvsqjerfbz6rbae4...@mail.gmail.com
Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
Hi, On ppc64, both packages of gcc-4.7 (4.7-20111217-2) and gcj-4.7 (4.7-20111217-1) were built without any problem. Matthias Klose wrote: > 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 -- Hiroyuki Yamamoto A75D B285 7050 4BF9 AEDA 91AC 3A10 59C6 5203 04DC -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef0af7e.2060...@gmail.com
Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
El 19 de desembre de 2011 0:55, Matthias Klose ha escrit: > 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). Existing kbsd-gnu.diff is obsolete, please replace with attached build fix. -- Robert Millan --- a/src/gcc/config/kfreebsd-gnu.h~ 2011-07-21 17:31:44.0 +0200 +++ b/src/gcc/config/kfreebsd-gnu.h 2011-12-19 20:20:26.961301396 +0100 @@ -33,3 +33,4 @@ #define GNU_USER_DYNAMIC_LINKERGLIBC_DYNAMIC_LINKER #define GNU_USER_DYNAMIC_LINKER32 GLIBC_DYNAMIC_LINKER32 #define GNU_USER_DYNAMIC_LINKER64 GLIBC_DYNAMIC_LINKER64 +#define GNU_USER_DYNAMIC_LINKERX32 GLIBC_DYNAMIC_LINKERX32
Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
On 19 December 2011 01:55, Matthias Klose wrote: > 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). Attached is the build failure on armhf (clean chroot with all bdeps satisfied). Konstantinos gcc-4.7_4.7-20111217-2_armhf.build_log Description: Binary data
Re: please update patches / investigate build failures for gcc-4.7 snapshot builds
On 12/18/2011 06:55 PM, Matthias Klose wrote: 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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee8ad5.30...@comcast.net
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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee7d60.9000...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/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-amd64-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
Kurt Roeckx, le Tue 26 Apr 2011 21:28:57 +0200, a écrit : > Is there a reason not to switch the remaining (release) arches > (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? There's no real reason to defer hurd-i386, as it's basically like i386, and the key packages (glibc/hurd/gnumach) already use a fixed version and can be handled independently. Samuel -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426204147.gs4...@const.famille.thibault.fr
Re: GCC-4.5 as the default for (at least some) architectures
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 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. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426192857.ga10...@roeckx.be
Re: GCC-4.5 as the default for (at least some) architectures
Matthias Klose dixit: > 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 Porters side, too. I’m okay with keeping gcc-4.4 for a while (kernel?) and switching to gcc-4.6 directly for m68k. I know I’ll probably have to invest some work into the latter, but considering the kernel problem is almost solved, chances are good. (I do want to bring out a new base emulator image first, though, but then…) bye, //mirabilos -- 13:47⎜ if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: > 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 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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426185104.gb29...@hall.aurel32.net
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis wrote: > On 26 April 2011 18:03, 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. > > Could you include armhf in the list as well? I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package: https://buildd.debian.org/status/package.php?p=vxl but since there is no log I cannot confirm this is the same ICE as on i386/armel thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com
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 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. 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-amd64-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 26 April 2011 18:03, 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. Could you include armhf in the list as well? Thanks Konstantinos -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimddKkTaiy1fyka6zMOj0o1YzBS=a...@mail.gmail.com
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-amd64-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 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? Regards, Adam -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303068791.3489.499.ca...@hathi.jungle.funky-badger.org
Re: GCC-4.5 as the default for (at least some) architectures
> On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose wrote: > > I'll make gcc-4.5 the default for (at least some) architectures within th= > e next > > two weeks before more transitions start. =A0GCC-4.5 is already used as th= > e default > > compiler for almost any other distribution, so there shouldn't be many su= > rprises > > on at least the common architectures. =A0About 50% of the build failures = > exposed > > by GCC-4.5 are fixed [1]. =A0I didn't see issues on amd64 and i386, armel > > (although optimized for a different processor) and powerpc (some object f= > iles > > 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 t= > o ask > > which architectures should do the switch together with the four architect= > ures > > mentioned above, and which not, and which ones should be better delayed, = > or dropped. > > Dave, > > What's your opinion on switching to GCC 4.5 for HPPA? Do it! I have built glibc with it and all my recent kernel have been with 4.5. I'm not aware of any new issues with 4.5 and a number of things are fixed. For kernel builds, the following patch must be included: 2010-12-18 John David Anglin PR target/46915 * config/pa/pa.c (branch_to_delay_slot_p): Use next_active_insn instead of next_real_insn. Search forward checking for both ASM_INPUT and ASM_OPERANDS asms until exit condition is found. (branch_needs_nop_p): Likewise. (use_skip_p): New function. (output_cbranch): Use use_skip_p. (output_bb, output_bvb): Likewise. There are some other bug fixes in 4.6 that might need back porting. We also need this binutils change: 2011-02-18 John David Anglin PR ld/12376 emulparams/hppalinux.sh (DATA_ADDR): Define. (SHLIB_DATA_ADDR): Likewise. This should eliminate cache issues arising from non equivalent aliasing. Hopefully, the above will help resolve some of the build and kernel issues that blocked squeeze. I personally don't know what the critical blockers were. If they involve GCC or binutils, I'm willing to take a look. I'm sure a number of things have been magically fixed by updates to the middle-end. The biggest issue is the callee copies args on HPPA and this differs from most other targets. Regards, Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307013751.74c8c5...@hiauly1.hia.nrc.ca
Re: GCC-4.5 as the default for (at least some) architectures
On Wed, 02 Mar 2011 02:34:01 +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). GCC4.5 still segfault when i try to compile, all previous version work fine (without any kind of warning), maybe my GCC4.5 isn't the right one (4.5.2-4), but i'm not so sure can be deployed as "default" (compiling on i386) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307015837.a9d87800.syt...@sythos.net
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Mar 1, 2011 at 8:34 PM, 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). > > 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. Dave, What's your opinion on switching to GCC 4.5 for HPPA? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinznkgbhpaqc7hd6peyppr8da+1iponh1im6...@mail.gmail.com
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 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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e787c.9090...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 2 March 2011 02:34, Matthias Klose 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. M -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiktn0zoa_hzgciwhkzbup7_ji6pbeji+p4c7...@mail.gmail.com
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 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-amd64-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 2 March 2011 03:34, 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). > > 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? Konstantinos
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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6d9e89.8080...@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-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: installing gcc various versions
Usually the problem is not the compiler, but the link line. Check if the paths are ok, and if the libraries are really there. Also, check if there are static (.a) and shared (.so) libraries on the path. LIBS= -L/opt/acml4.2.0/gfortran64_mp_int64/lib -lacml_mv -lgfortran -lpthread Also, the LIB and the LD_LIBRARY_PATH are a little different: /opt/acml4.2.0/gfortran64_mp_int64/lib /opt/acml4.2.0/gfortran64_mp/lib Is these right? Cheers, Ivan 2009/4/26 Francesco Pietra : > With amd64 lenny I have gcc 4.3.2 > > Because of problems in linking libraries (ACML 4.1.0), is it safe to > install also previous versions of gcc? > > The link is > > LIBS= L/opt/acml4.2.0/gfortran64_mp_int64/lib -lacml_mv -lgfortran -lpthread > > while > > france...@tya64:~$ echo $LD_LIBRARY_PATH > /opt/intel/mkl/10.0.1.014/lib/em64t:/opt/intel/cce/10.1.015/lib:/opt/intel/fce/10.1.015/lib:/usr/local/lib:/opt/acml4.2.0/gfortran64_mp/lib > france...@tya64:~$ > > and the compilation complains "-lacml_mv not found" > > The same compilation had no problems one year ago with amd64 etch; > this is why i am thinking to the version of gcc. > > thanks for suggestions > francesco pietra > > > -- > To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
installing gcc various versions
With amd64 lenny I have gcc 4.3.2 Because of problems in linking libraries (ACML 4.1.0), is it safe to install also previous versions of gcc? The link is LIBS= L/opt/acml4.2.0/gfortran64_mp_int64/lib -lacml_mv -lgfortran -lpthread while france...@tya64:~$ echo $LD_LIBRARY_PATH /opt/intel/mkl/10.0.1.014/lib/em64t:/opt/intel/cce/10.1.015/lib:/opt/intel/fce/10.1.015/lib:/usr/local/lib:/opt/acml4.2.0/gfortran64_mp/lib france...@tya64:~$ and the compilation complains "-lacml_mv not found" The same compilation had no problems one year ago with amd64 etch; this is why i am thinking to the version of gcc. thanks for suggestions francesco pietra -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Problems with gcc
On Thu, Jul 17, 2008 at 11:35:52AM +0200, E. Rens wrote: > I think my gcc problem is partly solved. It seems related to time_t > which doesn't behave on amd64 as on i386 (where it was a double). I > don't know yet how to cope with this but there must be a solution, there > is a lot of concern about time_t and amd64 on the web. If you have a > quick answer to this question too, don't hesitate to talk to me! > > For the installation and removal of gcc-4.3 base I still can't figure > out what to do, but if compilation is possible, I feel less annoyed yet. Well making code 64bit clean takes work in some cases where people made (incorrect) assumptions about types which just happened to work. time_t is __TIME_T_TYPE which is __SLONGWORD_TYPE which is 'long int' which is 32bit on some systems and 64bit on others I believe. As long as the code ALWAYS uses time_t when working on time values, that is no problem. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, Jul 16, 2008 at 11:56:46PM +0200, E. Rens wrote: > When I realized that I couldn't run compiled programs I decided to > remove all the versions of gcc I had (3.4, 4.1, 4.3) to reinstall them > from the mirror (ftp://ftp.fr.debian.org/debian/ lenny main contrib -- > changing it later to the main didn't improve the situation) running > apt-get clean, then: > # sudo apt-get remove gcc-4.3 gcc-4.3-base > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > libgcc1: Depends: gcc-4.3-base (= 4.3.1-2) but it is not going to be > installed > E: Broken packages > > After that,trying to remove libgcc1 (just to see) I got : > > The following packages have unmet dependencies: > libc6: Depends: libgcc1 but it is not going to be installed > E: Broken packages > > I can only reinstall these 2 packages but not remove them. Trying to > remove libc6 (also for testing) brings up an awful list of software, > among them essential ones that wouldn't leave my system usable, but at > least it is removable. libc6, libgcc1 and hence gcc-4.3-base are required packages. You can replace them, but not remove them. Still there may not actually be a problem. You could install the apt-show-versions tool and run it, and see if it lists anything as not uptodate or such, including 'newer than version in archive' which would tend to indicate something from sid or elsewhere. If everything is simply up to date then there is nothing currently incorrect installed, and anything that doesn't work is either a bug or a user error. I can't actually remember what the problem started out as anymore. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
I think my gcc problem is partly solved. It seems related to time_t which doesn't behave on amd64 as on i386 (where it was a double). I don't know yet how to cope with this but there must be a solution, there is a lot of concern about time_t and amd64 on the web. If you have a quick answer to this question too, don't hesitate to talk to me! For the installation and removal of gcc-4.3 base I still can't figure out what to do, but if compilation is possible, I feel less annoyed yet. Thank you again, Emmanuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, 16 Jul 2008 14:53:32 -0400, "Lennart Sorensen" <[EMAIL PROTECTED]> said: > But you had an error saying libgcc1 required a specific gcc-4.3-base > which made it look like it was missing. > > What was the command you ran to get that error then? When I realized that I couldn't run compiled programs I decided to remove all the versions of gcc I had (3.4, 4.1, 4.3) to reinstall them from the mirror (ftp://ftp.fr.debian.org/debian/ lenny main contrib -- changing it later to the main didn't improve the situation) running apt-get clean, then: # sudo apt-get remove gcc-4.3 gcc-4.3-base Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgcc1: Depends: gcc-4.3-base (= 4.3.1-2) but it is not going to be installed E: Broken packages After that,trying to remove libgcc1 (just to see) I got : The following packages have unmet dependencies: libc6: Depends: libgcc1 but it is not going to be installed E: Broken packages I can only reinstall these 2 packages but not remove them. Trying to remove libc6 (also for testing) brings up an awful list of software, among them essential ones that wouldn't leave my system usable, but at least it is removable. > -- > Len Sorensen I think I'm feeling depressed! Emmanuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, Jul 16, 2008 at 07:39:45PM +0200, E. Rens wrote: > right! and my gcc-4.3-base matches libgcc1 > > how could I put my system back in the original state without > reinstalling from scratch? But you had an error saying libgcc1 required a specific gcc-4.3-base which made it look like it was missing. What was the command you ran to get that error then? Of course fi 'apt-get -f install' says nothing is wrong then I guess it is in the correct state as far as lenny is concerned (which doesn't mean lenny isn't potentially broken although it usually isn't). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, 16 Jul 2008 13:17:47 -0400, "Lennart Sorensen" <[EMAIL PROTECTED]> said: > Do apt-get update. > > According to packages.debian.org/gcc-3.4-base the current version in > lenny is in fact 4.3.1-2 so if you don't see that either you are using a > bad mirror, or you didn't run apt-get update recently. > > gcc is not gcc-4.3-base. right! and my gcc-4.3-base matches libgcc1 > Len Sorensen how could I put my system back in the original state without reinstalling from scratch? Emmanuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, Jul 16, 2008 at 05:29:20PM +0200, E. Rens wrote: > On Wed, 16 Jul 2008 10:48:42 -0400, "Lennart Sorensen" > <[EMAIL PROTECTED]> said: > > > Try 'apt-get -f install' that will try to get the packages into a sane > > state again. > > # aget -f install > Reading package lists... Done > Building dependency tree > Reading state information... Done > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > > > > Not sure what you did but you manged to install libgcc1 that requries > > gcc 4.3 but not have gcc-4.3-base installed. So the answer is either > > install gcc-4.3-base or go back to an older libgcc1 that you do have the > > requirements for. > > I first installed etch when I installed the whole system and then > upgraded to lenny. > gcc-4.3-base is installed, but I can't remove it, because of libgcc1: > > ... > The following packages have unmet dependencies: > libgcc1: Depends: gcc-4.3-base (= 4.3.1-2) but it is not going to be > installed > E: Broken packages > > > Be very careful since removing libgcc1 will likely make your system > > unusable so don't do that. Either install an older version (apt-get > > install libgcc1=someversionnumber), or install the required gcc-4.3-base > > package. > > > 'apt-cache show libgcc1 |grep Version' can get you a list of what > > versions you have to choose between. > > # apt-cache show gcc |grep Version > Version: 4:4.3.1-1 > > # apt-cache show libgcc1 |grep Version > Version: 1:4.3.1-2 > > it seems libgcc1 4.3.1-2 doesn't like gcc-base 4.3.1-1, but there is no > way to have these version numbers match. Do apt-get update. According to packages.debian.org/gcc-3.4-base the current version in lenny is in fact 4.3.1-2 so if you don't see that either you are using a bad mirror, or you didn't run apt-get update recently. gcc is not gcc-4.3-base. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, 16 Jul 2008 10:48:42 -0400, "Lennart Sorensen" <[EMAIL PROTECTED]> said: > Try 'apt-get -f install' that will try to get the packages into a sane > state again. # aget -f install Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Not sure what you did but you manged to install libgcc1 that requries > gcc 4.3 but not have gcc-4.3-base installed. So the answer is either > install gcc-4.3-base or go back to an older libgcc1 that you do have the > requirements for. I first installed etch when I installed the whole system and then upgraded to lenny. gcc-4.3-base is installed, but I can't remove it, because of libgcc1: ... The following packages have unmet dependencies: libgcc1: Depends: gcc-4.3-base (= 4.3.1-2) but it is not going to be installed E: Broken packages > Be very careful since removing libgcc1 will likely make your system > unusable so don't do that. Either install an older version (apt-get > install libgcc1=someversionnumber), or install the required gcc-4.3-base > package. > 'apt-cache show libgcc1 |grep Version' can get you a list of what > versions you have to choose between. # apt-cache show gcc |grep Version Version: 4:4.3.1-1 # apt-cache show libgcc1 |grep Version Version: 1:4.3.1-2 it seems libgcc1 4.3.1-2 doesn't like gcc-base 4.3.1-1, but there is no way to have these version numbers match. > -- > Len Sorensen > You can see a little output of my program at http://rafb.net/p/izqIhT10.html where the correct is mixed with unwanted verbose. Many thanks, Emmanuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with gcc
On Wed, Jul 16, 2008 at 04:19:05PM +0200, E. Rens wrote: > Following our discussion in the "EM64T compiling options" thread I tried > to recompile some simple programs with gcc in order to test openmp. > The openmp "hello world" program went very well, however I cant run my > own programs (with or without openmp). The compilation goes without > problem but running the programs output lots of messages like: > > "19201: binding file ./simpleset [0] to /lib/libc.so.6 [0]: normal > symbol `malloc'" or: > " 17186: symbol=fprintf; lookup in file=./simpleset [0]" > > This is followed by the normal output PLUS a segmentation fault. But not > all the time, sometimes the same program (not even recompiled) executes > without any error. > I tried to remove and reinstall all the gcc packages but gcc-base-4.3 > refuses to be removed: > > # sudo apt-get remove gcc-4.3-base > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > Since you only requested a single operation it is extremely likely that > the package is simply not installable and a bug report against > that package should be filed. > The following information may help to resolve the situation: > The following packages have unmet dependencies: > libgcc1: Depends: gcc-4.3-base (= 4.3.1-2) but it is not going to be > installed > E: Broken packages > > I reinstalled it and also glibc, libgcc1, I finally installed gcc-4.2, > but the problem remained, worse with gcc-3.4 whose compilations segfault > immediately. I think I'll make a chroot environment in the future but I > can't let my system in such a state anyway and I really don't know what > to do. Any help highly welcome! Try 'apt-get -f install' that will try to get the packages into a sane state again. Not sure what you did but you manged to install libgcc1 that requries gcc 4.3 but not have gcc-4.3-base installed. So the answer is either install gcc-4.3-base or go back to an older libgcc1 that you do have the requirements for. Be very careful since removing libgcc1 will likely make your system unusable so don't do that. Either install an older version (apt-get install libgcc1=someversionnumber), or install the required gcc-4.3-base package. 'apt-cache show libgcc1 |grep Version' can get you a list of what versions you have to choose between. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with gcc
Following our discussion in the "EM64T compiling options" thread I tried to recompile some simple programs with gcc in order to test openmp. The openmp "hello world" program went very well, however I cant run my own programs (with or without openmp). The compilation goes without problem but running the programs output lots of messages like: "19201: binding file ./simpleset [0] to /lib/libc.so.6 [0]: normal symbol `malloc'" or: " 17186: symbol=fprintf; lookup in file=./simpleset [0]" This is followed by the normal output PLUS a segmentation fault. But not all the time, sometimes the same program (not even recompiled) executes without any error. I tried to remove and reinstall all the gcc packages but gcc-base-4.3 refuses to be removed: # sudo apt-get remove gcc-4.3-base Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: libgcc1: Depends: gcc-4.3-base (= 4.3.1-2) but it is not going to be installed E: Broken packages I reinstalled it and also glibc, libgcc1, I finally installed gcc-4.2, but the problem remained, worse with gcc-3.4 whose compilations segfault immediately. I think I'll make a chroot environment in the future but I can't let my system in such a state anyway and I really don't know what to do. Any help highly welcome! Emmanuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 10:16:27AM +0200, Matthias Klose wrote: > 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. According to Bastian Blank, gcc 4.2 currently produces broken sparc kernel images. Another thing which comes to mind: we have recently announced that sparc32 machines are not going to be supported in lenny. Transition to the new gcc version seems like a perfect time to turn on the ultrasparc specific optimizations in gcc by default. Do you think it is feasible? I currently have no idea what breakage such a change might cause. Best regards, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 11:51:47AM +0200, Mike Hommey wrote:
> On Fri, Jul 20, 2007 at 11:33:01AM +0200, Johannes Berg <[EMAIL PROTECTED]>
> wrote:
> > On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote:
> >
> > > 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.
> >
> > I have objections :)
> > http://bugs.debian.org/433629
> > Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2
> > causes my usbhid to totally not work.
>
> I have another objection. I'd like all mozilla security updates to be built
> before gcc 4.2 becomes the default, because they don't build correctly yet,
> and I am (still) waiting for an upstream comment on how to fix it.
>
On a more general note, I'd like to see xulrunner/nss built and
depending packages[0] built so we can get the fixes into testing easier
before this is started.
Cheers,
Neil
[0] Most of: http://security-tracker.debian.net/tracker/status/dtsa-candidates
--
int getRandomNumber() {
return 4; // chosen by fair dice roll. guaranteed to be random.
}
// http://xkcd.com/c221.html
signature.asc
Description: Digital signature
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 11:33:01AM +0200, Johannes Berg <[EMAIL PROTECTED]> wrote: > On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote: > > > 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. > > I have objections :) > http://bugs.debian.org/433629 > Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2 > causes my usbhid to totally not work. I have another objection. I'd like all mozilla security updates to be built before gcc 4.2 becomes the default, because they don't build correctly yet, and I am (still) waiting for an upstream comment on how to fix it. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote: > 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. I have objections :) http://bugs.debian.org/433629 Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2 causes my usbhid to totally not work. johannes signature.asc Description: This is a digitally signed message part
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]
Re: gcc-4.1
Hi Rob And thanks for the answer. > >Has anyone noticed that gcc is older in experimental for amd64 than > > for other architectures. It seems to me like dependencies that go in > > circles. If so, does anyone have an explanation? I wanted to compile the > > newest version of openoffice but I need this version of gcc for that. > > The packages in experimental don't seem to build for all architectures - > another example is gnome-applets, which has been built for i386 only. > > Sometimes it is because of failure to build on that architecture. Sometimes > it just doesn't build. > > Look at the per-package build logs at buildd.debian.org for more > information. I can in fact wait a bit for the gcc but the page you pointed out is interesting and I should have known. But I could not find the experimental build logs in there. I play with compiling openoffice myself because I sometimes have to wait months for the official amd64 debian compiler to do it (I'm not complaining, thanks for the job you do if you read it :) and I want to have the newest version to check its compatibility with MS-Word myself. Regards Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.1
On 01-Apr-2007 20:52.50 (BST), Gudjon I. Gudjonsson wrote: >Has anyone noticed that gcc is older in experimental for amd64 than for > other architectures. It seems to me like dependencies that go in circles. >If so, does anyone have an explanation? I wanted to compile the newest > version of openoffice but I need this version of gcc for that. The packages in experimental don't seem to build for all architectures - another example is gnome-applets, which has been built for i386 only. Sometimes it is because of failure to build on that architecture. Sometimes it just doesn't build. Look at the per-package build logs at buildd.debian.org for more information. -- rob andrews :: pgp 0x01e00563 :: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.1
On Sun, Apr 01, 2007 at 09:52:50PM +0200, Gudjon I. Gudjonsson wrote: > Hi >Has anyone noticed that gcc is older in experimental for amd64 than for > other architectures. It seems to me like dependencies that go in circles. >If so, does anyone have an explanation? I wanted to compile the newest > version of openoffice but I need this version of gcc for that. gcc-4.1 is in testing and unstable for quite a while, and is the default compiler for testing/etch. openoffice.org is also available in testing/etch, and I have no idea why it would suddenly require a newer gcc. I have no idea why you have a problem with this. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-4.1
Hi Has anyone noticed that gcc is older in experimental for amd64 than for other architectures. It seems to me like dependencies that go in circles. If so, does anyone have an explanation? I wanted to compile the newest version of openoffice but I need this version of gcc for that. Regards Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.0
c wakefield <[EMAIL PROTECTED]> writes: > On Monday 29 January 2007 00:59, Goswin von Brederlow wrote: >> c wakefield <[EMAIL PROTECTED]> writes: >> > Greetings all. >> > >> > Can someone point me to an amd64 deb of gcc-4.0? >> > >> > It's not in the standard repository, at least, the binary isn't. >> > >> > I'm compiling the nvidia module on a 2.6.15-1 kernel which requires gcc >> > 4.0 >> > >> > Thanks for any replies. >> > Chris W. >> > >> > >> > -- >> > To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> > with a subject of "unsubscribe". Trouble? Contact >> > [EMAIL PROTECTED] >> >> You could go and find it on snapshots but might i suggest to build a >> new kernel with whatever compiler you have now? Prefreably a recent >> one. >> >> MfG >> Goswin > Hi Goswin. Thanks, but I did find the compiler on an old install. I have to > use the 2.6.15-1 deb kernel, as nothing else will boot my asus m2nvp-vm board > for some reason (I think it's the lack of support for the NFORCE-MCP51 > chipset). If you can you should do a git-bisect to find the patch that breaks it and then work on getting it fixed again for current kernels. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.0
On Monday 29 January 2007 00:59, Goswin von Brederlow wrote: > c wakefield <[EMAIL PROTECTED]> writes: > > Greetings all. > > > > Can someone point me to an amd64 deb of gcc-4.0? > > > > It's not in the standard repository, at least, the binary isn't. > > > > I'm compiling the nvidia module on a 2.6.15-1 kernel which requires gcc > > 4.0 > > > > Thanks for any replies. > > Chris W. > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > You could go and find it on snapshots but might i suggest to build a > new kernel with whatever compiler you have now? Prefreably a recent > one. > > MfG > Goswin Hi Goswin. Thanks, but I did find the compiler on an old install. I have to use the 2.6.15-1 deb kernel, as nothing else will boot my asus m2nvp-vm board for some reason (I think it's the lack of support for the NFORCE-MCP51 chipset). Chris W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.0
c wakefield <[EMAIL PROTECTED]> writes: > Greetings all. > > Can someone point me to an amd64 deb of gcc-4.0? > > It's not in the standard repository, at least, the binary isn't. > > I'm compiling the nvidia module on a 2.6.15-1 kernel which requires gcc 4.0 > > Thanks for any replies. > Chris W. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] You could go and find it on snapshots but might i suggest to build a new kernel with whatever compiler you have now? Prefreably a recent one. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.0
On Sunday 28 January 2007 21:37, Alan Ianson wrote: > On Sun January 28 2007 21:03, c wakefield wrote: > > Greetings all. > > > > Can someone point me to an amd64 deb of gcc-4.0? > > > > It's not in the standard repository, at least, the binary isn't. > > > > I'm compiling the nvidia module on a 2.6.15-1 kernel which requires gcc > > 4.0 > > I use the nvidia binaries from non-free in etch and they work well for me. > If your running sarge 3.4 will be the newest (official) gcc available. I > had to install that so m-a could built the module for me. > > Do you need a newer driver than m-a will build for you? Hi Alan. I've heard about problems associated the nvidia binaries, leaving the user without X and a hosed system. I think that was the fault of the nVidia installer, though. I'm running testing and was wanting to compile a module against my [only] running kernel: 2.6.15-1-amd64-generic. module-assistant says that I need gcc-4.0 to compile the nvidia source against this kernel. I'm running a asus M2NPV-VM motherboard which has an NFORCE-MCP51 chipset that is not supported yet, and the 2.6.15-1-amd64-generic debian kernel is the only one that boots this machine. Tried 2.6.19.2 of course. What binaries/amd64 packages are you using? Thanks, Chris W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.0
On Sun January 28 2007 21:03, c wakefield wrote: > Greetings all. > > Can someone point me to an amd64 deb of gcc-4.0? > > It's not in the standard repository, at least, the binary isn't. > > I'm compiling the nvidia module on a 2.6.15-1 kernel which requires gcc 4.0 I use the nvidia binaries from non-free in etch and they work well for me. If your running sarge 3.4 will be the newest (official) gcc available. I had to install that so m-a could built the module for me. Do you need a newer driver than m-a will build for you? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-4.0
Greetings all. Can someone point me to an amd64 deb of gcc-4.0? It's not in the standard repository, at least, the binary isn't. I'm compiling the nvidia module on a 2.6.15-1 kernel which requires gcc 4.0 Thanks for any replies. Chris W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating gcc
On Wed, Nov 15, 2006 at 01:33:50AM +0100, sigi wrote: > 1. cd /usr/bin > 2. rm gcc > 3. ln -s gcc-3.4 gcc > > and it will use gcc-3.4 from now on Making a temporary change using the CC enviroment variable is a much better idea. Sarge is meant to be using gcc 3.4, and changing that may cause problems. Of course if you almost never compile anything, you may not care. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating gcc
On Tue, Nov 14, 2006 at 07:58:52PM -0300, Federico Izuel wrote: > Hi, I have a problem and I wonder if you could help me. I have GNU/Liunux > Debian Sarge Amd64, and I'm trying to install a wireless drivers, but as I > have > gcc 3.3 and kernel is compiled with gcc 3.4, when I complill the driver I > can't > load it, so I need to upgrade gcc to 3.4 version, but I couldn't... I try with > apt-get, and I thing gcc 3.4 is now installed, but when I use "make" it still > using gcc 3.3.5 > How can I fix it?? 1. cd /usr/bin 2. rm gcc 3. ln -s gcc-3.4 gcc and it will use gcc-3.4 from now on sigi. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating gcc
On 11/15/06, Federico Izuel <[EMAIL PROTECTED]> wrote: Hi, I have a problem and I wonder if you could help me. I have GNU/Liunux Debian Sarge Amd64, and I'm trying to install a wireless drivers, but as I have gcc 3.3 and kernel is compiled with gcc 3.4, when I complill the driver I can't load it, so I need to upgrade gcc to 3.4 version, but I couldn't... I try with apt-get, and I thing gcc 3.4 is now installed, but when I use "make" it still using gcc 3.3.5 How can I fix it?? CC=gcc-3.4 make-kpkg -- Paolo Alexis Falcone [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Updating gcc
Hi, I have a problem and I wonder if you could help me. I have GNU/Liunux Debian Sarge Amd64, and I'm trying to install a wireless drivers, but as I have gcc 3.3 and kernel is compiled with gcc 3.4, when I complill the driver I can't load it, so I need to upgrade gcc to 3.4 version, but I couldn't... I try with apt-get, and I thing gcc 3.4 is now installed, but when I use "make" it still using gcc 3.3.5How can I fix it??THanksFederico Izuel
mixing Fortran (77) and C code with gcc-gfortran 4.1 on amd64?
Hello, this is probably offtopic, so feel free to answer off the list, if you prefer. Some time ago, I wrote a piece of software which mixed C and Fortran 77. This was relatively clean and somewhat portable, since I included f2c.h to get the type definitions to coincide between C and F77 in function calls. Now I would like to use gfortran and gcc 4.1, but it looks like gfortran uses a different ABI to interface with subroutines. Is there a (somewhat) clean and portable way to call C functions from F77 and vice versa, using gfortran and gcc 4.1? I would be happy to Read The Fine Manual on this topic, but it seems this section (which was present in the info documentation of good ol' gcc/g77 3.4) apparently is nowhere to be found in the documentation to gcc/gfortran 4.1... (please correct me if I'm wrong) Any clue? Thanks Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
As to packages available from another distribution, I forgot to tell the whole
instructions I was given:
Looks like there is a debian mpqc package. See
http://packages.debian.org/unstable/science/mpqc
You should be able to do an 'apt-get mpqc' and it will install mpqc,
along with any missing packages that mpqc depends on.
Does this fit with your suggestion below? I wonder about those and where to address that apt-get, and why does not
precede the name of the package.
thank you
francesco pietra
On Thursday 08 June 2006 18:14, A J Stiles wrote:
> On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> > Finally, I issued #make (from root) and then changed the ownership of all
> > *.c, *.o, *.h, and *.prm files, including the directory containing them.
> > It works perfectly at truly 64bit (of course it has no graphics, to this
> > end, but on the 32bit pc I have a sister program to examine graphically
> > the output). Impressive speed. The most tricky part is to create the
> > input on the 32bit pc and transfer to the 64bit workstation through a usb
> > card reader, complex because of the strict adherence of debian to
> > ownerships and permissions.
>
> Is there a good reason why you can't set up an NFS share between the two
> machines?
Really not. I am just at the beginning, with recoursing problems. NFS will be
the solution. And may be even vetter to create a 32bit chroot to run there my
pre-program. It may be useful in case of pc32 down. I never created a chroot
and take into account that I am a chemist (one of the very few scientists in
my country who does not know about Microsoft), I have to do chemistry. Time
is short.
I am experiencing unusual difficulties with these particular file transfers
from the 64bit side. Root is not allowed to transfer with preservation of
properties of output files (may be I am using wrong commands, however) and
files on the card reader refuse to be changed of ownership (here I am sure to
use the right commands). Moreover, umount does not work and occupancy pid is
both to user (why, he was only involved in the property of output files) and
root, and a simple kill pid does not work, I had to make recourse to the
dangerous kill -kill pid (always, not only once). In contrast, everything
flows smoothly with the same card and same file on the 32bit pc (either from
terminal window or kde). On the 64bit machine I had even a suggestion to
report a bug about malfunction of -p --preserve. Unfortunately I did nothing
and I did not take notice.
> > > If `make install` is not working,
> >
> > There is no makeinstall in the Makefile. Things are arranged that make
> > creates the executable that can be placed everywhere (with its needed
> > companions)
>
> Ah. Well, this is the sort of thing I should have expected from a
> programmer who is still using gets() . ;-)
I would be more cautious about that. That person was able to transfer
computational programs from mainframe to the first IBM PC (and I was using
them from the beginning), and he wrote ones that still have no equivalent on
earth. But I understand, he do not know him.
>
> > I believe you have grasped the point [about user #500] perfectly. Who
> > wrote
>
> the program is a
>
> > RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> > that, on my solicitation, he has installed debian too, but he was
> > probably pressed by the time. I was looking at 500: is that the decimal
> > corresponding to octal 764?
>
> 7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
>
> > At any event, I am happy to have the first important piece for my
> > calculations at 64bit with multiprocessor. Now I have to check if the
> > program is bug-free. A molecule of my repertoire will test that fully.
> >
> > Could you please help me further? I posed to the mpqc list the question
> > (unanswered) if it is safe to install on amd64 debian etch mpqc (the
> > second part of my calculations) made available for debian sid at
> >
> > http://packages.debian.org/unstable/science/mpqc
> >
> > What do you think? If safe, should I add a repository to my sources.list
> > for etch or there is another less risky way?
>
> What I've mostly done in the past, when wanting packages not available in
> the distribution I am using {e.g. my 32-bit Etch at home, when some KDE
> packages were unavailable}, has been to download the .dsc, .diff.gz and
> .orig.tar.gz files by hand, build the package:
> # dpkg-source -x foo.dsc
> # cd foo
> # dpkg-buildpackage
> and install the resulting .deb using
> # dpkg -i foo.deb
>
> Unstable {sid} packages generally will build fine on testing {etch at
> time of writing} except when a huge transition is taking place {eg. KDE2
> to KDE3, XFree86 to Xorg} and a dependency hasn't made it through the
> system yet. Depending upon how actively mpqc is being developed, you may
> even find that the Etch and Sid versions are the same.
>
> Good luck with it!
>
Thanks a lot
> --
> AJS
> de
Re: gcc
On Thursday 08 June 2006 18:14, A J Stiles wrote:
> On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> > Finally, I issued #make (from root) and then changed the ownership of all
> > *.c, *.o, *.h, and *.prm files, including the directory containing them.
> > It works perfectly at truly 64bit (of course it has no graphics, to this
> > end, but on the 32bit pc I have a sister program to examine graphically
> > the output). Impressive speed. The most tricky part is to create the
> > input on the 32bit pc and transfer to the 64bit workstation through a usb
> > card reader, complex because of the strict adherence of debian to
> > ownerships and permissions.
>
> Is there a good reason why you can't set up an NFS share between the two
> machines?
Really not. I am just at the beginning, with recoursing problems. NFS will be
the solution. And may be even vetter to create a 32bit chroot to run there my
pre-program. It may be useful in case of pc32 down. I never created a chroot
and take into account that I am a chemist (one of the very few scientists in
my country who does not know about Microsoft), I have to do chemistry. Time
is short.
I am experiencing unusual difficulties with these particular file transfers
from the 64bit side. Root is not allowed to transfer with preservation of
properties of output files (may be I am using wrong commands, however) and
files on the card reader refuse to be changed of ownership (here I am sure to
use the right commands). Moreover, umount does not work and occupancy pid is
both to user (why, he was only involved in the property of output files) and
root, and a simple kill pid does not work, I had to make recourse to the
dangerous kill -kill pid (always, not only once). In contrast, everything
flows smoothly with the same card and same file on the 32bit pc (either from
terminal window or kde). On the 64bit machine I had even a suggestion to
report a bug about malfunction of -p --preserve. Unfortunately I did nothing
and I did not take notice.
> > > If `make install` is not working,
> >
> > There is no makeinstall in the Makefile. Things are arranged that make
> > creates the executable that can be placed everywhere (with its needed
> > companions)
>
> Ah. Well, this is the sort of thing I should have expected from a
> programmer who is still using gets() . ;-)
I would be more cautious about that. That person was able to transfer
computational programs from mainframe to the first IBM PC (and I was using
them from the beginning), and he wrote ones that still have no equivalent on
earth. But I understand, he do not know him.
>
> > I believe you have grasped the point [about user #500] perfectly. Who
> > wrote
>
> the program is a
>
> > RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> > that, on my solicitation, he has installed debian too, but he was
> > probably pressed by the time. I was looking at 500: is that the decimal
> > corresponding to octal 764?
>
> 7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
>
> > At any event, I am happy to have the first important piece for my
> > calculations at 64bit with multiprocessor. Now I have to check if the
> > program is bug-free. A molecule of my repertoire will test that fully.
> >
> > Could you please help me further? I posed to the mpqc list the question
> > (unanswered) if it is safe to install on amd64 debian etch mpqc (the
> > second part of my calculations) made available for debian sid at
> >
> > http://packages.debian.org/unstable/science/mpqc
> >
> > What do you think? If safe, should I add a repository to my sources.list
> > for etch or there is another less risky way?
>
> What I've mostly done in the past, when wanting packages not available in
> the distribution I am using {e.g. my 32-bit Etch at home, when some KDE
> packages were unavailable}, has been to download the .dsc, .diff.gz and
> .orig.tar.gz files by hand, build the package:
> # dpkg-source -x foo.dsc
> # cd foo
> # dpkg-buildpackage
> and install the resulting .deb using
> # dpkg -i foo.deb
>
> Unstable {sid} packages generally will build fine on testing {etch at
> time of writing} except when a huge transition is taking place {eg. KDE2
> to KDE3, XFree86 to Xorg} and a dependency hasn't made it through the
> system yet. Depending upon how actively mpqc is being developed, you may
> even find that the Etch and Sid versions are the same.
>
> Good luck with it!
>
Thanks a lot
> --
> AJS
> delta echo bravo six four at earthshod dot co dot uk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> Finally, I issued #make (from root) and then changed the ownership of all
> *.c, *.o, *.h, and *.prm files, including the directory containing them. It
> works perfectly at truly 64bit (of course it has no graphics, to this end,
> but on the 32bit pc I have a sister program to examine graphically the
> output). Impressive speed. The most tricky part is to create the input on
> the 32bit pc and transfer to the 64bit workstation through a usb card
> reader, complex because of the strict adherence of debian to ownerships and
> permissions.
Is there a good reason why you can't set up an NFS share between the two
machines?
> > If `make install` is not working,
>
> There is no makeinstall in the Makefile. Things are arranged that make
> creates the executable that can be placed everywhere (with its needed
> companions)
Ah. Well, this is the sort of thing I should have expected from a programmer
who is still using gets() . ;-)
> I believe you have grasped the point [about user #500] perfectly. Who wrote
the program is a
> RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> that, on my solicitation, he has installed debian too, but he was probably
> pressed by the time. I was looking at 500: is that the decimal
> corresponding to octal 764?
7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
> At any event, I am happy to have the first important piece for my
> calculations at 64bit with multiprocessor. Now I have to check if the
> program is bug-free. A molecule of my repertoire will test that fully.
>
> Could you please help me further? I posed to the mpqc list the question
> (unanswered) if it is safe to install on amd64 debian etch mpqc (the second
> part of my calculations) made available for debian sid at
>
> http://packages.debian.org/unstable/science/mpqc
>
> What do you think? If safe, should I add a repository to my sources.list
> for etch or there is another less risky way?
What I've mostly done in the past, when wanting packages not available in the
distribution I am using {e.g. my 32-bit Etch at home, when some KDE
packages were unavailable}, has been to download the .dsc, .diff.gz
and .orig.tar.gz files by hand, build the package:
# dpkg-source -x foo.dsc
# cd foo
# dpkg-buildpackage
and install the resulting .deb using
# dpkg -i foo.deb
Unstable {sid} packages generally will build fine on testing {etch at time
of writing} except when a huge transition is taking place {eg. KDE2 to
KDE3, XFree86 to Xorg} and a dependency hasn't made it through the system
yet. Depending upon how actively mpqc is being developed, you may even find
that the Etch and Sid versions are the same.
Good luck with it!
--
AJS
delta echo bravo six four at earthshod dot co dot uk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Thursday 08 June 2006 11:35, Adam Stiles wrote:
> On Wednesday 07 June 2006 20:06, Francesco Pietra wrote:
> > Yes, it was compiled OK. However, because make was from root, the
> > property of all compiled *.o files is root root. This makes some problems
> > in the use of the program, such as in deleting files.
> > Issuing
> >
> > ln -s /usr/bin/gcc-41 /usr/local/bin/gcc
> >
> > either as $ or #, followed by
> >
> > $ make
> >
> > reports
> > gcc -g -02 -c -o active.o active.c
> > cc1: error: active.c: Permission denied
> > make: *** [active.o] Error 1
> >
> > Perhaps, unless link/make can be arranged differently, the easiest would
> > be to change the property of all *.o files. Don'y remember how this could
> > be done with a single command.
>
> When you do
> # make install
> all the important files are copied somewhere sensible, usually
> /usr/local/bin which is in the standard path and out of reach of the
> package management system. You have to be root to do this, because
> ordinary users really should not be writing to such places.
>
Finally, I issued #make (from root) and then changed the ownership of all *.c,
*.o, *.h, and *.prm files, including the directory containing them. It works
perfectly at truly 64bit (of course it has no graphics, to this end, but on
the 32bit pc I have a sister program to examine graphically the output).
Impressive speed. The most tricky part is to create the input on the 32bit pc
and transfer to the 64bit workstation through a usb card reader, complex
because of the strict adherence of debian to ownerships and permissions.
> >
> If `make install` is not working,
There is no makeinstall in the Makefile. Things are arranged that make creates
the executable that can be placed everywhere (with its needed companions)
> then that indicates an error {as opposed
> to a warning; errors are serious enough actually to stop the compilation}
> somewhere. So you probably want to capture the full output to analyse at
> your leisure. Type
> $ script [filename]
> to begin capturing the terminal output into a file {if you don't give a
> filename the default will be 'typescript'}; then
> $ make
> to start the make process. Press ctrl+D at the end, to stop writing to the
> script file and save it.
>
> Now you can look through the file with an editor and see where the error
> occurred.
>
> > Incidentally, in previous compilation the proprty of *.c files was
> > francesco francesco. Now it is 500 500; I imagine that 500 stands for
> > francesco. True? You know, when such affaris are carried out
> > sporadically, memory about tends to vanish to make room to other storage.
>
> Unix stores the users and groups associated with files numerically, and
> looks them up for display. It's conventional that the low numbers are used
> for system users and "artificial" users, and higher numbers are the "real"
> users. On Red Hat systems and derivatives, non-system users start at 500;
> on Debian systems, non-system users start at 1000.
>
> What probably happened is that someone generated the tarball as the first
> non-system user on a Red Hat-ish system, who would have been numbered 500.
> One of the times that you extracted it, you took over ownership of the
> files; the other time, you preserved the original file ownerships {perhaps
> you extracted it as root or something}. Your Debian system doesn't have a
> user #500, so it can't give you a username.
I believe you have grasped the point perfectly. Who wrote the program is a
RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
that, on my solicitation, he has installed debian too, but he was probably
pressed by the time. I was looking at 500: is that the decimal corresponding
to octal 764?
>
> Not that it matters much because only root can do `make install`, and root
> can always read files belonging to anyone regardless of permission modes.
At any event, I am happy to have the first important piece for my calculations
at 64bit with multiprocessor. Now I have to check if the program is bug-free.
A molecule of my repertoire will test that fully.
Could you please help me further? I posed to the mpqc list the question
(unanswered) if it is safe to install on amd64 debian etch mpqc (the second
part of my calculations) made available for debian sid at
http://packages.debian.org/unstable/science/mpqc
What do you think? If safe, should I add a repository to my sources.list for
etch or there is another less risky way?
Thanks a lot
francesco pietra
>
> --
> AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Wednesday 07 June 2006 20:06, Francesco Pietra wrote:
> Yes, it was compiled OK. However, because make was from root, the property
> of all compiled *.o files is root root. This makes some problems in the use
> of the program, such as in deleting files.
>
> Issuing
>
> ln -s /usr/bin/gcc-41 /usr/local/bin/gcc
>
> either as $ or #, followed by
>
> $ make
>
> reports
> gcc -g -02 -c -o active.o active.c
> cc1: error: active.c: Permission denied
> make: *** [active.o] Error 1
>
> Perhaps, unless link/make can be arranged differently, the easiest would be
> to change the property of all *.o files. Don'y remember how this could be
> done with a single command.
When you do
# make install
all the important files are copied somewhere sensible, usually /usr/local/bin
which is in the standard path and out of reach of the package management
system. You have to be root to do this, because ordinary users really should
not be writing to such places.
If `make install` is not working, then that indicates an error {as opposed to
a warning; errors are serious enough actually to stop the compilation}
somewhere. So you probably want to capture the full output to analyse at
your leisure. Type
$ script [filename]
to begin capturing the terminal output into a file {if you don't give a
filename the default will be 'typescript'}; then
$ make
to start the make process. Press ctrl+D at the end, to stop writing to the
script file and save it.
Now you can look through the file with an editor and see where the error
occurred.
> Incidentally, in previous compilation the proprty of *.c files was
> francesco francesco. Now it is 500 500; I imagine that 500 stands for
> francesco. True? You know, when such affaris are carried out sporadically,
> memory about tends to vanish to make room to other storage.
Unix stores the users and groups associated with files numerically, and looks
them up for display. It's conventional that the low numbers are used for
system users and "artificial" users, and higher numbers are the "real" users.
On Red Hat systems and derivatives, non-system users start at 500; on Debian
systems, non-system users start at 1000.
What probably happened is that someone generated the tarball as the first
non-system user on a Red Hat-ish system, who would have been numbered 500.
One of the times that you extracted it, you took over ownership of the files;
the other time, you preserved the original file ownerships {perhaps you
extracted it as root or something}. Your Debian system doesn't have a user
#500, so it can't give you a username.
Not that it matters much because only root can do `make install`, and root can
always read files belonging to anyone regardless of permission modes.
--
AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Yes, it was compiled OK. However, because make was from root, the property of all compiled *.o files is root root. This makes some problems in the use of the program, such as in deleting files. Issuing ln -s /usr/bin/gcc-41 /usr/local/bin/gcc either as $ or #, followed by $ make reports gcc -g -02 -c -o active.o active.c cc1: error: active.c: Permission denied make: *** [active.o] Error 1 Perhaps, unless link/make can be arranged differently, the easiest would be to change the property of all *.o files. Don'y remember how this could be done with a single command. Incidentally, in previous compilation the proprty of *.c files was francesco francesco. Now it is 500 500; I imagine that 500 stands for francesco. True? You know, when such affaris are carried out sporadically, memory about tends to vanish to make room to other storage. francesco pietra Therefore, I have recreated directory gmmx with sources (I had deleted all) and recompiled issuing both links and make as root. Now the *. files are 500 500 property (I imagine it is for owner francesco) while *.o files are root root. Why not changing the property? I was too tired yesterday. Now tried. Perhaps mistakenly, I issued the ln -s from my home, then cd to the directory containing the sources, from where i issued make: deb64:/home/francesco# ln - /usr/bin/gcc-4.1 /usr/local/bin/gcc cd gmmx deb64:/home/francesco/gmmx# make whereby a large number of lines where shown consecutively, of the type gcc -g -02 -c -o utility.o utility.c where utility.c is a file owned francesco francesco (date when the tarball was unzipped and untared), present before make, and utility.o, owned root root (date when make was issued), was generated following the command. the sequence ended with: gcc -g -o gmmx03 active.o angles.o attach.o column.o dolastat.o diagc.o Then, after other lines of text main.o: In function 'main': /home/francesco/gmmx/main.c: 71: warning: the 'gets' function is dangerous and should not be used. deb64: /home/francesco/gmmx# where is the name of the tarball. I do not yet understand if something positive happened, but surely your suggestion has broken the ice. Thank you. (should you understand from the above description, please tell me) francesco pietra On Wednesday 07 June 2006 15:57, Matthias Julius wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > On Wednesday 07 June 2006 00:05, Matthias Julius wrote: > >> # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc > > And did you try to create a gcc symlink? > > Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
> > $alias gcc="gcc-4.1" make > > -bash: alias: make: not found [...] > I think that should have been: > # alias gcc="gcc-4.1" > # make Make doesn't use bash aliases. An exported environment variable might do it, but I believe this is the standard way to do this: make CC=gcc-4.1 HTH, --Pete -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Francesco Pietra wrote: Resent to say that before #make install I should delete the directory, recreate, and issue make from $. I am only worried about the warning below. Was that because I issued make from root? No. It's programmer error in main.c, line 71. Use fgets() instead of gets() as gets() is easy to exploit with buffer overrun attacks. Generally, read "man gets" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Resent to say that before #make install (or better #checkinstall -D) I should delete the directory, recreate, and issue make from $. I am only worried about the warning below. Was that because I issued make from root? ___ I was too tired yesterday. Now tried. Perhaps mistakenly, I issued the ln -s from my home, then cd to the directory containing the sources, from where i issued make: deb64:/home/francesco# ln - /usr/bin/gcc-4.1 /usr/local/bin/gcc cd gmmx deb64:/home/francesco/gmmx# make whereby a large number of lines where shown consecutively, of the type gcc -g -02 -c -o utility.o utility.c where utility.c is a file owned francesco francesco (date when the tarball was unzipped and untared), present before make, and utility.o, owned root root (date when make was issued), was generated following the command. the sequence ended with: gcc -g -o gmmx03 active.o angles.o attach.o column.o dolastat.o diagc.o Then, after other lines of text main.o: In function 'main': /home/francesco/gmmx/main.c: 71: warning: the 'gets' function is dangerous and should not be used. deb64: /home/francesco/gmmx# where is the name of the tarball. I do not yet understand if something positive happened, but surely your suggestion has broken the ice. Thank you. (should you understand from the above description, please tell me) francesco pietra On Wednesday 07 June 2006 15:57, Matthias Julius wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > On Wednesday 07 June 2006 00:05, Matthias Julius wrote: > >> # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc > > And did you try to create a gcc symlink? > > Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Resent to say that before #make install I should delete the directory, recreate, and issue make from $. I am only worried about the warning below. Was that because I issued make from root? ___ I was too tired yesterday. Now tried. Perhaps mistakenly, I issued the ln -s from my home, then cd to the directory containing the sources, from where i issued make: deb64:/home/francesco# ln - /usr/bin/gcc-4.1 /usr/local/bin/gcc cd gmmx deb64:/home/francesco/gmmx# make whereby a large number of lines where shown consecutively, of the type gcc -g -02 -c -o utility.o utility.c where utility.c is a file owned francesco francesco (date when the tarball was unzipped and untared), present before make, and utility.o, owned root root (date when make was issued), was generated following the command. the sequence ended with: gcc -g -o gmmx03 active.o angles.o attach.o column.o dolastat.o diagc.o Then, after other lines of text main.o: In function 'main': /home/francesco/gmmx/main.c: 71: warning: the 'gets' function is dangerous and should not be used. deb64: /home/francesco/gmmx# where is the name of the tarball. I do not yet understand if something positive happened, but surely your suggestion has broken the ice. Thank you. (should you understand from the above description, please tell me) francesco pietra On Wednesday 07 June 2006 15:57, Matthias Julius wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > On Wednesday 07 June 2006 00:05, Matthias Julius wrote: > >> # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc > > And did you try to create a gcc symlink? > > Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
I was too tired yesterday. Now tried. Perhaps mistakenly, I issued the ln -s from my home, then cd to the directory containing the sources, from where i issued make: deb64:/home/francesco# ln - /usr/bin/gcc-4.1 /usr/local/bin/gcc cd gmmx deb64:/home/francesco/gmmx# make whereby a large number of lines where shown consecutively, of the type gcc -g -02 -c -o utility.o utility.c where utility.c is a file owned francesco francesco (date when the tarball was unzipped and untared), present before make, and utility.o, owned root root (date when make was issued), was generated following the command. the sequence ended with: gcc -g -o gmmx03 active.o angles.o attach.o column.o dolastat.o diagc.o Then, after other lines of text main.o: In function 'main': /home/francesco/gmmx/main.c: 71: warning: the 'gets' function is dangerous and should not be used. deb64: /home/francesco/gmmx# where is the name of the tarball. I do not yet understand if something positive happened, but surely your suggestion has broken the ice. Thank you. (should you understand from the above description, please tell me) francesco pietra On Wednesday 07 June 2006 15:57, Matthias Julius wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > On Wednesday 07 June 2006 00:05, Matthias Julius wrote: > >> # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc > > And did you try to create a gcc symlink? > > Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Francesco Pietra <[EMAIL PROTECTED]> writes: > On Wednesday 07 June 2006 00:05, Matthias Julius wrote: >> # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc And did you try to create a gcc symlink? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Francesco Pietra wrote: On Tuesday 06 June 2006 23:24, Alexander Samad wrote: On Tue, Jun 06, 2006 at 08:11:01PM +0200, Francesco Pietra wrote: #apt-get install gcc-4.0 Reading.. Building dependency tree... Package 4.0 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source. However the following packages replace it: gcc-4.0-locales W. (a series of warnings that Couldn't stat source package list at http:... E: Package gcc-4.0 has no installation candidate. My sources.list from which the net installation was carried out with only main and the row end (subsequently, apt-get update did nothing): deb http://debian.inode.at/debian-amd64/debian/ etch main contrib non-free deb-src http://debian.inode.at/debian-amd64/debian/ etch main contrib non-free Think you have to change your repository to the main debain ones, as etch has been moved to there something like ftp://ftp.au.debian.org/debian etch main contrib non-free Now tried: #apt-get update (or upgrade) with sources.list deb ftp://ftp.au.debian.org/debian etch main contrib non-free deb-src ftp://ftp.au.debian.org/debian etch main contrib non-free deb http://security.debian.org/ etch/updates main contrib non-free deb-src http://security.debian.org/ etch/updates main contrib non-free fails to give access to either sources or security updates and no update/upgrade occurs at all Then also tried: #apt-get update (or upgrade) with sources.list deb ftp://ftp.debian.org/debian etch main contrib non-free deb-src ftp://ftp.debian.org/debian etch main contrib non-free deb http://security.debian.org/ etch/updates main contrib non-free deb-src http://security.debian.org/ etch/updates main contrib non-free fails to give access to either sources or security updates and no update/upgrade occurs at all (installation was from etch beta 2 release installer; netinstall from debian.inode.at) TO ADD that with either 'au' or without in the sources.list, the result of gcc trial install is the same as with debian.inode.at, i.e.: #apt-get install gcc-4.0 Reading.. Building dependency tree... Package 4.0 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source. However the following packages replace it: gcc-4.0-locales W. (a series of warnings that Couldn't stat source package list at http:... E: Package gcc-4.0 has no installation candidate. Have you done "apt-get update"??? Albert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Tuesday 06 June 2006 06:15 pm, Francesco Pietra wrote: > On Tuesday 06 June 2006 23:24, Alexander Samad wrote: > > On Tue, Jun 06, 2006 at 08:11:01PM +0200, Francesco Pietra wrote: > > > On Tuesday 06 June 2006 20:13, Lennart Sorensen wrote: > > > > On Tue, Jun 06, 2006 at 04:38:20PM +0200, Francesco Pietra wrote: > > > > > Hi Matthew: > > > > > Thank you. However: > > > > > > > > > > $alias gcc="gcc-4.1" make > > > > > -bash: alias: make: not found > > > > > > > > > > $man alias > > > > > No manual entry for alias > > > > > > > > > > I am making a cup of doubly strong green tea > > > > > > > > I think that should have been: > > > > # alias gcc="gcc-4.1" > > > > # make > > > > > > Retrying as you suggest as root, the first command returns the root > > > prompt #make > > > gcc - g -02 -c -o active.o active.c > > > make: gcc: Command not found > > > make: *** [active.o] Error 127 > > > that is, as if the alis was not activated. > > > > > > > Not sure make can use shell aliases though. > > > > > > > > So your real problem is that gcc-4.0 which gcc depends on is not > > > > currently installable for some reason on your system. > > > > > > Just to detail what errors: > > > #apt-get install gcc > > > gcc: Depends: gcc-4.0 (>=4.0.2-5) but it is not installable. > > > E: Broken packages. > > > > > > > What output/errors do you get from: > > > > apt-get install gcc-4.0 > > > > > > #apt-get install gcc-4.0 > > > Reading.. > > > Building dependency tree... > > > Package 4.0 is not available, but is referred to by another package. > > > This may mean that the package is missing, has been obsoleted, or is > > > only available from another source. > > > However the following packages replace it: > > > gcc-4.0-locales > > > W. (a series of warnings that Couldn't stat source package list at > > > http:... E: Package gcc-4.0 has no installation candidate. > > > > > > My sources.list from which the net installation was carried out with > > > only main and the row end (subsequently, apt-get update did nothing): > > > deb http://debian.inode.at/debian-amd64/debian/ etch main contrib > > > non-free deb-src http://debian.inode.at/debian-amd64/debian/ etch main > > > contrib non-free > > > > Think you have to change your repository to the main debain ones, as > > etch has been moved to there > > > > something like > > ftp://ftp.au.debian.org/debian etch main contrib non-free > > Now tried: > #apt-get update (or upgrade) with sources.list > deb ftp://ftp.au.debian.org/debian etch main contrib non-free > deb-src ftp://ftp.au.debian.org/debian etch main contrib non-free > deb http://security.debian.org/ etch/updates main contrib non-free > deb-src http://security.debian.org/ etch/updates main contrib non-free > fails to give access to either sources or security updates and no > update/upgrade occurs at all > > Then also tried: > #apt-get update (or upgrade) with sources.list > deb ftp://ftp.debian.org/debian etch main contrib non-free > deb-src ftp://ftp.debian.org/debian etch main contrib non-free > deb http://security.debian.org/ etch/updates main contrib non-free > deb-src http://security.debian.org/ etch/updates main contrib non-free > fails to give access to either sources or security updates and no > update/upgrade occurs at all > > (installation was from etch beta 2 release installer; netinstall from > debian.inode.at) > > TO ADD that with either 'au' or without in the sources.list, the result of > gcc trial install is the same as with debian.inode.at, i.e.: > > #apt-get install gcc-4.0 > Reading.. > Building dependency tree... > Package 4.0 is not available, but is referred to by another package. This > may mean that the package is missing, has been obsoleted, or is only > available from another source. > However the following packages replace it: > gcc-4.0-locales > W. (a series of warnings that Couldn't stat source package list at http:... > E: Package gcc-4.0 has no installation candidate. > > francesco pietra > > ___ > > > > deb http://security.debian.org/ etch/updates main contrib non-free > > > deb-src http://security.debian.org/ etch/updates main contrib non-free > > > > > > thanks a lot for your interest and kind advice > > > > > > francesco pietra > > > > > > > Len Sorensen > > > > > > -- May as well try this # alias gcc="gcc-4.1" # export gcc # make -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Tuesday 06 June 2006 23:24, Alexander Samad wrote: > On Tue, Jun 06, 2006 at 08:11:01PM +0200, Francesco Pietra wrote: > > On Tuesday 06 June 2006 20:13, Lennart Sorensen wrote: > > > On Tue, Jun 06, 2006 at 04:38:20PM +0200, Francesco Pietra wrote: > > > > Hi Matthew: > > > > Thank you. However: > > > > > > > > $alias gcc="gcc-4.1" make > > > > -bash: alias: make: not found > > > > > > > > $man alias > > > > No manual entry for alias > > > > > > > > I am making a cup of doubly strong green tea > > > > > > I think that should have been: > > > # alias gcc="gcc-4.1" > > > # make > > > > Retrying as you suggest as root, the first command returns the root > > prompt #make > > gcc - g -02 -c -o active.o active.c > > make: gcc: Command not found > > make: *** [active.o] Error 127 > > that is, as if the alis was not activated. > > > > > Not sure make can use shell aliases though. > > > > > > So your real problem is that gcc-4.0 which gcc depends on is not > > > currently installable for some reason on your system. > > > > Just to detail what errors: > > #apt-get install gcc > > gcc: Depends: gcc-4.0 (>=4.0.2-5) but it is not installable. > > E: Broken packages. > > > > > What output/errors do you get from: > > > apt-get install gcc-4.0 > > > > #apt-get install gcc-4.0 > > Reading.. > > Building dependency tree... > > Package 4.0 is not available, but is referred to by another package. This > > may mean that the package is missing, has been obsoleted, or is only > > available from another source. > > However the following packages replace it: > > gcc-4.0-locales > > W. (a series of warnings that Couldn't stat source package list at > > http:... E: Package gcc-4.0 has no installation candidate. > > > > My sources.list from which the net installation was carried out with only > > main and the row end (subsequently, apt-get update did nothing): > > deb http://debian.inode.at/debian-amd64/debian/ etch main contrib > > non-free deb-src http://debian.inode.at/debian-amd64/debian/ etch main > > contrib non-free > > Think you have to change your repository to the main debain ones, as > etch has been moved to there > > something like > ftp://ftp.au.debian.org/debian etch main contrib non-free Now tried: #apt-get update (or upgrade) with sources.list deb ftp://ftp.au.debian.org/debian etch main contrib non-free deb-src ftp://ftp.au.debian.org/debian etch main contrib non-free deb http://security.debian.org/ etch/updates main contrib non-free deb-src http://security.debian.org/ etch/updates main contrib non-free fails to give access to either sources or security updates and no update/upgrade occurs at all Then also tried: #apt-get update (or upgrade) with sources.list deb ftp://ftp.debian.org/debian etch main contrib non-free deb-src ftp://ftp.debian.org/debian etch main contrib non-free deb http://security.debian.org/ etch/updates main contrib non-free deb-src http://security.debian.org/ etch/updates main contrib non-free fails to give access to either sources or security updates and no update/upgrade occurs at all (installation was from etch beta 2 release installer; netinstall from debian.inode.at) TO ADD that with either 'au' or without in the sources.list, the result of gcc trial install is the same as with debian.inode.at, i.e.: #apt-get install gcc-4.0 Reading.. Building dependency tree... Package 4.0 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source. However the following packages replace it: gcc-4.0-locales W. (a series of warnings that Couldn't stat source package list at http:... E: Package gcc-4.0 has no installation candidate. francesco pietra ___ > > > deb http://security.debian.org/ etch/updates main contrib non-free > > deb-src http://security.debian.org/ etch/updates main contrib non-free > > > > thanks a lot for your interest and kind advice > > > > francesco pietra > > > > > Len Sorensen > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
