[U-Boot] buildman: using wrong libgcc.a

[U-Boot] buildman: using wrong libgcc.a

[Steve Rae]

Hi Simon,

In my environment, buildman and MAKEALL are not producing the same results.

It seems that buildman is accidentally picking up the wrong libgcc.a ...


*** buildman ***

$ cat ~/.buildman
[toolchain]
eldk: 
/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi

[toolchain-alias]
$


$ tools/buildman/buildman --list-tool-chains
No section: 'make-flags'
Scanning for tool chains
    - scanning path 
'/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi'
       - looking in 
'/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/.'
          - found 
'/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./armv7a-gcc'
Tool chain test:  OK
          - found 
'/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./arm-linux-gnueabi-gcc'
Tool chain test:  OK
       - looking in 
'/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/bin'
       - looking in 
'/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/usr/bin'
List of available toolchains (2):
arm       : 
/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./arm-linux-gnueabi-gcc
armv7a    : 
/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./armv7a-gcc
$


$ tools/buildman/buildman bcm28155_ap -x bcm28155_w1d -fk
No section: 'make-flags'
WARNING: no status info for 'Ippo_q8h'
WARNING: no maintainers for 'Ippo_q8h'
Building current source for 1 boards (1 thread, 8 jobs per thread)
     1    0    0 /1      bcm28155_ap
$


$ head -14 ../current/current/bcm28155_ap/u-boot.map
Archive member included because of file (symbol)

/usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_udivsi3.o)
                               arch/arm/cpu/armv7/bcm281xx/built-in.o 
(__aeabi_uidiv)
/usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_divsi3.o)
                               common/built-in.o (__aeabi_idiv)
/usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_lshrdi3.o)
                               lib/built-in.o (__aeabi_llsr)
/usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_ashldi3.o)
                               drivers/mmc/built-in.o (__aeabi_llsl)
/usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_dvmd_lnx.o)
 
/usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_udivsi3.o) (__aeabi_idiv0)

Discarded input sections
$


*** MAKEALL ***

$ 
CROSS_COMPILE_ARM=/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi- 
./MAKEALL -b bcm28155_ap
$


$ head -14 u-boot.map
Archive member included because of file (symbol)

/opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_udivsi3.o)
                               arch/arm/cpu/armv7/bcm281xx/built-in.o 
(__aeabi_uidiv)
/opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_divsi3.o)
                               common/built-in.o (__aeabi_idiv)
/opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_lshrdi3.o)
                               lib/built-in.o (__aeabi_llsr)
/opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_ashldi3.o)
                               drivers/mmc/built-in.o (__aeabi_llsl)
/opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_dvmd_lnx.o)
 
/opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_udivsi3.o) 
(__aeabi_idiv0)

Discarded input sections
$

[U-Boot] buildman: using wrong libgcc.a

[Steve Rae]

Hmmmm -- maybe it would be better to specify the entire path for the 
CROSS_COMPILE, and not rely on the PATH to find the cross compile tools:

diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index 27dc318..58c7b1f 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -33,6 +33,7 @@ class Toolchain:
          self.cross = os.path.basename(fname)[:-3]
          pos = self.cross.find('-')
          self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
+        self.cross = fname[:-3]

          env = self.MakeEnvironment()

@@ -82,7 +83,6 @@ class Toolchain:
          """
          env = dict(os.environ)
          env['CROSS_COMPILE'] = self.cross
-        env['PATH'] += (':' + self.path)
          return env



On 14-10-30 09:57 AM, Steve Rae wrote:
> Hi Simon,
>
> In my environment, buildman and MAKEALL are not producing the same results.
>
> It seems that buildman is accidentally picking up the wrong libgcc.a ...
>
>
> *** buildman ***
>
> $ cat ~/.buildman
> [toolchain]
> eldk:
> /opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi
>
>
> [toolchain-alias]
> $
>
>
> $ tools/buildman/buildman --list-tool-chains
> No section: 'make-flags'
> Scanning for tool chains
>     - scanning path
> '/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi'
>
>        - looking in
> '/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/.'
>
>           - found
> '/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./armv7a-gcc'
>
> Tool chain test:  OK
>           - found
> '/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./arm-linux-gnueabi-gcc'
>
> Tool chain test:  OK
>        - looking in
> '/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/bin'
>
>        - looking in
> '/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/usr/bin'
>
> List of available toolchains (2):
> arm       :
> /opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./arm-linux-gnueabi-gcc
>
> armv7a    :
> /opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/./armv7a-gcc
>
> $
>
>
> $ tools/buildman/buildman bcm28155_ap -x bcm28155_w1d -fk
> No section: 'make-flags'
> WARNING: no status info for 'Ippo_q8h'
> WARNING: no maintainers for 'Ippo_q8h'
> Building current source for 1 boards (1 thread, 8 jobs per thread)
>      1    0    0 /1      bcm28155_ap
> $
>
>
> $ head -14 ../current/current/bcm28155_ap/u-boot.map
> Archive member included because of file (symbol)
>
> /usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_udivsi3.o)
>                                arch/arm/cpu/armv7/bcm281xx/built-in.o
> (__aeabi_uidiv)
> /usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_divsi3.o)
>                                common/built-in.o (__aeabi_idiv)
> /usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_lshrdi3.o)
>                                lib/built-in.o (__aeabi_llsr)
> /usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_ashldi3.o)
>                                drivers/mmc/built-in.o (__aeabi_llsl)
> /usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_dvmd_lnx.o)
>
> /usr/lib/gcc/arm-linux-gnueabi/4.6/libgcc.a(_udivsi3.o) (__aeabi_idiv0)
>
> Discarded input sections
> $
>
>
> *** MAKEALL ***
>
> $
> CROSS_COMPILE_ARM=/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-
> ./MAKEALL -b bcm28155_ap
> $
>
>
> $ head -14 u-boot.map
> Archive member included because of file (symbol)
>
> /opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_udivsi3.o)
>
>                                arch/arm/cpu/armv7/bcm281xx/built-in.o
> (__aeabi_uidiv)
> /opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_divsi3.o)
>
>                                common/built-in.o (__aeabi_idiv)
> /opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_lshrdi3.o)
>
>                                lib/built-in.o (__aeabi_llsr)
> /opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_ashldi3.o)
>
>                                drivers/mmc/built-in.o (__aeabi_llsl)
> /opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_dvmd_lnx.o)
>
>
> /opt/eldk-5.4/armv7a/sysroots/armv7a-vfp-neon-linux-gnueabi/usr/lib/arm-linux-gnueabi/4.7.2/libgcc.a(_udivsi3.o)
> (__aeabi_idiv0)
>
> Discarded input sections
> $

[U-Boot] buildman: using wrong libgcc.a

[Jeroen Hofstee]

Hello Steve,

On 30-10-14 21:42, Steve Rae wrote:
> Hmmmm -- maybe it would be better to specify the entire path for the 
> CROSS_COMPILE, and not rely on the PATH to find the cross compile tools:
>
> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> index 27dc318..58c7b1f 100644
> --- a/tools/buildman/toolchain.py
> +++ b/tools/buildman/toolchain.py
> @@ -33,6 +33,7 @@ class Toolchain:
>          self.cross = os.path.basename(fname)[:-3]
>          pos = self.cross.find('-')
>          self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
> +        self.cross = fname[:-3]
>

A bit off topic, but is it possible to stop adding these magic 3
constants. strlen("clang") != 3. strlen("cc") isn't either. Anyway
I am aware buildman is already full with it, so I am fine with
one more (for now).

Regards,
Jeroen

[U-Boot] buildman: using wrong libgcc.a

[Simon Glass]

Hi,

On 30 October 2014 14:57, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hello Steve,
>
> On 30-10-14 21:42, Steve Rae wrote:
>>
>> Hmmmm -- maybe it would be better to specify the entire path for the
>> CROSS_COMPILE, and not rely on the PATH to find the cross compile tools:
>>
>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>> index 27dc318..58c7b1f 100644
>> --- a/tools/buildman/toolchain.py
>> +++ b/tools/buildman/toolchain.py
>> @@ -33,6 +33,7 @@ class Toolchain:
>>          self.cross = os.path.basename(fname)[:-3]
>>          pos = self.cross.find('-')
>>          self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
>> +        self.cross = fname[:-3]
>>
>
> A bit off topic, but is it possible to stop adding these magic 3
> constants. strlen("clang") != 3. strlen("cc") isn't either. Anyway
> I am aware buildman is already full with it, so I am fine with
> one more (for now).

This should be isolated to Toolchain. I'd be happy to have a fix that
solves this once and for all. What is needed?

Regards,
Simon

[U-Boot] buildman: using wrong libgcc.a

[Steve Rae]

On 14-11-03 01:14 PM, Simon Glass wrote:
> Hi,
>
> On 30 October 2014 14:57, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> Hello Steve,
>>
>> On 30-10-14 21:42, Steve Rae wrote:
>>>
>>> Hmmmm -- maybe it would be better to specify the entire path for the
>>> CROSS_COMPILE, and not rely on the PATH to find the cross compile tools:
>>>
>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>> index 27dc318..58c7b1f 100644
>>> --- a/tools/buildman/toolchain.py
>>> +++ b/tools/buildman/toolchain.py
>>> @@ -33,6 +33,7 @@ class Toolchain:
>>>           self.cross = os.path.basename(fname)[:-3]
>>>           pos = self.cross.find('-')
>>>           self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
>>> +        self.cross = fname[:-3]
>>>
>>
>> A bit off topic, but is it possible to stop adding these magic 3
>> constants. strlen("clang") != 3. strlen("cc") isn't either. Anyway
>> I am aware buildman is already full with it, so I am fine with
>> one more (for now).
>
> This should be isolated to Toolchain. I'd be happy to have a fix that
> solves this once and for all. What is needed?
>
> Regards,
> Simon
>
( back to the original issue )
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index 27dc318..58c7b1f 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -33,6 +33,7 @@ class Toolchain:
          self.cross = os.path.basename(fname)[:-3]
          pos = self.cross.find('-')
          self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
+        self.cross = fname[:-3]

          env = self.MakeEnvironment()


@@ -82,7 +83,6 @@ class Toolchain:
          """
          env = dict(os.environ)
          env['CROSS_COMPILE'] = self.cross
-        env['PATH'] += (':' + self.path)
          return env

This solves my problem, however, I have only built "arm" and "armv8" 
targets....
So I don't know whether it breaks any other environments.
How can we proceed?
Thanks, Steve

[U-Boot] buildman: using wrong libgcc.a

[Jeroen Hofstee]

Hello Simon,

On 03-11-14 22:14, Simon Glass wrote:
> Hi,
>
> On 30 October 2014 14:57, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> Hello Steve,
>>
>> On 30-10-14 21:42, Steve Rae wrote:
>>> Hmmmm -- maybe it would be better to specify the entire path for the
>>> CROSS_COMPILE, and not rely on the PATH to find the cross compile tools:
>>>
>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>> index 27dc318..58c7b1f 100644
>>> --- a/tools/buildman/toolchain.py
>>> +++ b/tools/buildman/toolchain.py
>>> @@ -33,6 +33,7 @@ class Toolchain:
>>>           self.cross = os.path.basename(fname)[:-3]
>>>           pos = self.cross.find('-')
>>>           self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
>>> +        self.cross = fname[:-3]
>>>
>> A bit off topic, but is it possible to stop adding these magic 3
>> constants. strlen("clang") != 3. strlen("cc") isn't either. Anyway
>> I am aware buildman is already full with it, so I am fine with
>> one more (for now).
> This should be isolated to Toolchain. I'd be happy to have a fix that
> solves this once and for all. What is needed?

not that much I think. What would be needed is to store the compiler
name in the toolchain object and use the python strlen equivalent on
that instead of the hardcoded threes. And eventually pass the correct
values to CC and HOSTCC.

When I tried that, subprocess was barfing some (at least for me not
easily, [no I don't recall which one exactly] explainable) error, so I gave
up and created a script called *-gcc invoking clang and all was fine 
again ;)

So yes, it would be nice if buildman did not make such an assumption.
It is not strictly clang related as well, at least on FreeBSD you can 
install
many gcc compilers, which will be named gcc44, gcc45.. gcc5 etc.

As already mentioned, it is not related to this patch, it adds just another
hardcoded magic 3 value.

Regards,
Jeroen

[U-Boot] buildman: using wrong libgcc.a (magic -3)

[Steve Rae]

On 14-11-05 10:46 AM, Jeroen Hofstee wrote:
> Hello Simon,
>
> On 03-11-14 22:14, Simon Glass wrote:
>> Hi,
>>
>> On 30 October 2014 14:57, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>> Hello Steve,
>>>
>>> On 30-10-14 21:42, Steve Rae wrote:
>>>> Hmmmm -- maybe it would be better to specify the entire path for the
>>>> CROSS_COMPILE, and not rely on the PATH to find the cross compile
>>>> tools:
>>>>
>>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>>> index 27dc318..58c7b1f 100644
>>>> --- a/tools/buildman/toolchain.py
>>>> +++ b/tools/buildman/toolchain.py
>>>> @@ -33,6 +33,7 @@ class Toolchain:
>>>>           self.cross = os.path.basename(fname)[:-3]
>>>>           pos = self.cross.find('-')
>>>>           self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
>>>> +        self.cross = fname[:-3]
>>>>
>>> A bit off topic, but is it possible to stop adding these magic 3
>>> constants. strlen("clang") != 3. strlen("cc") isn't either. Anyway
>>> I am aware buildman is already full with it, so I am fine with
>>> one more (for now).
>> This should be isolated to Toolchain. I'd be happy to have a fix that
>> solves this once and for all. What is needed?
>
> not that much I think. What would be needed is to store the compiler
> name in the toolchain object and use the python strlen equivalent on
> that instead of the hardcoded threes. And eventually pass the correct
> values to CC and HOSTCC.
>
> When I tried that, subprocess was barfing some (at least for me not
> easily, [no I don't recall which one exactly] explainable) error, so I gave
> up and created a script called *-gcc invoking clang and all was fine
> again ;)
>
> So yes, it would be nice if buildman did not make such an assumption.
> It is not strictly clang related as well, at least on FreeBSD you can
> install
> many gcc compilers, which will be named gcc44, gcc45.. gcc5 etc.
>
> As already mentioned, it is not related to this patch, it adds just another
> hardcoded magic 3 value.
>
> Regards,
> Jeroen
( updated the subject line for this discussion topic... )
In my experience, we would normally set the CROSS_COMPILE variable to 
the "prefix" of the cross compiler toolchain, for example:
 
CROSS_COMPILE=/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-
Perhaps if the "~/.buildman" defined these "prefixes" (rather than 
"directories"), then maybe it would be more consistent and simpler....
[ and I suspect that this magic "-3" would go away; isn't this "-3" 
because we need to strip "gcc" off the end of the string ?!?!?! ]
Thanks, Steve

[U-Boot] buildman: using wrong libgcc.a (magic -3)

[Wolfgang Denk]

Dear Steve,

In message <545A74E6.5010208@broadcom.com> you wrote:
> 
> In my experience, we would normally set the CROSS_COMPILE variable to 
> the "prefix" of the cross compiler toolchain, for example:
>  
> CROSS_COMPILE=/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-

Actually we should have only

	CROSS_COMPILE=arm-linux-gnueabi-

and make the PATH take care of where to pick the tools from.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Your csh still thinks true is false. Write to your vendor  today  and
tell them that next year Configure ought to "rm /bin/csh" unless they
fix  their blasted shell. :-)
                 - Larry Wall in Configure from the perl distribution

[U-Boot] buildman: using wrong libgcc.a (magic -3)

[Steve Rae]

On 14-11-05 11:09 AM, Wolfgang Denk wrote:
> Dear Steve,
>
> In message <545A74E6.5010208@broadcom.com> you wrote:
>>
>> In my experience, we would normally set the CROSS_COMPILE variable to
>> the "prefix" of the cross compiler toolchain, for example:
>>
>> CROSS_COMPILE=/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-
>
> Actually we should have only
>
> 	CROSS_COMPILE=arm-linux-gnueabi-
>
> and make the PATH take care of where to pick the tools from.
>
> Best regards,
>
> Wolfgang Denk
>
Actually, that would be unfortunate, because I currently have:
- /usr/bin/arm-linux-gnueabi-gcc
- 
/opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-gcc
- (and others)
installed on my machine....
If $PATH" was to "take care of it", then somehow $PATH would need to be 
constantly "rearranged" so that the desired compiler is selected correctly.
IMO it would be best to specify the "absolute path to the prefix" 
completely, and not rely on PATH at all!
Thanks, Steve

[U-Boot] buildman: using wrong libgcc.a (magic -3)

[Wolfgang Denk]

Dear Steve,

In message <545A7C54.30204@broadcom.com> you wrote:
> 
> Actually, that would be unfortunate, because I currently have:
> - /usr/bin/arm-linux-gnueabi-gcc
> - 
> /opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-gcc
> - (and others)
> installed on my machine....

This is pretty normal.

> If $PATH" was to "take care of it", then somehow $PATH would need to be 
> constantly "rearranged" so that the desired compiler is selected correctly.

Yes, this is what is supposed to happen, for a variety of reasons.
Often you select not only the compilers, but more o tools from a
specific "SDK" that way.

Usually there will be scripts that do all this for you; with ELDK,
that would be "eldk-switch".

> IMO it would be best to specify the "absolute path to the prefix" 
> completely, and not rely on PATH at all!

No, this is bound to fail.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The management question ... is not _whether_ to build a pilot  system
and  throw  it away. You _will_ do that. The only question is whether
to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers.       - Fred Brooks, "The Mythical Man Month"