This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Re: File not found when running tests
On Mon, Mar 09, 2009 at 07:23:57PM +0200, Sergei Gavrikov wrote:
> On Mon, Mar 09, 2009 at 05:08:18PM +0000, John Dallaway wrote:
> > Hi Sergei
> >
> > Sergei Gavrikov wrote:
> >
> > > John Dallaway wrote:
> > >> Chris Holgate wrote:
> > >>
> > >>> The one configtool quirk I did notice was that while trying to run the
> > >>> tests from the GUI, they would occasionally fail with 'file not found'.
> > >>> This is all new to me, since i usually use GDB from the command line.
> > >>> The only file I can think of which 'comes and goes' in this way would be
> > >>> /dev/ttyS0 - or more specifically the lock on it - so I was wondering if
> > >>> this behaviour may be caused by GDB not releasing /dev/ttyS0 properly
> > >>> between tests. Is this something anyone else has seen?
> > >>
> > >> I have been testing against target pc_i82559 with a CentOS 5 host and
> > >> have not observed this issue. Has anyone else seen this?
> > >
> > > I noticed same sporadic messages on Ununtu 8.04.02. Target olpch2294,
> > > GDB port was /dev/ttyUSB0. But when I tried same build and same
> > > configtool on Ubuntu 7.10 I never got the errors. I think that my 8.04
> > > disto has mixed C++ environment. I need (and it is istalled) both
> > > libstdc++ (5 and 6) packages. And my old Ubuntu 7.10 uses libstdc++.so.5
> > > only.
> >
> > That is interesting. Chris Holgate was using openSUSE 11.0 which is also
> > very recent. Could you try running some eCos tests using configtool
> > under strace on Ubuntu 8.04? The strace output may reveal more about the
> > nature of this problem.
>
> John, thank you for the tip. Tonight I'll try to trace a run and then
> report about my diggs.
My guesswork aboud libstdc++ was wrong. I am/was sure that all arm gnu
tools in my PATH, but 'arm-eabi-gdb' does not run itself in configtool
21668 execve("arm-eabi-gdb", ["arm-eabi-gdb", "-nw", "-q", "/opt/testing/untitled_install/te"...], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
21668 execve("/bin/arm-eabi-gdb", ["arm-eabi-gdb", "-nw", "-q", "/opt/testing/untitled_install/te"...], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
21668 execve("/usr/bin/arm-eabi-gdb", ["arm-eabi-gdb", "-nw", "-q", "/opt/testing/untitled_install/te"...], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
21668 write(2, "exec error - No such file or dir"..., 39) = 39
...
Why I was sure? I sourced /opt/ecos/ecosenv.sh before to run configtool.
The 'which' found arm-eabi-gdb. I checked it.
... Just for fun I did fulfil
sudo ln -f -s /opt/ecos/gnutools/arm-eabi/bin/arm-eabi-gdb /usr/bin
then re-run configtool... and the problem went away.
Then I did remove that symlink and reduce my PATH variable to a classic
path
export PATH=/usr/sbin:/usr/bin:/sbin:/bin
. /opt/ecos/ecosenv.sh
echo $PATH
/opt/ecos/gnutools/i386-elf/bin:/opt/ecos/gnutools/arm-eabi/bin:/opt/ecos/ecos-3.0b1/tools/bin:/usr/sbin:/usr/bin:/sbin:/bin
which arm-eabi-gdb
/opt/ecos/gnutools/arm-eabi/bin/arm-eabi-gdb
which configtool
/opt/ecos/ecos-3.0b1/tools/bin/configtool
strace -f -o trace /opt/ecos/ecos-3.0b1/tools/bin/configtool
and the tests ran under configtool:
22084 execve("/opt/ecos/gnutools/arm-eabi/bin/arm-eabi-gdb", ["arm-eabi-gdb", "-nw", "-q", "/opt/testing/untitled_install/te"...], [/* 39 vars */]) = 0
22084 brk(0) = 0x8324000
Hmm. Is it possible that my original PATH too long?
/home/sg/bin:/home/sg/ecos/gnutools/arm-eabi/bin:/home/sg/ecos/gnutools/i386-elf/bin:/home/sg/ecos/tools/bin:/opt/TclDevKit-5.0/bin:/opt/ActiveTcl-8.5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Once again, I sourced 'ecosenv.sh' before to run 'configtool'. I have no
ecos stuff under /usr/local. The same tools are placed under my
~/ecos/gnutools directory. And I am/was? sure that 'ecosenv.sh'
overwrites it.
My conclusion, configtool _has_no_bug_. IMHO, it should work on the
fresh-installed systems. Now, I wonder, What's about openSuSE?
Regards,
Sergei
P.S.
Once again I did think about non-existing eCos 3.0 vmware appliance for
linux. It would justify the results :-)
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss