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]
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/
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
