Configure/make bug?

[Sergei Organov]

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.

>
> > ...
> > 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. Even if it were the case, I don't see how this can corrupt
native tool-chains.

>
> > checking whether the C compiler (/usr/local/bin/ppc-rtems-gcc  ) works... no
> > configure: error: installation or configuration problem: C compiler cannot create executables.
> > make[2]: *** [mbx860_002] Error 1
> > make[2]: Leaving directory `/home/osv/build/ppc-rtems/rtems/ppc-rtems/c'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/osv/build/ppc-rtems/rtems/ppc-rtems/c'
> > make: *** [all-recursive] Error 1
> >
> > Note, that error is because configure finds WRONG COMPILER. The right compiler
> > is under the '/home/osv/try' directory that is specified in --prefix option
> > for configure, and is correctly found (as well as the rest of tools) during
> > 'configure' stage or when I build another (papyrus) BSP.
> >
> > The same error occurs if I try to build 'mbx8xx' BSP.
> >
> > How do I fix this?
> I guess, your configuration options aren't set up correctly

Don't think so, because for 'papyrus' they work just fine.

>
> > I run configure/make in a separate build directory like this:
> >
> > ./config
> > ./makeit
> >
> > where config and makeit are the following scripts:
> >
> > $ cat config
> > prefix=/home/osv/try
> Don't name the variable prefix, it might interfere with the
> internals of the configury. This should not happen, but I have seen
> broken shells (older bash-2s, all versions of ash, /bin/sh under
> Solaris) or make (some versions of gmake) having problems with
> exporting/not-exporting shell variables.

Don't see any problem here because I don't export 'prefix', but thanks for
warning anyway.

>
> > export PATH=$prefix/bin:$PATH
> > ~/src/rtems-ss-20000919/configure \
> >   --target=ppc-rtems \
> >   --prefix=$prefix \
> >   --exec-prefix=ppc-rtems- \
> Remove this option ^, this very likely is the culprit.

If it were the problem, why does it work for 'papyrus' BSP then? This script
works fine if I just change 'mbx860_002' to 'papyrus' below in
--enable-rtemsbsp option. Moreover, if I first build 'papyrus', and then
'mbx860_002', then all works fine because configure gets right gcc from cache
created during 'papyrus' build! The problem should be somewhere in 'mbx'
files, I believe. BTW, notice that error is triggered after lines

Configuring RTEMS_BSP=mbx860_002
creating cache ./config.cache
...

so configure already begins to use mbx specific files, and only then the error
occurs.

Anyway, will remove this.

>
> >   --enable-gcc28 \
> >   --disable-posix \
> >   --disable-networking \
> >   --disable-itron \
> >   --enable-libcdir=$prefix/ppc-rtems/lib \
> This option ^ should not have any effect (be unused) when using
> --enable-gcc28 (which is the default), but should also not desturb.

Thanks, will remove both.

>
> >   --enable-maintainer-mode \
> >   --enable-rtemsbsp=mbx860_002 \
> >   $*
> >
> > $ cat makeit
> > export PATH=/home/osv/try/bin:$PATH
> > make $*

Thanks a lot,
Sergei Organov.