Configure/make bug?

[Ralf Corsepius]

Sergei Organov wrote:
> 
> Thanks for suggestions.
> 
> I've almost finished the answer and then went back to try your suggestion to
> remove --exec-prefix option. I first tried to run unmodified scripts again and
> suddenly they begin to work. Either your reply convinced my configuration
> tools that the right tools are in the '/home/osv/try' subdirectory, or phase
> of the moon has changed dramatically since my last attempt, I don't know. But
> error just disappeared.
> 
> Anyway, as I'm sure I changed nothing and there were an error before (that I
> just cut-and-copied to my mail), below are some explanations. If the problem
> re-appears, I'll try your suggestions to fix it.
> 
> Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:
> > Sergei Organov wrote:
> > >
> > > Hello,
> > >
> > > I'm trying to configure/build RTEMS (latest snapshot) for powerpc-rtems
> > > target on Linux host. When I configure/make for 'papyrus' BSP only, then
> > > everything works fine. If I configure/make for 'mbx860_002' BSP only, then
> > > configure runs fine, but make gives me the following:
> > >
> > Are you saying the configuration works for the papyrus BSP but
> > doesn't work for the mbx860_002, while using analogous configuration
> > options? I have never seen this happen before at this early stage of
> > the configuration, you are refering to, because the part is common
> > all BSPs of a target. It could happen in later stages, when
> > configuring BSP-specific parts of the sources and when something is
> > broken in a BSP-specific Makefile.
> 
> 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.
# echo $PATH
/opt/rtems/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/gnome/bin:/opt/kde/bin:/usr/openwin/bin:.

> >
> > > ...
> > > make[2]: Entering directory `/home/osv/build/ppc-rtems/rtems/ppc-rtems/c'
> > > Configuring RTEMS_BSP=mbx860_002
> > > creating cache ./config.cache
> > >
> > [..]
> > > checking for ppc-rtems-gcc... /usr/local/bin/ppc-rtems-gcc
> > Did build pcc-rtems-gcc to with --prefix=/usr/local?
> 
> There are multiple different ppc-rtems-gcc's installed in different
> directories. One of them indeed is under /usr/local, but for given
> configure/build I'd like to use another one that is located under
> /home/osv/try, that I give as --prefix for RTEMS configure.
> 
> >
> > I would not recommend to build gcc, binutils or newlib with
> > --prefix=/usr/local. There is a very high risk in corrupting your
> > native toolchain by doing so.
> 
> No, I'm using Debian, and all the native tools are in /usr, not in
> /usr/local.
Well Debian seems to be religious about /usr/local, but using
/opt/rtems is fully conformaning to the FHS, too and far easier to
maintain than /usr/local.

> Even if it were the case, I don't see how this can corrupt
> native tool-chains.

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.


Ralf
-- 
Ralf Corsepius 
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999  
http://www.faw.uni-ulm.de