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:
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 req
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
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/
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 ou
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 d
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 i
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
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 o
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 g
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 bet
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
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
cr
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
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 everythin
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 i
16 matches
Mail list logo
