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.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 26 April 2011 18:03, Matthias Klose d...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? 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/26/2011 05:31 PM, Konstantinos Margaritis wrote: On 26 April 2011 18:03, Matthias Klosed...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? yes, forgot about that. with GCC 4.6, armhf is built again from the 4.6 fsf branch, and lets us drop the GCC 4.5 Linaro variant. Matthias -- To UNSUBSCRIBE, email to debian-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 Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis mar...@genesi-usa.com wrote: On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? 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 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
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⎜tobiasu 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 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
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 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
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 d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. 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 Wed, 02 Mar 2011 02:34:01 +0100 Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). 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 d...@debian.org 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 dave.ang...@nrc-cnrc.gc.ca 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 dave.ang...@nrc-cnnrc.gc.ca 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 2 March 2011 02:34, Matthias Klose d...@debian.org wrote: armel (although optimized for a different processor) Hi For which processor (/architecture) is it optimized, and do you mean optimized-for, or only-runs-on? I ask in case this would mean dumping all the armv4t systems that are using Debian armel. 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 17:54, Martin Guy wrote: On 2 March 2011 02:34, Matthias Klose d...@debian.org wrote: armel (although optimized for a different processor) Hi For which processor (/architecture) is it optimized, and do you mean optimized-for, or only-runs-on? I ask in case this would mean dumping all the armv4t systems that are using Debian armel. I didn't propose changing the minimum required processor for armel. I said that 4.5 looks ok, although I can only say that for another processor default (armv7-a). Matthias -- To UNSUBSCRIBE, email to debian-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 03:34, Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Could you add armhf to the list? Konstantinos
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
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, 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 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.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 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]
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.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
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 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
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]
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
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
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 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 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
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 missing
packages and where to address that apt-get, and why install 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
delta echo bravo six four at earthshod dot co dot uk
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
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 gmmx03 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 gmmx03 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 (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 gmmx03 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 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
$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
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 gmmx03 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
On Tue, Jun 06, 2006 at 02:57:53PM +0200, Francesco Pietra wrote: Why with amd64 debian etch $gcc -v $gcc --version are unrecognized and there is no $man gcc page? While #dselect reveals that both gcc-4.1 and make are installed from base installation. Of course my question is not merely related to that, but to the use of queries with respect to 32bit etch. Is gcc installed? gcc-4.1 provides gcc-4.1, gcc depends on the current gcc, and provides the gcc link to the current version. # dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Hi Len: perhaps better for me to go for a jogging, or make a cup of strong green tea, because I am getting really confused: #dselect shows that both gcc-4.1 and make are installed (blank*** with the last * highlighted, as for packages that work, like apt) In contrast (?) #dpkg -S /usr/bin/gcc dpkg: /usr/bin/gcc not found but see below from a perusal of directories Installation was in differet partitions and raid1: /, /usr, /var/ swap, /home, /tmp /usr/bin includes, inter alia, g++-4.1, gcc-4.1, gccbug-4.1 Previously I was trying to compile a program that has Makefile only: $make gcc -g -02 -c -o active.o active.c make: *** [active.o] Error 127 thank you francesco pietra On Tuesday 06 June 2006 17:00, Lennart Sorensen wrote: On Tue, Jun 06, 2006 at 02:57:53PM +0200, Francesco Pietra wrote: Why with amd64 debian etch $gcc -v $gcc --version are unrecognized and there is no $man gcc page? While #dselect reveals that both gcc-4.1 and make are installed from base installation. Of course my question is not merely related to that, but to the use of queries with respect to 32bit etch. Is gcc installed? gcc-4.1 provides gcc-4.1, gcc depends on the current gcc, and provides the gcc link to the current version. # dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Francesco Pietra wrote: Hi Len: perhaps better for me to go for a jogging, or make a cup of strong green tea, because I am getting really confused: #dselect shows that both gcc-4.1 and make are installed (blank*** with the last * highlighted, as for packages that work, like apt) In contrast (?) #dpkg -S /usr/bin/gcc dpkg: /usr/bin/gcc not found but see below from a perusal of directories Installation was in differet partitions and raid1: /, /usr, /var/ swap, /home, /tmp /usr/bin includes, inter alia, g++-4.1, gcc-4.1, gccbug-4.1 Previously I was trying to compile a program that has Makefile only: $make gcc -g -02 -c -o active.o active.c make: *** [active.o] Error 127 thank you francesco pietra On Tuesday 06 June 2006 17:00, Lennart Sorensen wrote: On Tue, Jun 06, 2006 at 02:57:53PM +0200, Francesco Pietra wrote: Why with amd64 debian etch $gcc -v $gcc --version are unrecognized and there is no $man gcc page? While #dselect reveals that both gcc-4.1 and make are installed from base installation. Of course my question is not merely related to that, but to the use of queries with respect to 32bit etch. Is gcc installed? gcc-4.1 provides gcc-4.1, gcc depends on the current gcc, and provides the gcc link to the current version. # dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc Len Sorensen gcc is a symbolic link, provided by the gcc package. Since you don't have the gcc package, you have no gcc. Either compile your app using gcc-4.1 instead of gcc, or install the gcc package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Hi Joe: Thank you. Because gcc is called by $make, I tried to install gcc: #apt-get install gcc gcc: Depends: gcc-4.0 (=4.0.2-5) but is not installable E: Broken packages. francesco pietra On Tuesday 06 June 2006 17:45, Jo Shields wrote: Francesco Pietra wrote: Hi Len: perhaps better for me to go for a jogging, or make a cup of strong green tea, because I am getting really confused: #dselect shows that both gcc-4.1 and make are installed (blank*** with the last * highlighted, as for packages that work, like apt) In contrast (?) #dpkg -S /usr/bin/gcc dpkg: /usr/bin/gcc not found but see below from a perusal of directories Installation was in differet partitions and raid1: /, /usr, /var/ swap, /home, /tmp /usr/bin includes, inter alia, g++-4.1, gcc-4.1, gccbug-4.1 Previously I was trying to compile a program that has Makefile only: $make gcc -g -02 -c -o active.o active.c make: *** [active.o] Error 127 thank you francesco pietra On Tuesday 06 June 2006 17:00, Lennart Sorensen wrote: On Tue, Jun 06, 2006 at 02:57:53PM +0200, Francesco Pietra wrote: Why with amd64 debian etch $gcc -v $gcc --version are unrecognized and there is no $man gcc page? While #dselect reveals that both gcc-4.1 and make are installed from base installation. Of course my question is not merely related to that, but to the use of queries with respect to 32bit etch. Is gcc installed? gcc-4.1 provides gcc-4.1, gcc depends on the current gcc, and provides the gcc link to the current version. # dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc Len Sorensen gcc is a symbolic link, provided by the gcc package. Since you don't have the gcc package, you have no gcc. Either compile your app using gcc-4.1 instead of gcc, or install the gcc package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Francesco Pietra wrote: Hi Joe: Thank you. Because gcc is called by $make, I tried to install gcc: #apt-get install gcc gcc: Depends: gcc-4.0 (=4.0.2-5) but is not installable E: Broken packages. francesco pietra On Tuesday 06 June 2006 17:45, Jo Shields wrote: Francesco Pietra wrote: Hi Len: perhaps better for me to go for a jogging, or make a cup of strong green tea, because I am getting really confused: #dselect shows that both gcc-4.1 and make are installed (blank*** with the last * highlighted, as for packages that work, like apt) In contrast (?) #dpkg -S /usr/bin/gcc dpkg: /usr/bin/gcc not found but see below from a perusal of directories Installation was in differet partitions and raid1: /, /usr, /var/ swap, /home, /tmp /usr/bin includes, inter alia, g++-4.1, gcc-4.1, gccbug-4.1 Previously I was trying to compile a program that has Makefile only: $make gcc -g -02 -c -o active.o active.c make: *** [active.o] Error 127 thank you francesco pietra On Tuesday 06 June 2006 17:00, Lennart Sorensen wrote: On Tue, Jun 06, 2006 at 02:57:53PM +0200, Francesco Pietra wrote: Why with amd64 debian etch $gcc -v $gcc --version are unrecognized and there is no $man gcc page? While #dselect reveals that both gcc-4.1 and make are installed from base installation. Of course my question is not merely related to that, but to the use of queries with respect to 32bit etch. Is gcc installed? gcc-4.1 provides gcc-4.1, gcc depends on the current gcc, and provides the gcc link to the current version. # dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc Len Sorensen "gcc" is a symbolic link, provided by the "gcc" package. Since you don't have the "gcc" package, you have no "gcc". Either compile your app using "gcc-4.1" instead of "gcc", or install the "gcc" package. How about alias: alias gcc="gcc-4.1" make or a symlink: ln -s `which gcc-4.1` /usr/local/bin/gcc
Re: gcc
On Tue, Jun 06, 2006 at 03:41:33PM +0200, Francesco Pietra wrote: Hi Len: perhaps better for me to go for a jogging, or make a cup of strong green tea, because I am getting really confused: #dselect shows that both gcc-4.1 and make are installed (blank*** with the last * highlighted, as for packages that work, like apt) Does dselect show gcc (not gcc-4.1) as installed? Does 'dpkg -l gcc' say gcc is installed? Does 'apt-get install gcc' do anything? In contrast (?) #dpkg -S /usr/bin/gcc dpkg: /usr/bin/gcc not found So you don't have a /usr/bin/gcc which probably means you don't have the gcc (no version) package installed. but see below from a perusal of directories Installation was in differet partitions and raid1: /, /usr, /var/ swap, /home, /tmp /usr/bin includes, inter alia, g++-4.1, gcc-4.1, gccbug-4.1 Previously I was trying to compile a program that has Makefile only: $make gcc -g -02 -c -o active.o active.c make: *** [active.o] Error 127 Makes sense. If only gcc-4.1 is installed, then you only have /usr/bin/gcc-4.1, not /usr/bin/gcc since the gcc package provides that. As far as I can tell, gcc still depends on gcc-4.0 since the transition isn't done to gcc 4.1, so using gcc will currently use gcc-4.0.3 until it is transitioned and the gcc package updated to default to gcc-4.1. Here is the state of my machine right now: debian:~# dpkg -l gcc\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii gcc 4.0.3-4 The GNU C compiler un gcc-2.95 none (no description available) un gcc-3.2 none (no description available) ii gcc-3.3-base 3.3.6-13 The GNU Compiler Collection (base package) un gcc-3.5 none (no description available) un gcc-3.5-base none (no description available) ii gcc-4.0 4.0.3-3 The GNU C compiler ii gcc-4.0-base 4.0.3-3 The GNU Compiler Collection (base package) un gcc-4.0-doc none (no description available) un gcc-4.0-locales none (no description available) ii gcc-4.1 4.1.1-2 The GNU C compiler ii gcc-4.1-base 4.1.1-2 The GNU Compiler Collection (base package) un gcc-4.1-doc none (no description available) un gcc-4.1-locales none (no description available) un gcc-doc none (no description available) So I have installed the packages: gcc gcc-3.3-base gcc-4.0 gcc-4.0-base gcc-4.1 gcc-4.1-base Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
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 francesco pietra On Tuesday 06 June 2006 18:20, Matthew Robinson wrote: Francesco Pietra wrote: Hi Joe: Thank you. Because gcc is called by $make, I tried to install gcc: #apt-get install gcc gcc: Depends: gcc-4.0 (=4.0.2-5) but is not installable E: Broken packages. francesco pietra On Tuesday 06 June 2006 17:45, Jo Shields wrote: Francesco Pietra wrote: Hi Len: perhaps better for me to go for a jogging, or make a cup of strong green tea, because I am getting really confused: #dselect shows that both gcc-4.1 and make are installed (blank*** with the last * highlighted, as for packages that work, like apt) In contrast (?) #dpkg -S /usr/bin/gcc dpkg: /usr/bin/gcc not found but see below from a perusal of directories Installation was in differet partitions and raid1: /, /usr, /var/ swap, /home, /tmp /usr/bin includes, inter alia, g++-4.1, gcc-4.1, gccbug-4.1 Previously I was trying to compile a program that has Makefile only: $make gcc -g -02 -c -o active.o active.c make: *** [active.o] Error 127 thank you francesco pietra On Tuesday 06 June 2006 17:00, Lennart Sorensen wrote: On Tue, Jun 06, 2006 at 02:57:53PM +0200, Francesco Pietra wrote: Why with amd64 debian etch $gcc -v $gcc --version are unrecognized and there is no $man gcc page? While #dselect reveals that both gcc-4.1 and make are installed from base installation. Of course my question is not merely related to that, but to the use of queries with respect to 32bit etch. Is gcc installed? gcc-4.1 provides gcc-4.1, gcc depends on the current gcc, and provides the gcc link to the current version. # dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc Len Sorensen gcc is a symbolic link, provided by the gcc package. Since you don't have the gcc package, you have no gcc. Either compile your app using gcc-4.1 instead of gcc, or install the gcc package. How about alias: alias gcc=gcc-4.1 make or a symlink: ln -s `which gcc-4.1` /usr/local/bin/gcc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
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 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. What output/errors do you get from: apt-get install gcc-4.0 Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
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 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]
Re: gcc
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 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] signature.asc Description: Digital signature
Re: gcc
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 That is not a valid source anymore. It isn't maintained. You can use: http://location/debian etch main contrib non-free or http://location/debian-amd64/debian/ sarge main contrib non-free Only sarge is maintained on the old unofficial amd64 sites. etch and sid are no longer updated. You have to move to the official debian mirrors with /debian dir instead. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
Lennart Sorensen [EMAIL PROTECTED] writes: I think that should have been: # alias gcc=gcc-4.1 # make What also might work (depending on Makefile): # CC=gcc-4.1 make or # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc (if /usr/local/bin is in $PATH) Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Wednesday 07 June 2006 00:05, Matthias Julius wrote: Lennart Sorensen [EMAIL PROTECTED] writes: I think that should have been: # alias gcc=gcc-4.1 # make What also might work (depending on Makefile): # CC=gcc-4.1 make # CC=gcc-4.1 make make: gcc: Command not found make: *** [active.o] Error 127 or # ln -s /usr/bin/gcc-4.1 /usr/local/bin/gcc (if /usr/local/bin is in $PATH) Matthias -- 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) 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]
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]
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 4.1 in experimental / GCC for etch
Hi! Matthias Klose a écrit : The GCC (GNU compiler collection) 4.1 release candidate 1 can be found in experimental. Porters, please make sure that the package is built and uploaded (if it's not built by the experimental buildd). Please check that the symbols exported in the 4.1 libraries are a superset of those exported in the 4.0 libraries (these are libgcc1 (except m68k and hppa), libstdc++6, libffi4, libobjc1, libmudflap0). The proposed GCC plan for etch consists of: - uploading GCC 4.0.3 to unstable (this release is expected shortly after the GCC 4.1.0 release), let 4.0.3 migrate to testing. The GCC website seems to be down currently, could you please tell us when the release are expected? - uploading GCC 4.1 to unstable for those architectures which do not have ABI problems (these should be all, but should be validated). Nice! - Once the 4.1 packages are migrated to testing, make 4.1 the default compiler for i386, amd64, powerpc. These are the architectures, which are considred primary (linux) architectures by GCC upstream. For the other Debian architectures, the GCC port maintainers and the Debian port maintainers should make the call, if and when the default GCC is changed. I think you could also make 4.1 the default one for kfreebsd-i386. They are very few differences with the linux version, and the testsuite shows good results. - Make gij-4.1/gcj-4.1 the default for all architectures. - Stop building compiler packages from the GCC 3.3 source; the only packages built will be libstdc++5 (and libgcc1 on hppa/m68k). AFAIK the 2.4 kernels in Debian are built with gcc-3.3. What are the plans wrt to them? - Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 and g++-3.4 (it looks like we can go without g++-3.4 for the etch release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be found anymore in 4.x releases. Currently three architectures are still using gcc 3.4 to build the glibc, namely m68k, hppa and powerpc. For powerpc, it seems we can make the switch to at least gcc 4.0. There is currently a problem of locales, but not sure it is related to gcc-4.0. For hppa, the glibc builds well with gcc 4.0, but create problem with python/perl. It still has to be investigated. For m68k, the glibc does not build, gcc 4.0 segfault on system.c. It looks like gcc 4.1 fixes the problem, but the resulting glibc has not been tested. I think compilers are critical for the glibc, so we will have to coordinate the changes. Aurélien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 in experimental / GCC for etch
On Tue, Feb 21, 2006 at 11:34:55AM +0100, Aurelien Jarno wrote: - Once the 4.1 packages are migrated to testing, make 4.1 the default compiler for i386, amd64, powerpc. These are the architectures, which are considred primary (linux) architectures by GCC upstream. For the other Debian architectures, the GCC port maintainers and the Debian port maintainers should make the call, if and when the default GCC is changed. I think you could also make 4.1 the default one for kfreebsd-i386. They are very few differences with the linux version, and the testsuite shows good results. Agreed, but.. (see below) - Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 and g++-3.4 (it looks like we can go without g++-3.4 for the etch release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be found anymore in 4.x releases. Currently three architectures are still using gcc 3.4 to build the glibc, namely m68k, hppa and powerpc. Building kfreebsd-5 (and kfreebsd-6, etc) requires gcc-3.4 as well. Note that upstream only supports their own fork of gcc-3.4 to build the kernel, and I'm not aware of any plans to update it short-term. So AFAIK no problem on our side to make gcc-4.1 the default, as long as gcc-3.4 is still present. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
Dr Gavin Seddon [EMAIL PROTECTED] writes: Hi, I am trying to get vmware running again, however it wants gcc-3.4.4 which I cannot find for sid can anyone help? Gavin Try gcc-3.4. The package name doesn't change for each minor version. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
Hi, I get this 'our kernel was built with gcc version 3.4.4, while you are trying to use /usr/bin/gcc version 3.4.5. This configuration is not recommended and VMware Workstation may crash if you'll continue. Please try to use exactly same compiler as one used for building your kernel.' Gavin On Thu, 2005-10-20 at 15:55 +0200, Goswin von Brederlow wrote: Dr Gavin Seddon [EMAIL PROTECTED] writes: Hi, I am trying to get vmware running again, however it wants gcc-3.4.4 which I cannot find for sid can anyone help? Gavin Try gcc-3.4. The package name doesn't change for each minor version. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
On Thu, Oct 20, 2005 at 02:12:30PM +, Dr Gavin Seddon wrote: Hi, I get this 'our kernel was built with gcc version 3.4.4, while you are trying to use /usr/bin/gcc version 3.4.5. This configuration is not recommended and VMware Workstation may crash if you'll continue. Please try to use exactly same compiler as one used for building your kernel.' Do it anyhow. I have never had a problem as long as x.y matches. .z doesn't matter. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
Hi, I posted the message I receive. It appears I need 3.4.4. On Thu, 2005-10-20 at 10:34 -0400, Lennart Sorensen wrote: On Thu, Oct 20, 2005 at 02:12:30PM +, Dr Gavin Seddon wrote: Hi, I get this 'our kernel was built with gcc version 3.4.4, while you are trying to use /usr/bin/gcc version 3.4.5. This configuration is not recommended and VMware Workstation may crash if you'll continue. Please try to use exactly same compiler as one used for building your kernel.' Do it anyhow. I have never had a problem as long as x.y matches. .z doesn't matter. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
On Thu, Oct 20, 2005 at 03:23:02PM +, Dr Gavin Seddon wrote: Hi, I posted the message I receive. It appears I need 3.4.4. My vmware always asked if it should continue anyhow, and I just said yes and things worked fine. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
Dr Gavin Seddon [EMAIL PROTECTED] writes: Now I can't find the headers for 2.6.8-11-k8. I think I'll try the 2.6.12 kernel. Gavin. Doh, you have to install them. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
Now I can't find the headers for 2.6.8-11-k8. I think I'll try the 2.6.12 kernel. Gavin. On Thu, 2005-10-20 at 12:08 -0400, Lennart Sorensen wrote: On Thu, Oct 20, 2005 at 03:23:02PM +, Dr Gavin Seddon wrote: Hi, I posted the message I receive. It appears I need 3.4.4. My vmware always asked if it should continue anyhow, and I just said yes and things worked fine. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.4.4
I, I've inst. 2.6.8-10 that are in my list but these don't work. On Thu, 2005-10-20 at 20:34 +0200, Goswin von Brederlow wrote: Dr Gavin Seddon [EMAIL PROTECTED] writes: Now I can't find the headers for 2.6.8-11-k8. I think I'll try the 2.6.12 kernel. Gavin. Doh, you have to install them. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.0 as default compiler
Javier Kohen kiedys napisal: Hi, I see that gcc-4:4.0.0-1 became the default compiler on sid, do you think (or better yet, know by experience) if's safe to switch to it already on AMD64, or should I put it on hold for now? Greetings, You can switch to gcc-4.0. If it doesn't work for you then as I see gcc-3.4 is still available. You can use gcc-4.0 as default compiler and gcc-3.4 if 4.0 fails -- Registered Linux User 369908 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.0 as default compiler
Hi Marcin, El vie, 08-07-2005 a las 18:11 +0200, Marcin Dębicki escribió: Javier Kohen kiedys napisal: Hi, I see that gcc-4:4.0.0-1 became the default compiler on sid, do you think (or better yet, know by experience) if's safe to switch to it already on AMD64, or should I put it on hold for now? Greetings, You can switch to gcc-4.0. If it doesn't work for you then as I see gcc-3.4 is still available. You can use gcc-4.0 as default compiler and gcc-3.4 if 4.0 fails I'm not worried about the compiler failing, I'm worried about the compiled software not running properly. I've used the gcc-3.4/4.0 archive before and even though it was pretty good, it still had some severe issues. Greetings, -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: GCC 4.0 as default compiler
Javier Kohen [EMAIL PROTECTED] writes: Hi, I see that gcc-4:4.0.0-1 became the default compiler on sid, do you think (or better yet, know by experience) if's safe to switch to it already on AMD64, or should I put it on hold for now? Greetings, As user of testing/unstable you are our guinny pig. You tell us. Things will certainly break. But that is what testing/unstable is for. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.0 as default compiler
Goswin von Brederlow wrote: Javier Kohen [EMAIL PROTECTED] writes: Hi, I see that gcc-4:4.0.0-1 became the default compiler on sid, do you think (or better yet, know by experience) if's safe to switch to it already on AMD64, or should I put it on hold for now? Greetings, As user of testing/unstable you are our guinny pig. You tell us. Things will certainly break. But that is what testing/unstable is for. MfG Goswin So... do I get one of those neat running wheel things? :) I am looking at my AMD64 processor right here and the rest of the parts of my new system should be here by the middle of next week. Hopefully I can be of some use, I do have some experience making debs, and I program in C, C++, and python. -- Matthew A. Nicholson Digium -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.0 as default compiler
Matthew A. Nicholson [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Javier Kohen [EMAIL PROTECTED] writes: Hi, I see that gcc-4:4.0.0-1 became the default compiler on sid, do you think (or better yet, know by experience) if's safe to switch to it already on AMD64, or should I put it on hold for now? Greetings, As user of testing/unstable you are our guinny pig. You tell us. Things will certainly break. But that is what testing/unstable is for. MfG Goswin So... do I get one of those neat running wheel things? :) I am looking at my AMD64 processor right here and the rest of the parts of my new system should be here by the middle of next week. Hopefully I can be of some use, I do have some experience making debs, and I program in C, C++, and python. I don't think there are that many amd64 specific gcc-4.0 bugs left though. Most things will break on all systems and lots of people will find them. Everyone can help there. Finding those nasty amd64 specific compiler bugs on the other hand is not suited for everyone. Most of the time the bug is easy to find if you know your way around gcc internals already and impossible to fix otherwise. Anyway, the transition will take longer than a week and there is always plenty of work in Debian that is happy to be done by a volunteer. Even finding bugs and looking if they are amd64 specific or can be reproduced on other archs is a lot of help. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Ernest jw ter Kuile [EMAIL PROTECTED] writes:
On Monday 13 June 2005 09:25, Goswin von Brederlow wrote:
Changing the link breaks your debian system.
this is not true.
I've had this link pointing to gcc-3.4 since quite a while. Every time gcc
must be reinstalled (which is not often) i simply replace the link.
everything works, nothing is broken.
Beside, wat could this break ?
If you must then create a /usr/local/bin/gcc. Debian won't overwrite that.
in what way would this be different ? if changing the link breaks Debian, why
would this not ? it has the same effect (hint : no packages use /usr/bin/gcc,
and they shouldn't) .
System accounts are unlikely to have /usr/local/ in their path before
/usr/bin:
[EMAIL PROTECTED]:~% echo $PATH
/home/mrvn/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
[EMAIL PROTECTED]:~% su -
Password:
[EMAIL PROTECTED]:~# echo $PATH
/root/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
See the difference. My user would get /usr/local/bin/gcc while root
still gets /usr/bin/gcc.
gcc package insists that gcc - gcc-3.3.
And rightly so.
Wrong. It should guard the (current) default, and not prevent people from
changing it.
Beside, when setting this default, it should use the alternative method
Debian has perfected, and which is used by most other packages specifically
for this purpose.
No. gcc specificaly does not use the alternative system because
different gcc versions are incompatible. You can't just switch between
them. They are not alternatives to produce object files but each one
has its own kind of object files.
Even gcc 3.3 and 3.4 on amd64 have slight differences in their abi
that can cause programs to break if you mix. g++ 3.3 and 3.4 are so
different nearly everything fails when mixing the two.
The exact same reason kernel modules want the same gcc version is the
reason gcc can't be an alternative.
Even so, I do agree that on upgrade, package gcc should want to restore the
current gcc to the default version Debian is using. It most definitly should
_ask_ before doing so.
Since it is not an alternative and not configurable at all it (dpkg)
is right to not ask. dpkg just unpacks the link contained in the deb.
I'd much prefer to set an environment variable as well, but it's going to
require a deeper understanding of the module compilation subsystem of the
2.6 kernel. Both CC and HOSTCC seem to be ignored.
Did you export it?
that doesn't help.
The Makefile that comes with the kernel.org source clobbers any existing CC
and HOSTCC.
I don't think Debian has changed that behavior.
The vmware-config.pl script does care about the environment:
sub get_cc {
$gHelper{'gcc'} = '';
if (defined($ENV{'CC'}) (not ($ENV{'CC'} eq ''))) {
$gHelper{'gcc'} = internal_which($ENV{'CC'});
If CC is set it will be used. It even says:
print wrap('Using compiler ' . $gHelper{'gcc'}
. '. Use environment variable CC to override.' . \n\n, 0);
I think that the kernel doesn't and the nvidia modules
_need_ the 3.4 version.
The kernel doesn't use gcc. It uses gcc-3.4 because that is the
only one that can build 64bit kernels on i386.
1) the kernel build system as provided by kernel.org uses gcc. Not a specific
gcc, just any available gcc (nearly, it does check for really old gccs).
2) using gcc-3.3 to build a amd64 kernel is not efficient, but the resulting
kernel will boot without any trouble, even if a bit slow. It is not broken in
anyway (try it!).
I actualy use gcc-3.3 for my kernel because I was to lazy / forgot to
use a different one. Never had a problem with it.
Any kernel modules you build also have to use gcc-3.4 and not gcc.
All kernel modules should be compiled using the exact same gcc as the
one used to compile the kernel. if you use gcc-3.3 for the kernel, modules
should use that too.
If one module (nvidia) requires gcc version 3.4 or higher, then the kernel
and
all other modules must be recompiled to use that same gcc.
Just for the record : changing the kernel Makefile (as Debian apparently did)
to force a specific gcc is IMNSHO dumb.
The kernel Makefile isn't changed to force a gcc version afaik. The
Debian system ships a gcc link (or script on some archs) that garanties
calling gcc will use a gcc version compatible with the existing
binaries and libs.
But that doesn't mean gcc-3.4 should be THE gcc.
Goswin, nobody claimed that. They just want easy choice.
what about changing package gcc to check available versions of gcc, and
asking
the user the one they want to ?
Can't work. The C/C++ ABI to use is not a users/admins choice but must
be made by debian prior to compiling all packages.
Don't worry, I'm still using Debian, and I don't plan to change.
Ernest ter Kuile.
a developer.
MfG
Goswin
--
To
Re: gcc version issue trying to install vmware5
Goswin von Brederlow wrote:
The vmware-config.pl script does care about the environment:
sub get_cc {
$gHelper{'gcc'} = '';
if (defined($ENV{'CC'}) (not ($ENV{'CC'} eq ''))) {
$gHelper{'gcc'} = internal_which($ENV{'CC'});
If CC is set it will be used. It even says:
print wrap('Using compiler ' . $gHelper{'gcc'}
. '. Use environment variable CC to override.' . \n\n, 0);
Well, it cares about it, but setting CC still doesn't work. I removed the
symlink I hand-libbed onto the box for gcc-3.4 and then did apt-get install
--reinstall gcc to make sure that things are setup the Debian way, exported
CC, and tried to compile:
$ export CC=gcc-3.4
$ sudo vmware-config.pl
Making sure services for VMware Workstation are stopped.
Stopping VMware services:
snip
Trying to find a suitable vmmon module for your running kernel.
None of the pre-built vmmon modules for VMware Workstation is suitable for
your running kernel. Do you want this program to try to build the vmmon
module for your system (you need to have a C compiler installed on your
system)? [yes]
Using compiler /usr/bin/gcc-3.4. Use environment variable CC to override.
What is the location of the directory of C header files that match your
running kernel? [/lib/modules/2.6.11.11/build/include]
Extracting the sources of the vmmon module.
Building the vmmon module.
Using 2.6.x kernel build system.
...
make[1]: Entering directory `/usr/src/linux-2.6.11.11'
/tmp/vmware-config0/vmmon-only/Makefile:87: *** Inappropriate build
environment you wanted to use gcc version 3.4.5 while kernel attempts to use
gcc version 3.3.6.
/tmp/vmware-config0/vmmon-only/Makefile:89: *** For proper build you'll have
to replace gcc with symbolic link to /usr/bin/gcc-3.4. Stop.
make[1]: *** [_module_/tmp/vmware-config0/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.11.11'
make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-config0/vmmon-only'
Unable to build the vmmon module.
snip remaining
Just to be damn sure that the kernel build system wouldn't remember that I
had previously used gcc and was now trying to use gcc-3.4, I rebuilt my
kernel using:
make CC=gcc-3.4 HOSTCC=gcc-3.4
And the results are the same, (as someone previously on this thread
indicated they would be).
vmware-config.pl overwrites the PATH (line 7746 in the current vmware5), so
dropping a symlink for gcc into /usr/local/bin/ doesn't help (without
modifying the script). Exporting CC to be /usr/local/bin/gcc also fails
with the same errors listed above.
However, with the symlink in place and /usr/local/bin/ in my PATH, I was
able to use module-assistant to build the nvidia kernel module, and the
build system for the ivtv modules also works, so I imagine other stuff does
as well. So, in summary, the gcc symlink in /usr/local/bin/ works pretty
well (at least for me, YMMV), and vmware-config.pl is not going to work
without either placing something in /usr/bin (e.g. /usr/bin/vmwarecc -
/usr/bin/gcc-3.4) or modifying the script to not muck with the PATH.
Thanks,
tony
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
On Monday 13 June 2005 09:25, Goswin von Brederlow wrote: Changing the link breaks your debian system. this is not true. I've had this link pointing to gcc-3.4 since quite a while. Every time gcc must be reinstalled (which is not often) i simply replace the link. everything works, nothing is broken. Beside, wat could this break ? If you must then create a /usr/local/bin/gcc. Debian won't overwrite that. in what way would this be different ? if changing the link breaks Debian, why would this not ? it has the same effect (hint : no packages use /usr/bin/gcc, and they shouldn't) . gcc package insists that gcc - gcc-3.3. And rightly so. Wrong. It should guard the (current) default, and not prevent people from changing it. Beside, when setting this default, it should use the alternative method Debian has perfected, and which is used by most other packages specifically for this purpose. Even so, I do agree that on upgrade, package gcc should want to restore the current gcc to the default version Debian is using. It most definitly should _ask_ before doing so. I'd much prefer to set an environment variable as well, but it's going to require a deeper understanding of the module compilation subsystem of the 2.6 kernel. Both CC and HOSTCC seem to be ignored. Did you export it? that doesn't help. The Makefile that comes with the kernel.org source clobbers any existing CC and HOSTCC. I don't think Debian has changed that behavior. I think that the kernel doesn't and the nvidia modules _need_ the 3.4 version. The kernel doesn't use gcc. It uses gcc-3.4 because that is the only one that can build 64bit kernels on i386. 1) the kernel build system as provided by kernel.org uses gcc. Not a specific gcc, just any available gcc (nearly, it does check for really old gccs). 2) using gcc-3.3 to build a amd64 kernel is not efficient, but the resulting kernel will boot without any trouble, even if a bit slow. It is not broken in anyway (try it!). Any kernel modules you build also have to use gcc-3.4 and not gcc. All kernel modules should be compiled using the exact same gcc as the one used to compile the kernel. if you use gcc-3.3 for the kernel, modules should use that too. If one module (nvidia) requires gcc version 3.4 or higher, then the kernel and all other modules must be recompiled to use that same gcc. Just for the record : changing the kernel Makefile (as Debian apparently did) to force a specific gcc is IMNSHO dumb. But that doesn't mean gcc-3.4 should be THE gcc. Goswin, nobody claimed that. They just want easy choice. what about changing package gcc to check available versions of gcc, and asking the user the one they want to ? Don't worry, I'm still using Debian, and I don't plan to change. Ernest ter Kuile. a developer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Lennart Sorensen wrote: On Thu, Jun 16, 2005 at 01:10:08PM +0200, Ernest jw ter Kuile wrote: that doesn't help. The Makefile that comes with the kernel.org source clobbers any existing CC and HOSTCC. I don't think Debian has changed that behavior. The kernel makefile does the same as all other makefiles and works fine. It does NOT use the env, since make generally doesn't. it does work this way though: make HOSTCC=gcc-3.4 CC=gcc-3.4 menuconfig Add V=1 if you want to see what commands it is running. That is the _correct_ way to pass parameters to make and also how make-kpkg does it (through the variable MAKEFLAGS it uses for exactly that purpose) Thanks to everyone who has responded to this thread. I like Goswin's idea about putting the symlink in /usr/local/bin/, since this rules out the possibility of a later gcc package install resulting in something unintended. Anyway, I'm going to undo the symlink I have in place and see if the issue can't be solved by passing the correct variables when invoking make, and then I'll report back to the list. tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
tony mancill [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Rupert Heesom [EMAIL PROTECTED] writes: On Sun, 2005-06-12 at 21:45 +0200, Goswin von Brederlow wrote: Rupert Heesom [EMAIL PROTECTED] writes: Just a note to let you know that I installed the vanilla kernel headers, and I had to redo the soft link of /usr/bin/gcc to /usr/bin/gcc-3.4. No you don't. You should set CC. I did that to start with (kept it that way), but the vmware compile didn't like that, a very good error msg told me to change the s-link, so I did. It then worked. Setting env CC probably works for most things. Changing the link breaks your debian system. Perhaps you could elaborate on this. What specifically is broken about the system if gcc - gcc-3.4? My system has been setup this way for over 2 months and there haven't been any adverse side-effects that I'm aware of. The default compiler is gcc-3.3 and everything in debian uses that. If you use anything that needs gcc then you end up with the wrong compiler. Not everything checks like vmware does to make sure it has the right one. I tried updating it using alternatives, but seemed to lose the preference everytime I did an apt-get upgrade, I'm pretty certain this is because the gcc package insists that gcc - gcc-3.3. And rightly so. If you must then create a /usr/local/bin/gcc. Debian won't overwrite that. Or create a /usr/local/bin/kernel/gcc and add /usr/local/bin/kernel/ first to your path only when building kernel modules. I'd much prefer to set an environment variable as well, but it's going to require a deeper understanding of the module compilation subsystem of the 2.6 kernel. Both CC and HOSTCC seem to be ignored. Did you export it? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
A Dimarts 14 Juny 2005 11:20, Goswin von Brederlow va escriure: [] The default compiler is gcc-3.3 and everything in debian uses that. Sure? I think that the kernel doesn't and the nvidia modules _need_ the 3.4 version. It's a bit confuss to have in this platform two versions of the compiler and choose the best for each circumstance. Maybe, if the 3.3 and the 3.4 versions have problems in _our_ platform, we should think again to make some effort in the a 4.x version of the dist to have only one compiler for _ALL_ the distro. And I'm writing this with good sense, the last think I want is a flame. I would like to make just a reflexion. Maybe, I'm wrong. Regards, Leo -- -- Linux User 152692 Catalonia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Leopold Palomo-Avellaneda [EMAIL PROTECTED] writes: A Dimarts 14 Juny 2005 11:20, Goswin von Brederlow va escriure: [] The default compiler is gcc-3.3 and everything in debian uses that. Sure? I think that the kernel doesn't and the nvidia modules _need_ the 3.4 version. The gernel doesn't use gcc. It uses gcc-3.4 because that is the only one that can build 64bit kernels on i386. Any kernel modules you build also have to use gcc-3.4 and not gcc. But that doesn't mean gcc-3.4 should be THE gcc. It's a bit confuss to have in this platform two versions of the compiler and choose the best for each circumstance. Maybe, if the 3.3 and the 3.4 versions have problems in _our_ platform, we should think again to make some effort in the a 4.x version of the dist to have only one compiler for _ALL_ the distro. Debian already defines one gcc version to be used for a release, that is what gcc links to. Gcc-3.4 is only used in special circumstances where it is needed and where it doesn't affect the rest of the system. The choice was to use gcc-3.4 or to not have a kernel-image-2.6-amd64 in debian sarge. Same for mozilla and derivates. I think everyone agrees that using gcc-3.4 was the better alternative. For etch the plan is to switch to gcc-3.4 (or later) completly. All c++ libraries need to be recompiled for that. And I'm writing this with good sense, the last think I want is a flame. I would like to make just a reflexion. Maybe, I'm wrong. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Rupert Heesom [EMAIL PROTECTED] writes: On Sun, 2005-06-12 at 21:45 +0200, Goswin von Brederlow wrote: Rupert Heesom [EMAIL PROTECTED] writes: Just a note to let you know that I installed the vanilla kernel headers, and I had to redo the soft link of /usr/bin/gcc to /usr/bin/gcc-3.4. No you don't. You should set CC. I did that to start with (kept it that way), but the vmware compile didn't like that, a very good error msg told me to change the s-link, so I did. It then worked. Setting env CC probably works for most things. Changing the link breaks your debian system. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Just a note to let you know that I installed the vanilla kernel headers, and I had to redo the soft link of /usr/bin/gcc to /usr/bin/gcc-3.4. I think I might have previously deleted the vanilla headers when I wondered what they were doing next to the smp tree! Won't delete them again! VMware has now compiled and running (taking lots of ram!). Thanks for your support! On Thu, 2005-06-09 at 07:01 -0500, Mark Nipper wrote: On 09 Jun 2005, Rupert Heesom wrote: I thought all of the derivative kernel-header packages were suppose to include the vanilla kernel-header-x.y.z-r package also? Just testing a few in dselect seems to select the base version also for me on my current system (x86 though, not x86_64). Anyway, yes, installing the kernel-headers-2.6.8-11 package itself will probably fix your problem. I'm not sure if it's just kernel-headers-2.6.8-11 off the top of my head or whether the -amd64 will be on the end also. -- Rupert Heesom [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Rupert Heesom [EMAIL PROTECTED] writes: Just a note to let you know that I installed the vanilla kernel headers, and I had to redo the soft link of /usr/bin/gcc to /usr/bin/gcc-3.4. No you don't. You should set CC. I think I might have previously deleted the vanilla headers when I wondered what they were doing next to the smp tree! Won't delete them again! VMware has now compiled and running (taking lots of ram!). Thanks for your support! MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
On Sun, 2005-06-12 at 21:45 +0200, Goswin von Brederlow wrote: Rupert Heesom [EMAIL PROTECTED] writes: Just a note to let you know that I installed the vanilla kernel headers, and I had to redo the soft link of /usr/bin/gcc to /usr/bin/gcc-3.4. No you don't. You should set CC. I did that to start with (kept it that way), but the vmware compile didn't like that, a very good error msg told me to change the s-link, so I did. It then worked. Setting env CC probably works for most things. -- Rupert Heesom [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
On 09 Jun 2005, Rupert Heesom wrote: I was running the install script for vmware5, it complained that my kernel was compiled using gcc 3.4 and my current gcc is version 3.3.5. You might try specifying CC=gcc-3.4 in your environment or on the same line as your vmware configure command: --- CC=gcc-3.4 /usr/local/vmware/bin/vmware-config.pl I would imagine either one will work. -- Mark Nippere-contacts: 4475 Carter Creek Parkway [EMAIL PROTECTED] Apartment 724 http://nipsy.bitgnome.net/ Bryan, Texas, 77802-4481 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 GG/IT d- s++:+ a- C++$ UBL$ P---+++ L+++$ !E--- W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- I cannot tolerate intolerant people. end random quote of the moment -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
Thanks, putting CC into env did work, now I know where the 3.4 exe is! However I have another problem now with VMware - the script fails again with the kernel headers (which I have installed). I've taken a look at the k-headers tree and symlinks, and I think I know what's wrong, but wanted a 2nd opinion. stat'd /usr/src/linux (shows symlink as expected) File: `linux' - `kernel-headers-2.6.8-11-amd64-k8-smp' stat'd /usr/src/linux/include/asm (shows symlink to non-smp, non-k8 kernel tree which is not present) File: `asm' - `../../kernel-headers-2.6.8-11/include/asm' The non-present vanilla kernel tree which is being symlinked to is what the vmware install script can't read. Should I have both the k8-smp kernel headers and the vanilla headers installed, or are the current kernel-headers faulty?? On Thu, 2005-06-09 at 05:57 -0500, Mark Nipper wrote: On 09 Jun 2005, Rupert Heesom wrote: I was running the install script for vmware5, it complained that my kernel was compiled using gcc 3.4 and my current gcc is version 3.3.5. You might try specifying CC=gcc-3.4 in your environment or on the same line as your vmware configure command: --- CC=gcc-3.4 /usr/local/vmware/bin/vmware-config.pl I would imagine either one will work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
On 09 Jun 2005, Rupert Heesom wrote: However I have another problem now with VMware - the script fails again with the kernel headers (which I have installed). I've taken a look at the k-headers tree and symlinks, and I think I know what's wrong, but wanted a 2nd opinion. stat'd /usr/src/linux (shows symlink as expected) File: `linux' - `kernel-headers-2.6.8-11-amd64-k8-smp' stat'd /usr/src/linux/include/asm (shows symlink to non-smp, non-k8 kernel tree which is not present) File: `asm' - `../../kernel-headers-2.6.8-11/include/asm' The non-present vanilla kernel tree which is being symlinked to is what the vmware install script can't read. Should I have both the k8-smp kernel headers and the vanilla headers installed, or are the current kernel-headers faulty?? I thought all of the derivative kernel-header packages were suppose to include the vanilla kernel-header-x.y.z-r package also? Just testing a few in dselect seems to select the base version also for me on my current system (x86 though, not x86_64). Anyway, yes, installing the kernel-headers-2.6.8-11 package itself will probably fix your problem. I'm not sure if it's just kernel-headers-2.6.8-11 off the top of my head or whether the -amd64 will be on the end also. -- Mark Nippere-contacts: 4475 Carter Creek Parkway [EMAIL PROTECTED] Apartment 724 http://nipsy.bitgnome.net/ Bryan, Texas, 77802-4481 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 GG/IT d- s++:+ a- C++$ UBL$ P---+++ L+++$ !E--- W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- ...now I am become Death [Shiva]. the destroyer of worlds... -- J. Robert Oppenheimer on 16 July 1945 at 0529 Mountain War Time in the Jornada del Muerto desert near the Trinity site in the White Sands Missile Range quoting from the Bhagavad-Gita upon witnessing the first atomic detonation by mankind. The quote from the Bhagavad-Gita: If the radiance of a thousand suns Were to burst at once in the sky That would be like the splendor of the Mighty one... I am become Death, The shatterer of Worlds. end random quote of the moment -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
I installed vanilla headers (2.6.8-11) and all is fine now re compiling. Thinking back, I seem to remember actually deleting the vanilla headers since I didn't think they should be there! Shouldn't be so trigger happy! Now on to creating a chroot-ia32 On Thu, 2005-06-09 at 07:01 -0500, Mark Nipper wrote: On 09 Jun 2005, Rupert Heesom wrote: I thought all of the derivative kernel-header packages were suppose to include the vanilla kernel-header-x.y.z-r package also? Just testing a few in dselect seems to select the base version also for me on my current system (x86 though, not x86_64). Anyway, yes, installing the kernel-headers-2.6.8-11 package itself will probably fix your problem. I'm not sure if it's just kernel-headers-2.6.8-11 off the top of my head or whether the -amd64 will be on the end also. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc version issue trying to install vmware5
I installed vanilla headers (2.6.8-11) and all is fine now re compiling. Thinking back, I seem to remember actually deleting the vanilla headers since I didn't think they should be there! Shouldn't be so trigger happy! Now on to creating a chroot-ia32 I had same problem (but not for kernel smp) and vmware 5.0 now works perfectly for me. probably: ls -l /usr/bin/gcc - /usr/bin/gcc-3.3.5 just remove /usr/bin/gcc link and remake a new: ln -s /usr/bin/gcc-3.4 /usr/bin/gcc Giulio
Re: gcc-3.3 -m32 fail, but gcc-3.4 -m32 success
Hello, gcc-3.3 is not built to cross-compile, only gcc-3.4 is. Thus, you must use gcc-3.4 if you want to compile 32bit binaries on amd64 or 64bit binaries on i386. (That's BTW the reason why our 64bit kernel packages are built with gcc-3.4, as they exist for both architectures.) Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: gcc-3.4 branch gone?
On 05-May-04 11:12, Pavel Jurus wrote: I use gcc-3.4 branch of unofficial debian-amd64 (deb http://bach.hpc2n.umu.se/gcc-3.4 sid main contrib non-free) but now I see that all gcc-3.4 package archives on all mirrors are gone. I searched the web and the only info I found was that gcc-3.4 branch is perhaps not going to be part of the official debian infrastructure even after the release of sarge. Could someone more informed explain what is happening to gcc-3.4 branch please? Also I'm quite happy with gcc-4.0 and mainly with gfortran-4.0, what upgrade path would you recommend me if I want to keep using and testing new gcc and fortran95 on pure AMD64 Debian? The amd64/gcc4 archive, which has been recompiled from scratch with the released version of gcc-4.0, will be available on alioth starting next weekend. A proper announcement will be made on the list. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4/4.0 dumb question
Goswin von Brederlow writes: [cut] What should I do now ? should I wait until the new gcc-4.0 tree is built? or should I use the standard pure64 tree? [cut] If you have to ask then you should reinstall using the standard tree, which uses gcc-3.3. isn't there any better solution than reinstalling everything? It would take a lot of time, since I don't have a fast connection at home. (not to mention that gcc-4.0 compiled binaries are faster) thanks c. -- . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4/4.0 dumb question
[EMAIL PROTECTED] writes: Goswin von Brederlow writes: [cut] What should I do now ? should I wait until the new gcc-4.0 tree is built? or should I use the standard pure64 tree? [cut] If you have to ask then you should reinstall using the standard tree, which uses gcc-3.3. isn't there any better solution than reinstalling everything? It would take a lot of time, since I don't have a fast connection at home. (not to mention that gcc-4.0 compiled binaries are faster) thanks c. Nothing to be sure to get rid of any interfering package. You could filter out any arch:all and any non C/c++ package I guess. But is that worth it? Maybe the compiled python scripts were created with a miscompiled python and are damaged? Or any other sideeffect of using gcc-4.0 to build the debs. The speed of your connection also shouldn't matter as long as you don't pay by the minute. Just download the stuff overnight(s). Your system is working now or not? So no hurry to switch. MfG Goswin PS: I used to have a 56K modem so I feel for you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4/4.0 dumb question
Goswin von Brederlow writes: [cut] Nothing to be sure to get rid of any interfering package. You could filter out any arch:all and any non C/c++ package I guess. But is that worth it? Maybe the compiled python scripts were created with a miscompiled python and are damaged? Or any other it's possible, of course, but I didn't notice any problem so far (except when qt were broken, but they were fixed later on) sideeffect of using gcc-4.0 to build the debs. The speed of your connection also shouldn't matter as long as you don't pay by the minute. Just download the stuff overnight(s). Your of course I pay by the minute, otherwise I wouldn't have sent these mails :( system is working now or not? So no hurry to switch. my system is working fine, but I can't install new packages, eg. -dev packages that I need to compile some stuff. MfG Goswin PS: I used to have a 56K modem so I feel for you. :) c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4/4.0 dumb question
[EMAIL PROTECTED] wrote: Goswin von Brederlow writes: [cut] Nothing to be sure to get rid of any interfering package. You could filter out any arch:all and any non C/c++ package I guess. But is that worth it? Maybe the compiled python scripts were created with a miscompiled python and are damaged? Or any other it's possible, of course, but I didn't notice any problem so far (except when qt were broken, but they were fixed later on) sideeffect of using gcc-4.0 to build the debs. The speed of your connection also shouldn't matter as long as you don't pay by the minute. Just download the stuff overnight(s). Your of course I pay by the minute, otherwise I wouldn't have sent these mails :( system is working now or not? So no hurry to switch. my system is working fine, but I can't install new packages, eg. -dev packages that I need to compile some stuff. same I here. I still have few -gcc4 packages. If you need to install some -dev packages re-install their dependencies only from pure64 and then try to install -dev, it worked for me. I just downloaded required packages manually and used dpkg to install downgrade gcc4 versions; I am not sure if it is 'right way' but worked for me. Haroon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4/4.0 dumb question
[EMAIL PROTECTED] writes: I didn't understand what I'm supposed to do. I've been using gcc-3.4/4.0 sid for a long time on my laptop. What should I do now ? should I wait until the new gcc-4.0 tree is built? or should I use the standard pure64 tree? what compiler is pure64 compiled with? 3.3 or 3.4? thanks in advance c. If you have to ask then you should reinstall using the standard tree, which uses gcc-3.3. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4/4.0 dumb question
El mi, 27-04-2005 a las 18:13 +0200, [EMAIL PROTECTED] escribi: I didn't understand what I'm supposed to do. I've been using gcc-3.4/4.0 sid for a long time on my laptop. What should I do now ? should I wait until the new gcc-4.0 tree is built? or should I use the standard pure64 tree? If you don't mind the occasional instability and can live without it (i.e., your laptop is not your production environment), then go ahead and stay with gcc-4.0 if you like. Otherwise, you are encouraged to switch to pure64. what compiler is pure64 compiled with? 3.3 or 3.4? Mostly 3.3, which is the standard compiler for sarge/sid. However, a few important packages that don't work properly with 3.3 are being compiled with 3.4 (namely, mozilla and derivatives). Greetings, -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: gcc-3.4 archive
On Monday 04 April 2005 3:16pm, Javier Kohen wrote: Hi, I've been using the /gcc-3.4 archive from Alioth. Is there any difference among that one, debian-gcc-3.4 and debian-pure64-3.4? I mean a user-noticeable difference, I've read archive-structure and I think I understand, but gcc-3.4 isn't mentioned there and I don't really know what the consecuences of arch:all being rebuilt on amd64 are. Thanks for your advice, I asked the same question just a few weeks ago. :) gcc-3.4 began, and still is, an experimental branch of pure64 using a later version of gcc. It began by using gcc-3.4 for building itself, hence its name, and is now almost completely converted over to gcc-4.0. As I understand it, it will always remain an experimental branch and at some point in the distant future, when pure64 upgrades to gcc-4.0, will simply go away. For starting out with AMD64, you should stick with pure64 (now called debian-pure64 on alioth). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4: cvs sigsegv's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I hate to be answering to myself, but I finally got somehow to build the cvs package and now it works... A few remarks: 1) I added a deb-src for pure64 and now apt-src install cvs gives a segmentation fault instead of saying it can't find the source. 2) I compiled CVS with -ggdb -Wall instead of the default of -O2 -Wall. 3) I just compiled agin with -ggdb -O2 -Wall and it also works. 4) I'm compiling with gcc (GCC) 3.4.4 20041218 (prerelease) (Debian 3.4.3-7.0.0.1.gcc4). I've been following the list for two weeks or so, but I'm not sure what the procedure I should follow is. Anybody any suggestions, or should I forget about it and the auto builder will fix it next build? Javier Kohen wrote: | | I was also wondering whether installing the 32-bit cvs package would | work and whether it's expected that it will be stable. I really need to | get this out of the way and it seems the problem happens during regular | operation, too. | | Thanks, - -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9rXy823633cP2P8RAiP+AJ4sJEMqWchHNLY5yz9f/p/+muhxLQCfQA0H Z+d0KU+YPlzTEuOBCg0tOw4= =wNDt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4: mozilla-thunderbird-enigmail
On 05-Jan-23 08:34, Harald Dunkel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Would it be possible to get rid of the version conflict between mozilla-thunderbird 1.03 and mozilla-thunderbird-enigmail in amd64(gcc-3.4)? I will have very limited access to the internet for the next 6 days, but I will look at this next week. Sorry for the delay. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
