Configure/make bug?

[Sergei Organov]

Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:
> Sergei Organov wrote:
[...]
> > Yes, I say that it works for the papyrus BSP but doesn't work for two other
> > BSPs I've tried: mbx8600_002 and mbx8xx. The fact that causes the problem is existence of
> > /usr/local/bin/ppc-rtems-gcc. I think that configure somehow was unable to
> > find 'ppc-rtems-gcc' in the '/home/osv/try/bin' directory on some stage, and
> > just took it from the default '/usr/local/bin' directory. Can't see how could
> > it depend on particular BSP though.
> 
> I can't reproduce this.
> 
> ~/rtems-4.5/configure \
> --target=powerpc-rtems \
> --prefix=/tmp/opt/rtems \
> --disable-posix \
> --enable-cxx \
> --disable-tests \
> --disable-networking \
> --disable-itron \
> --enable-multiprocessing \
> --enable-maintainer-mode \
> --enable-rtemsbsp="papyrus mbx860_002"
> 
> works perfectly for me.

Neither can I. Hopefully it was my mistake and not some glitch in
autoconf/automake/configure that shows up only every next Wednesday after full
moon :-)

To my pleasure now even my own just created BSP compiles smoothly.

[...]

> The problem is /usr/local/include and /usr/local/lib being special
> to a native gcc:
> 
> # gcc -o hello -v hello.c
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
>  /usr/lib/gcc-lib/i486-suse-linux/2.95.2/cpp -lang-c -v -D__GNUC__=2
> -D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__
> -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix)
> -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di486
> -D__i486 -D__i486__ hello.c /tmp/cc4KNFOO.i
> GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF)
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/lib/gcc-lib/i486-suse-linux/2.95.2/include
>  /usr/include
> End of search list.
> 
> => /usr/local/include has precedence over /usr/include.
> 
> Building the cross toolchain also installs some native files to
> $(prefix)/include and $(prefix)/lib, i.e. they will be used instead
> of the ones in /usr/include and /usr/lib and therefore can influence
> your system.
> 
> => If you'd install a package which has header conflicts with
> /usr/include, or install a different version of a package to
> /usr/local, which also is installed to /usr ... the files in
> /usr/local will have precedence over the files in /usr.

Well, now I see your point. Sure you are right it's better to avoid using of
'/usr' or '/usr/local' for cross tools. Thanks for explanations.

BR,
Sergei.