Re: [ECOS] A hello world problem

Re: [ECOS] A hello world problem

[Fano Ramparany]

Did you try the Makefile provided in the same directory than hello.c?
I used it w/o any pb.

Fano

Re: [ECOS] A hello world problem

[Lewin A.R.W. Edwards]

>Looking at the relevant header file, it appears to be the following
>macro that is causing the problem:

Right, I looked at it but couldn't deduce the nature of the problem. Your 
answer fixed it; thank you! Sorry for not RTFMing well enough. I probably 
glossed over the page you mentioned when I was first downloading 
everything, then once I hit problems building gcc I read 
< http://sources.redhat.com/ecos/faq.html > and I thought I would make life 
simple and uniform by changing all my mounts to binary.

Now, I'm back to work!

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] A hello world problem

[Bart Veer]

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:

    Lewin> In file included from ../ecos_work/DigiOS_install/include/stdio.h:56, from 
    Lewin> hello.c:1:
    Lewin> ../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: parse error 
    Lewin> before '__tmp1'
    Lewin> ../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: '_name_' 
    Lewin> undeclared here (not in a function)
    Lewin> ../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: warning: data 
    Lewin> definition has no type or storage class
    Lewin> ../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: stray '\' in 
    Lewin> program

    Lewin> [and many more errors]

    Lewin> Can anyone help? This is using a "canonical" installation of eCos cygwin 
    Lewin> arm-elf, ie binutils 2.10 and gcc 2.95.2, and eCos 1.3.1 so it ought to work.

Looking at the relevant header file, it appears to be the following
macro that is causing the problem:

#define CYG_UNUSED_PARAM( _type_, _name_ ) CYG_MACRO_START      \
  _type_ __tmp1 = (_name_);                                     \
  _type_ __tmp2 = __tmp1;                                       \
  __tmp1 = __tmp2;                                              \
CYG_MACRO_END

Note the backslashes at the end of the line. The error messages you
are seeing are a sure sign that they are ignored, i.e. there is junk
data at the end of the line. Under Windows the most likely problem is
that you are using a file containing carriage-return/linefeed pairs
via a binary mount point. The eCos sources and build trees should be
kept on a text mount point. The sources as supplied contain carriage
returns for the benefit of any Windows users who want to use utilities
like notepad. The instructions for installing under Windows,
http://sources.redhat.com/ecos/install-windows.html ,
specifically mention text mount points.

See e.g.
http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00283.html and
http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00297.html for
an earlier discussion.

Bart

Re: [ECOS] A hello world problem

[Lewin A.R.W. Edwards]

>pass -v to gcc. It will then verbosly tell you exactly what its
>calling. Here is your hello world program compiled with my setup on a
>linux box. You can see which cpp, cc1, as and collect2 it is using.

Hmmm.

OK, I tried this, and is calling the right cc1.exe. So does anyone have any 
idea what is going on? Someone must have done this, surely?

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] A hello world problem

[Andrew Lunn]

> With your method above, what happens when gcc calls the assembler and 
> linker? I guess (or rather worry) that it will just call 'as' or 'ld' and 
> then would hit the native ones, which is why I put the /arm-elf/bin dir at 
> the head of the path.

pass -v to gcc. It will then verbosly tell you exactly what its
calling. Here is your hello world program compiled with my setup on a
linux box. You can see which cpp, cc1, as and collect2 it is using.

        Andrew

lunn@tux:~$ arm-elf-gcc -v -I/usr/local/pkg/plcuts/ecos-work-sa-1.4.4/install/include hello.c -L/usr/local/pkg/plcuts/ecos-work-sa-1.4.4/install/lib -T target.ld -nostdlib
Reading specs from /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/specs
gcc version 2.9-ecos-99r1-001005
 /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/cpp -lang-c -v -I/usr/local/pkg/plcuts/ecos-work-sa-1.4.4/install/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=9 -Darm -Darm_elf -D__ELF__ -D__arm__ -D__arm_elf__ -D__ELF__ -D__arm -D__arm_elf -Acpu(arm) -Amachine(arm) -D__CHAR_UNSIGNED__ -D__ARM_ARCH_4T__ -D__APCS_32__ hello.c /tmp/ccYWYS8l.i
GNU CPP version 2.9-ecos-99r1-001005 (ARM/ELF non-Linux)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/pkg/plcuts/ecos-work-sa-1.4.4/install/include
 /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/include
 /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/../../../../arm-elf/include
End of search list.
 /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/cc1 /tmp/ccYWYS8l.i -quiet -dumpbase hello.c -version -o /tmp/ccy4dY5C.s
GNU C version 2.9-ecos-99r1-001005 (arm-elf) compiled by GNU C version 2.7.2.3.
 /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/../../../../arm-elf/bin/as -o /tmp/cckOjESV.o /tmp/ccy4dY5C.s
 /usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/collect2 -X -L/usr/local/pkg/plcuts/ecos-work-sa-1.4.4/install/lib -L/usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005 -L/usr/local/pkg/H686-arm-elf-1.4.4/lib/gcc-lib/arm-elf/2.9-ecos-99r1-001005/../../../../arm-elf/lib /tmp/cckOjESV.o -T target.ld

Re: [ECOS] A hello world problem

[Lewin A.R.W. Edwards]

>Linux. Having said that im supprised to see the DigiOS_ bit. My
>directories are always without such a prefix. Its a long time since i
>read the instructions. Does it suggest you give the ecc config file a
>name such as DigiOS? Mine is always ecos.ecc.

Well, no - the save as dialog specified "Untitled.ecc" and so I typed 
DigiOS. Not a big deal.

>arm-elf-gcc -g -I\ARMDigi\ecos_work\DigiOS_install\include hello.c -L 
>\ARMDigi\ecos_work\DigiOS_install\lib -Ttarget.ld -nostdlib
>
>Note the arm-elf-gcc not gcc. Without that it may still use the native
>compiler.

With your method above, what happens when gcc calls the assembler and 
linker? I guess (or rather worry) that it will just call 'as' or 'ld' and 
then would hit the native ones, which is why I put the /arm-elf/bin dir at 
the head of the path.

Why does the gcc build process make two copies of the tools anyway, with 
different names? (one set in /[host]/bin has names starting with the 
target, eg arm-elf-gcc, the other set is in /[host]/[target]/shortnames, 
e.g. /[host]/arm-elf/gcc). Baffling.

>See if that makes any difference? The other thing to check is the way

The only difference is that this time I can't use the scroll lock key to 
pause the output. Same errors. My command line isn't quite the same as 
yours though, since '/' is not the root directory of the drive. It's the 
same as yours except instead of /ARMDigi it is /c/ARMDigi.

hello.c is just cut and pasted from the tutorial :

#include <stdio.h>
int main(void)
{
printf("test\n");
return 0;
}

>you have the file systems mounted. Some bits have to be mounted text
>mode and other binary. Since i unix with grown up line endings i never

All my mount points are binmode. All my files should have UNIX EOL 
conventions... or what? The docs only talk about being careful that object 
paths are mounted binary, they don't say that certain paths need to be 
textmode!

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

Re: [ECOS] A hello world problem

[Andrew Lunn]

> Now I have a directory structure like this:
> 
> c:\ARMDigi - tidy dir to hold all project files
> c:\ARMDigi\ecos_work - eCos build dir
> c:\ARMDigi\ecos_work\DigiOS_build
> c:\ARMDigi\ecos_work\DigiOS_install
> c:\ARMDigi\ecos_work\DigiOS_mlt
> c:\OS3\hello.c

I don't use the GUI, i stick to the nice and friendly CLI on
Linux. Having said that im supprised to see the DigiOS_ bit. My
directories are always without such a prefix. Its a long time since i
read the instructions. Does it suggest you give the ecc config file a
name such as DigiOS? Mine is always ecos.ecc.
 
> The ecos-tutorial-arm.pdf file says that to make the hello world app, I 
> should use the command line "gcc -g -IBASE_DIR/ecos-work/install/include 
> hello.c -LBASE_DIR/ecos-work/install/lib -Ttarget.ld -nostdlib". OK, first 
> problem there - that commandline will run the _native target_ gcc, not the 
> cross-compiler, given the step above. Second problem - the "/install/" path 
> fragment is obviously wrong, since the build process appears to prepend the 
> .ecc's filename to the output directories when it's building the object tree.
> 
> So instead I add /tools/H-i686-pc-cygwin/arm-elf/bin to the head of PATH, 
> and replace "/install/" with "/DigiOS_install/" in the command line above, 
> and now I get:

That looks nearly right. I would of used 

arm-elf-gcc -g -I\ARMDigi\ecos_work\DigiOS_install\include hello.c -L \ARMDigi\ecos_work\DigiOS_install\lib -Ttarget.ld -nostdlib

Note the arm-elf-gcc not gcc. Without that it may still use the native
compiler.

See if that makes any difference? The other thing to check is the way
you have the file systems mounted. Some bits have to be mounted text
mode and other binary. Since i unix with grown up line endings i never
looked into this.

        Andrew

[ECOS] A hello world problem

[Lewin A.R.W. Edwards]

Well, I've been attacking the attempt to get a hello world app built for 
three hours, time to ask for help I think because at the least this 
uncovers some inconsistency in the documentation. This is not strictly an 
eCos question, more a gcc/bash/whoknowswhat type problem. Using Cygwin 
environment at the moment, building for arm-elf. eCos builds fine using the 
graphical config tool.

Now I have a directory structure like this:

c:\ARMDigi - tidy dir to hold all project files
c:\ARMDigi\ecos_work - eCos build dir
c:\ARMDigi\ecos_work\DigiOS_build
c:\ARMDigi\ecos_work\DigiOS_install
c:\ARMDigi\ecos_work\DigiOS_mlt
c:\OS3\hello.c

I open bash to start the build. The tools build/install instructions said I 
should add /tools/H-i686-pc-cygwin/bin to head of PATH, so I do it.

The ecos-tutorial-arm.pdf file says that to make the hello world app, I 
should use the command line "gcc -g -IBASE_DIR/ecos-work/install/include 
hello.c -LBASE_DIR/ecos-work/install/lib -Ttarget.ld -nostdlib". OK, first 
problem there - that commandline will run the _native target_ gcc, not the 
cross-compiler, given the step above. Second problem - the "/install/" path 
fragment is obviously wrong, since the build process appears to prepend the 
.ecc's filename to the output directories when it's building the object tree.

So instead I add /tools/H-i686-pc-cygwin/arm-elf/bin to the head of PATH, 
and replace "/install/" with "/DigiOS_install/" in the command line above, 
and now I get:

In file included from ../ecos_work/DigiOS_install/include/stdio.h:56, from 
hello.c:1:
../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: parse error 
before '__tmp1'
../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: '_name_' 
undeclared here (not in a function)
../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: warning: data 
definition has no type or storage class
../ecos_work/DigiOS_install/include/cyg/infra/cyg_type.h:160: stray '\' in 
program

[and many more errors]

Can anyone help? This is using a "canonical" installation of eCos cygwin 
arm-elf, ie binutils 2.10 and gcc 2.95.2, and eCos 1.3.1 so it ought to work.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/