building rtems-cvs failed

Philippe Simons loki_666 at fastmail.fm
Wed May 11 18:01:12 UTC 2005


OK sorry all, I checked-out the cvs today, and build process completed.
Dont know what happened, thanks for your help.

Philippe

On Wed, 11 May 2005 06:59:02 +0200, "Ralf Corsepius"
<ralf.corsepius at rtems.org> said:
> On Tue, 2005-05-10 at 19:06 +0200, Philippe Simons wrote:
> > On Tue, 10 May 2005 07:03:19 +0200, "Ralf Corsepius"
> > <ralf.corsepius at rtems.org> said:
> > > On Mon, 2005-05-09 at 12:41 -0500, Joel Sherrill  wrote:
> > > > 
> > > > Philippe Simons wrote:
> > > > > this is for gcc
> > > > > ../gcc-4.0.0/configure --target=arm-rtems --with-gnu-as --with-gnu-ld
> > > > > --with-newlib --verbose --enable-threads --enable-languages="c,c++"
> > > > > --prefix=/opt/rtems-4.7 --disable-multilib --disable-interwork
> > > > > 
> > > > > and this is for rtems
> > > > > ../rtems/configure --target=arm-rtems --disable-posix
> > > > > --disable-networking --disable-cxx --disable-itron --disable-rdbg
> > > > > --enable-rtemsbsp=gp32 --prefix=/opt/rtems-4.7
> > > > 
> > > > Ralf, is this some odd type of configure/Makefile bug that is only 
> > > > manifested when some timestamps trick rpcgen into running?
> > > I guess so.
> > > 
> > > > I can't duplicate it.
> > > Neither can I.
> > > 
> > > ATM, I suspect this to be the result of several bugs interacting ...
> > > 
> > > 1. He reports not to be using --enable-rpcgen. Without it, the rpcgen
> > > generated programs are not supposed to be regenerated.
> > > 
> > > To be investigated, probably a bug in c/src/configure.ac.
> > > 
> > > 2. The error message indicates "cpp" complaining on "-B" options as part
> > > of the call to rpcgen, despite the fact that rpcgen does not pass these
> > > options to rpcgen.
> > > 
> > > This indicates the rpcgen Philippe is using is could be pulling these
> > > flags "from the air". The question is why and where (environment,
> > > Makefile, wrapper scripts?)
> > > 
> > > The only place "-B's" are used inside of the Makefile is as part of "CC"
> > > and "CPP", which would indicate Philippe's rpcgen being sensitive to one
> > > or more of these environment variables.
> > > 
> > > However, this would be non-documented behavior and also doesn't make
> > > sense, because rpcgen is supposed to be using nothing but /lib/cpp
> > > underneath.
> > > 
> > > Philippe, which OS are you using? Do you have CPP or CC explicitly set
> > > in your environment? Do you have any GCC variable set in your
> > > environment? Do you use any wrapper scripts to GCC?
> > > 
> > My box is a Gentoo 2005.0
> Well, this might explain a lot ;-)
> 
> >  running on amd64, here is my env
> > 
> > INFODIR=/usr/share/info
> > HOSTNAME=omega3000
> > SHELL=/bin/bash
> > TERM=xterm
> > ANT_HOME=/usr/share/ant-core
> > USER=root
> > PRELINK_PATH_MASK=/usr/lib/gstreamer-0.8
> > GDK_USE_XFT=1
> > PAGER=/usr/bin/less
> > CONFIG_PROTECT_MASK=/etc/gconf /etc/terminfo
> > XINITRC=/etc/X11/xinit/xinitrc
> > PATH=/opt/rtems-4.7/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/opt/ati/bin:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin
> > INPUTRC=/etc/inputrc
> > PWD=/root
> > JAVA_HOME=/opt/blackdown-jdk-1.4.2.01
> > EDITOR=/bin/nano
> > JAVAC=/opt/blackdown-jdk-1.4.2.01/bin/javac
> > PS1=\[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\]
> > JDK_HOME=/opt/blackdown-jdk-1.4.2.01
> > SHLVL=1
> > HOME=/root
> > LESS=-R
> > LOGNAME=root
> > CVS_RSH=ssh
> > GCC_SPECS=
> > CLASSPATH=.
> > LESSOPEN=|lesspipe.sh %s
> > INFOPATH=/usr/share/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.15.92.0.2/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.3/info
> > DISPLAY=:0.0
> > LADSPA_PATH=/usr/lib64/ladspa
> > OPENGL_PROFILE=ati
> > CONFIG_PROTECT=/usr/lib/X11/xkb
> > G_BROKEN_FILENAMES=1
> > XAUTHORITY=/root/.xauthRunSJa
> > _=/bin/env
> > 
> > what do you mean by a wrapper script?...
> A script around gcc to hard-code certain options to it. Some people use
> something of this kind to avoid having to pass options to gcc to it.
> 
> 
> And what does 
> "ls -l /lib/cpp"
> say?
> 
> > I reconfigured rtems with --disable-rpcgen option, and now build fails
> > with
> > Making all in librdbg
> > gmake[3]: Entering directory `/tmp/b-rtems/arm-rtems/c/gp32/librdbg'
> > gmake[3]: *** No rule to make target
> > `src/powerpc/new_exception_processing/remdeb.h', needed by `all'.  Stop.
> 
> This file is part of the sources, if it is missing, your cvs checkout is
> incomplete.
> 
> > > > > and here the full error
> > > > > gmake[3]: Entering directory `/tmp/b-rtems/arm-rtems/c/gp32/librdbg'
> > > > > rm -f
> > > > > ../../../../../rtems/c/src/librdbg/src/powerpc/new_exception_processing/remdeb.h;
> > > > > ( cd ../../../../../rtems/c/src/librdbg && \
> > > > > rpcgen -h -DFRONTEND=\"powerpc/new_exception_processing/remdeb_f.x\" \
> > > > >   -o src/powerpc/new_exception_processing/remdeb.h src/remdeb.x )
> All the code above should only be run with --enable-rpcgen enabled.
> 
> > > > > cpp: -B../../../lib/ -B../../../gp32/lib/: No such file or directory
> > > > > rpcgen: C preprocessor failed with exit code 1
> We still don't know why your rpcgen seems to use CC or CPP. 
> 
> Under linux, rpcgen is part of glibc2's sources. I had a look into
> glibc2's sources in its CVS and could not find trace of rpcgen being
> sensitive to CC or CPP. The same applies to FreeBSD, Cygwin and the
> original Sun rpcgen. AFAIS, none of them is using CC nor CPP nor any
> *FLAGS - If Gentoo's rpcgen does, it is broken.
> 
> Please send me your 
> arm-rtems4.7/c/gp32/config.status
> arm-rtems4.7/c/gp32/config.log
> arm-rtems4.7/c/gp32/librdbg/Makefile
> 
> which should exist in your build tree after configure had been run on
> PM.
> 
> Ralf
> 
> 



More information about the users mailing list