Re: [gentoo-dev] eselect-compiler updates and unmasking
Hi Kumba, In a similar vein, will this eselect tool eventually supplant the functionality of binutils-config as well (and thus need its own wrapper script)? Have a look at eselect binutils please, which is shipped with app-admin/eselect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Friday 09 June 2006 10:15, Danny van Dyk wrote: Have a look at eselect binutils please, which is shipped with app-admin/eselect. It's sub-optimal compared to eselect compiler, x86_64 ld does not work with i686. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppmkbojAU5g.pgp Description: PGP signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
Hi Diego, It's sub-optimal compared to eselect compiler, x86_64 ld does not work with i686. eselect binutils should be as capable as binutils-config. AFAIK the stated behaviour is no regression. If it is a regression, please file a bug against it. If it isn't, file a bug for an enhancement request. I'm quite positive we can get it going. :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Ah, you're right, there should be an env-update in there. Thanks for the report. As for sourcing /etc/profile, you don't need to do that with eselect- compiler because your $PATH doesn't change like it did with gcc- config-1.x. --Jeremy On Jun 8, 2006, at 11:27 , Donnie Berkholz wrote: Donnie Berkholz wrote: This aliases g77 to gfortran and gfortran to g77. They are entirely different compilers and do not accept all the same options. This is incredibly broken behavior, it masks issues in a number of packages and creates new issues in many others. Please fix it. It also doesn't run env-update, so the library paths aren't updated. In the past, all that was necessary was to source /etc/profile. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: This aliases g77 to gfortran and gfortran to g77. They are entirely different compilers and do not accept all the same options. This is incredibly broken behavior, it masks issues in a number of packages and creates new issues in many others. Please fix it. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
Donnie Berkholz wrote: This aliases g77 to gfortran and gfortran to g77. They are entirely different compilers and do not accept all the same options. This is incredibly broken behavior, it masks issues in a number of packages and creates new issues in many others. Please fix it. It also doesn't run env-update, so the library paths aren't updated. In the past, all that was necessary was to source /etc/profile. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: app-admin/eselect-conmpiler sys-devel/gcc-config then just update gcc-config: $ emerge -uv --oneshot sys-devel/gcc-config gcc-config is just a wrapper which takes the same syntax as the older gcc-configs and makes the appropriate call to eselect-compiler. Please report any bugs you find in bugzilla and assign them directly to me ([EMAIL PROTECTED]). Also, if you've been using eselect-compiler, you may have an issue where your profiles don't get removed from /etc/eselect/compiler when you unmerge gcc. This problem is fixed now for future installs, but you'll have to manually remove the file when you unmerge any gcc that is on your system now. Thanks, Jeremy Just a heads up: if anyone runs crossdev (even with -p), then finds a broken gcc-config, the reason lies in Bug #136140. In a similar vein, will this eselect tool eventually supplant the functionality of binutils-config as well (and thus need its own wrapper script)? --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere. --Elrond -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote: Uhm, what is this all about? If you have suggestions, make them, but don't come out of the gate in a huff talking about unsubstantiated breakage. That's about the least constructive way to get heard. i guess his point is, you're the only guy supporting eselect-compiler ... if you arent going to be around to support it, then dont unmask it -mike pgp1yPKlfYVxw.pgp Description: PGP signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Jun 7, 2006, at 02:47 , Mike Frysinger wrote: On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote: Uhm, what is this all about? If you have suggestions, make them, but don't come out of the gate in a huff talking about unsubstantiated breakage. That's about the least constructive way to get heard. i guess his point is, you're the only guy supporting eselect- compiler ... if you arent going to be around to support it, then dont unmask it -mike Yeah, I couldn't agree more. That's part of the reason why I hadn't unmasked it until now. --Jeremy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Why are you hijacking tools not written by you, declaring them as 2.0 and breaking the expected behaviors of them? Please don't do that ever again. On Fri, 2006-06-02 at 21:24 -0700, Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: app-admin/eselect-conmpiler sys-devel/gcc-config then just update gcc-config: $ emerge -uv --oneshot sys-devel/gcc-config gcc-config is just a wrapper which takes the same syntax as the older gcc-configs and makes the appropriate call to eselect-compiler. Please report any bugs you find in bugzilla and assign them directly to me ([EMAIL PROTECTED]). Also, if you've been using eselect-compiler, you may have an issue where your profiles don't get removed from /etc/eselect/compiler when you unmerge gcc. This problem is fixed now for future installs, but you'll have to manually remove the file when you unmerge any gcc that is on your system now. Thanks, Jeremy -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Uhm, what is this all about? If you have suggestions, make them, but don't come out of the gate in a huff talking about unsubstantiated breakage. That's about the least constructive way to get heard. The wrapper provided in gcc-config-2.0 provides the exact same interface to the user as gcc-config-1.x, so how is that breaking expected behavior? If anything, it's providing expected behavior to users who want it and don't care about migrating over to eselect. Additionally, If you check through the ChangeLog, you'll see that I did actively worked on gcc-config-1.x last year prior to my starting eselect-compiler. That's how I came to realize its limitations and _need_ for replacement on multilib systems. A similar wrapper is needed for binutils as has been discussed multiple times on toolchain@, and at amd64 and ppc64 dev meetings on IRC. Additionally, eselect-compiler has been discussed multiple times on the toolchain and gentoo-dev lists over the past year (main threads started 2005-08-09, 2005-09-17, 2005.10.02), and you didn't once raise an objection until now. I'd say you missed the 10 month window I gave you, but if you do have suggestions, I'd be more than happy to hear them. Even more so, I left eselect-compiler in package.mask for a _very_ long time as I didn't have much time to devote to its development over the past school year. During that time, very few issues were raised despite it being used by many testers and developers. This past month, I worked out all but one of the known bugs (the one remaining is just specific to the wine package on amd64) and got more testers to give it a final beating before finally unmasking it. If anything, this has been an extremely conservative development process because of the nature of this package. --Jeremy On Jun 6, 2006, at 04:28 , Ned Ludd wrote: Why are you hijacking tools not written by you, declaring them as 2.0 and breaking the expected behaviors of them? Please don't do that ever again. On Fri, 2006-06-02 at 21:24 -0700, Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: app-admin/eselect-conmpiler sys-devel/gcc-config then just update gcc-config: $ emerge -uv --oneshot sys-devel/gcc-config gcc-config is just a wrapper which takes the same syntax as the older gcc-configs and makes the appropriate call to eselect-compiler. Please report any bugs you find in bugzilla and assign them directly to me ([EMAIL PROTECTED]). Also, if you've been using eselect-compiler, you may have an issue where your profiles don't get removed from /etc/eselect/compiler when you unmerge gcc. This problem is fixed now for future installs, but you'll have to manually remove the file when you unmerge any gcc that is on your system now. Thanks, Jeremy -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Couple of questions: 1) Can it handle non-gcc compilers? If so, how? It is possible, but I'm not sure if icc is installed in a way that makes it convenient. All the binaries will need to be lumped in a directory by themselves (like we do with gcc). You'll have to create your own profile in /etc/eselect/compiler. 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. No, this isn't something I considered a high priority. I was more interested in tackling the issues road-blocking multilib, but this is something that would be a nice feature down the road. If neither of those are possible now, I would like to look into fixing this. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Well, incidentally I was working on toolchainasing gnat (a gcc based Ada compiler, basically just another frontend) and pestered toolchain people on irc regarding similar matters. Basically it came down to: toolchain.eclass and eselect-compiler are not for stuff not in gcc, so I had to create my own ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions actually :). I could not inherit toolchain.eclass either, only copy the relevant parts of it.. A due notice: this was discussed already like half a year ago (although when I announced progress here on -dev no comments followed), so if the things have chaged since then I will be interested to know too.. Well, I'm not against that support being in eselect-compiler, and in fact I think it'd be nice... It's just not a priority on my list, so if you'd like to contribute changes which allow support for what you want without needlessly complicating things for those who don't want to use these advanced features, then I'm more than willing to incorporate them. --Jeremy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Jun 2, 2006, at 21:33 , Donnie Berkholz wrote: Couple of questions: 1) Can it handle non-gcc compilers? If so, how? It is possible, but I'm not sure if icc is installed in a way that makes it convenient. All the binaries will need to be lumped in a directory by themselves (like we do with gcc). You'll have to create your own profile in /etc/eselect/compiler. 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. No, this isn't something I considered a high priority. I was more interested in tackling the issues road-blocking multilib, but this is something that would be a nice feature down the road. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Saturday, 3. June 2006 06:33, Donnie Berkholz Ви написали: Jeremy Huddleston wrote: Couple of questions: 1) Can it handle non-gcc compilers? If so, how? 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. If neither of those are possible now, I would like to look into fixing this. Thanks, Donnie Well, incidentally I was working on toolchainasing gnat (a gcc based Ada compiler, basically just another frontend) and pestered toolchain people on irc regarding similar matters. Basically it came down to: toolchain.eclass and eselect-compiler are not for stuff not in gcc, so I had to create my own ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions actually :). I could not inherit toolchain.eclass either, only copy the relevant parts of it.. A due notice: this was discussed already like half a year ago (although when I announced progress here on -dev no comments followed), so if the things have chaged since then I will be interested to know too.. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Jeremy Huddleston wrote: I finally had a few free cycles, so I fixed up the eselect-compiler ebuild to better handle the transition from gcc-config and updated toolchain.eclass to better work with multilib. I've had a bunch of help from the amd64 devs/testers/users this past week testing it out, and I think it's ready to be removed from package.mask sometime soon (next week). Before that happens, I'd like to get some feedback from a broader test base, so if you have some time and aren't using eselect-compiler yet, I'd appreciate your testing. All you need to do is add the following to /etc/portage/package.unmask: Couple of questions: 1) Can it handle non-gcc compilers? If so, how? 2) Can it handle different languages being set to different compilers? For example, use Intel's Fortran compiler but GCC for everything else. If neither of those are possible now, I would like to look into fixing this. Thanks, Donnie signature.asc Description: OpenPGP digital signature
