[ECOS] Synthetic target on linux x86_64 host

[ECOS] Synthetic target on linux x86_64 host

[Tarmo Kuuse]

Hi!

I've been trying get vanilla synthetic target up and running on 64-bit 
Debian testing. It's definitely a painful experience (well, more than 
usual). Is this host platform unsupported?

This is what I did:

1. Getting tools and code

I installed eCos with i386-elf tools as described in 
http://ecos.sourceware.org/getstart.html.

I also fetched fresh source from anonymous CVS and set $ECOS_REPOSITORY 
to point to it.

2. Prepations

Started configtool, verified repository (OK, set to anoncvs).

Picked default template "Linux synthetic target".

3. Building the library

Configtools shows that global command prefix is "i686-pc-linux-gnu". WTF 
is that?

I remove the command prefix entirely to build with my native gcc 
toolchain (Debian 4.3.3-3).

Generate tree, OK. Press F7 to build library, it fails.

Build is missing cc1plus:
http://people.proekspert.ee/tarmok/ecos/build_ecos_in_configtool.txt

Why does that happen? Some environment problem maybe?

I open a shell, navigate to build directory, delete it, build tree, type 
in commmand "make -j4". It fails.

Build now chokes on some pointer casts:
http://people.proekspert.ee/tarmok/ecos/build_ecos_from_shell.txt

Can synthetic target even be built with native x86_64 tools?

--
Kind regards,
Tarmo Kuuse


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Synthetic target on linux x86_64 host

[Andrew Lunn]

> Can synthetic target even be built with native x86_64 tools?

I don't think so. Synth calls kernel system calls directly, using
assembly language. I expect this part needs re-writing into 64 bit
code.

Also, eCos is very much used on 32 bit systems. I don't know of
anybody using it on 64 bit systems. You are bound to run into problems
with assumptions that sizeof(int)==4 etc. However synth probably is a
good platform to find and fix some of these, once you have done the
basic HAL port.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Synthetic target on linux x86_64 host

[Tarmo Kuuse]

Andrew Lunn wrote:
>> Can synthetic target even be built with native x86_64 tools?
> 
> I don't think so. Synth calls kernel system calls directly, using
> assembly language. I expect this part needs re-writing into 64 bit
> code.

That is a bit surprising - I assumed the synthetic target was just 
another application from the compiler's side.

Anyway it is good to have a clear answer. Thanks.

> Also, eCos is very much used on 32 bit systems. I don't know of
> anybody using it on 64 bit systems. You are bound to run into problems
> with assumptions that sizeof(int)==4 etc. However synth probably is a
> good platform to find and fix some of these, once you have done the
> basic HAL port.

I don't know anything about the x86 or (shudder) x86-64 bowels and would 
prefer to live a long and sane life by keeping it that way :)

--
Kind regards,
Tarmo Kuuse


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Synthetic target on linux x86_64 host

[Andrew Lunn]

On Sun, May 03, 2009 at 12:44:13AM +0300, Tarmo Kuuse wrote:
> Andrew Lunn wrote:
>>> Can synthetic target even be built with native x86_64 tools?
>>
>> I don't think so. Synth calls kernel system calls directly, using
>> assembly language. I expect this part needs re-writing into 64 bit
>> code.
>
> That is a bit surprising - I assumed the synthetic target was just  
> another application from the compiler's side.

From the compiler, yes, its just an application. However because eCos
has a libc, you cannot use the native libc as the interface to the
native kernel. You have to call the kernel directly. Hence the system
call issues.

> I don't know anything about the x86 or (shudder) x86-64 bowels and would  
> prefer to live a long and sane life by keeping it that way :)

Then take a look at x86 emulators which you can run on 32 bit more on
top of a 64 bit system. eg http://bochs.sourceforge.net/

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Synthetic target on linux x86_64 host

[Ross Younger]

Tarmo Kuuse wrote:
> Can synthetic target even be built with native x86_64 tools?

As Andrew has said it's not a supported environment - synth predates x86_64 
by some years - and I suspect would require a proper porting effort in due 
course.

However, I did find myself poking at the synth target on my workstation a 
few weeks ago (Ubuntu 8.10, 64-bit) and was able to get it going, after a 
fashion, without very much trouble (and without having to know much about 
x86/x86_64 guts!) in order to play with some new code I was writing.

I was using the eCos i386-elf toolchain; the syscalls and so on all seemed 
to just work thanks to x86_64's backwards compatibility (and I have various 
32-bit compatibility libs installed, which may or may not have helped).

I manually configured my ecos.ecc to use i386-elf, and once I had built eCos 
I had to edit target.ld by hand and remove the mention of libgcc_eh.a in 
order for my test applications to link. For debugging, the native gdb (not 
i386-elf-gcc!) just worked.

Obviously, running synth cross-architecture in this way is not tested at all 
- it seemed to work for my limited purposes, and might for you, but if it 
breaks you get to keep both pieces :-)


Ross

-- 
eCosCentric Ltd, Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK
Registered in England no. 4422071.                 www.ecoscentric.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Synthetic target on linux x86_64 host

[Nick Garnett]

Ross Younger <wry@ecoscentric.com> writes:

> Tarmo Kuuse wrote:
> > Can synthetic target even be built with native x86_64 tools?
> 
> As Andrew has said it's not a supported environment - synth predates
> x86_64 by some years - and I suspect would require a proper porting
> effort in due course.
> 
> However, I did find myself poking at the synth target on my
> workstation a few weeks ago (Ubuntu 8.10, 64-bit) and was able to get
> it going, after a fashion, without very much trouble (and without
> having to know much about x86/x86_64 guts!) in order to play with some
> new code I was writing.
> 
> I was using the eCos i386-elf toolchain; the syscalls and so on all
> seemed to just work thanks to x86_64's backwards compatibility (and I
> have various 32-bit compatibility libs installed, which may or may not
> have helped).
> 
> I manually configured my ecos.ecc to use i386-elf, and once I had
> built eCos I had to edit target.ld by hand and remove the mention of
> libgcc_eh.a in order for my test applications to link. For debugging,
> the native gdb (not i386-elf-gcc!) just worked.
> 
> Obviously, running synth cross-architecture in this way is not tested
> at all - it seemed to work for my limited purposes, and might for you,
> but if it breaks you get to keep both pieces :-)


I have also been running the synthetic target on my OpenSuSE 11.0
x86_64 system. I can do this without making any changes to eCos
sources at all.

I compile using the native "gcc" compiler, adding the -m32 flag. The
default configuration tries to use i686-pc-linux-gnu-gcc, so I have
put a script of that name in my path that simply contains the line
"gcc -m32 $*". I have also had to define i686-pc-linux-gnu-ar to "ar
$*". Those are the only two tools used during a build, and the
standard native "gdb" then works to debug.

Like Ross, I have the 32 bit compatibility libraries installed,
together with the development packages for some. eCos synthetic target
executables are not dynamically linked, so it may be necessary to
install the static versions of libraries you already have in dynamic
form. I simply used trial and error to work out which libraries were
needed: try a build, work out which header or library is missing, find
out which RPM it comes from, install that and repeat. The exact
combination will obviously depend on how a specific distribution
divided things up into packages, and what you might already have
installed.


-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Synthetic target on linux x86_64 host

[Tarmo Kuuse]

Andrew Lunn wrote:
> On Sun, May 03, 2009 at 12:44:13AM +0300, Tarmo Kuuse wrote:
>> Andrew Lunn wrote:
>>>> Can synthetic target even be built with native x86_64 tools?
>>> I don't think so. Synth calls kernel system calls directly, using
>>> assembly language. I expect this part needs re-writing into 64 bit
>>> code.
>> That is a bit surprising - I assumed the synthetic target was just  
>> another application from the compiler's side.
> 
> From the compiler, yes, its just an application. However because eCos
> has a libc, you cannot use the native libc as the interface to the
> native kernel. You have to call the kernel directly. Hence the system
> call issues.
> 
>> I don't know anything about the x86 or (shudder) x86-64 bowels and would  
>> prefer to live a long and sane life by keeping it that way :)
> 
> Then take a look at x86 emulators which you can run on 32 bit more on
> top of a 64 bit system. eg http://bochs.sourceforge.net/

I now have a 32-bit Debian system running inside VirtualBox on my 64-bit 
Debian system. Synthetic target works as expected, host tools for 
Ethernet can be built, etc.

I suspected it would end up like this when starting...

--
Kind regards,
Tarmo Kuuse


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Synthetic target on linux x86_64 host

[Tarmo Kuuse]

Thanks for the tips.

Unfortunately I also host tools like rawether et al (no, they don't 
build either). eCos+gcc is a damn complex system and I don't have time 
(nor motivation, nor skill) for hacking it - when something breaks, 
result is pain, pain, pain. I'll just use a 32-bit environment.

Nick Garnett wrote:
> Ross Younger <wry@ecoscentric.com> writes:
> 
>> Tarmo Kuuse wrote:
>>> Can synthetic target even be built with native x86_64 tools?
>> As Andrew has said it's not a supported environment - synth predates
>> x86_64 by some years - and I suspect would require a proper porting
>> effort in due course.
>>
>> However, I did find myself poking at the synth target on my
>> workstation a few weeks ago (Ubuntu 8.10, 64-bit) and was able to get
>> it going, after a fashion, without very much trouble (and without
>> having to know much about x86/x86_64 guts!) in order to play with some
>> new code I was writing.
>>
>> I was using the eCos i386-elf toolchain; the syscalls and so on all
>> seemed to just work thanks to x86_64's backwards compatibility (and I
>> have various 32-bit compatibility libs installed, which may or may not
>> have helped).
>>
>> I manually configured my ecos.ecc to use i386-elf, and once I had
>> built eCos I had to edit target.ld by hand and remove the mention of
>> libgcc_eh.a in order for my test applications to link. For debugging,
>> the native gdb (not i386-elf-gcc!) just worked.
>>
>> Obviously, running synth cross-architecture in this way is not tested
>> at all - it seemed to work for my limited purposes, and might for you,
>> but if it breaks you get to keep both pieces :-)
> 
> 
> I have also been running the synthetic target on my OpenSuSE 11.0
> x86_64 system. I can do this without making any changes to eCos
> sources at all.
> 
> I compile using the native "gcc" compiler, adding the -m32 flag. The
> default configuration tries to use i686-pc-linux-gnu-gcc, so I have
> put a script of that name in my path that simply contains the line
> "gcc -m32 $*". I have also had to define i686-pc-linux-gnu-ar to "ar
> $*". Those are the only two tools used during a build, and the
> standard native "gdb" then works to debug.
> 
> Like Ross, I have the 32 bit compatibility libraries installed,
> together with the development packages for some. eCos synthetic target
> executables are not dynamically linked, so it may be necessary to
> install the static versions of libraries you already have in dynamic
> form. I simply used trial and error to work out which libraries were
> needed: try a build, work out which header or library is missing, find
> out which RPM it comes from, install that and repeat. The exact
> combination will obviously depend on how a specific distribution
> divided things up into packages, and what you might already have
> installed.

I admire the clever solutions. When the linker dies because something 
called "libgcc_eh.a" is missing I assume it's a sign from the gods 
saying it's not meant to build.

--
Kind regards,
Tarmo Kuuse


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Synthetic target on linux x86_64 host

[Sergei Gavrikov]

On Sun, May 03, 2009 at 11:09:45PM +0300, Tarmo Kuuse wrote:
> Thanks for the tips.
> 
> Unfortunately I also host tools like rawether et al (no, they don't 
> build either). eCos+gcc is a damn complex system and I don't have time 
> (nor motivation, nor skill) for hacking it - when something breaks, 
> result is pain, pain, pain. I'll just use a 32-bit environment.
> 
> Nick Garnett wrote:
> >Ross Younger <wry@ecoscentric.com> writes:
> >
> >>Tarmo Kuuse wrote:
> >>>Can synthetic target even be built with native x86_64 tools?
> >>As Andrew has said it's not a supported environment - synth predates
> >>x86_64 by some years - and I suspect would require a proper porting
> >>effort in due course.
> >>
> >>However, I did find myself poking at the synth target on my
> >>workstation a few weeks ago (Ubuntu 8.10, 64-bit) and was able to get
> >>it going, after a fashion, without very much trouble (and without
> >>having to know much about x86/x86_64 guts!) in order to play with some
> >>new code I was writing.
> >>
> >>I was using the eCos i386-elf toolchain; the syscalls and so on all
> >>seemed to just work thanks to x86_64's backwards compatibility (and I
> >>have various 32-bit compatibility libs installed, which may or may not
> >>have helped).
> >>
> >>I manually configured my ecos.ecc to use i386-elf, and once I had
> >>built eCos I had to edit target.ld by hand and remove the mention of
> >>libgcc_eh.a in order for my test applications to link. For debugging,
> >>the native gdb (not i386-elf-gcc!) just worked.
> >>
> >>Obviously, running synth cross-architecture in this way is not tested
> >>at all - it seemed to work for my limited purposes, and might for you,
> >>but if it breaks you get to keep both pieces :-)
> >
> >
> >I have also been running the synthetic target on my OpenSuSE 11.0
> >x86_64 system. I can do this without making any changes to eCos
> >sources at all.
> >
> >I compile using the native "gcc" compiler, adding the -m32 flag. The
> >default configuration tries to use i686-pc-linux-gnu-gcc, so I have
> >put a script of that name in my path that simply contains the line
> >"gcc -m32 $*". I have also had to define i686-pc-linux-gnu-ar to "ar
> >$*". Those are the only two tools used during a build, and the
> >standard native "gdb" then works to debug.
> >
> >Like Ross, I have the 32 bit compatibility libraries installed,
> >together with the development packages for some. eCos synthetic target
> >executables are not dynamically linked, so it may be necessary to
> >install the static versions of libraries you already have in dynamic
> >form. I simply used trial and error to work out which libraries were
> >needed: try a build, work out which header or library is missing, find
> >out which RPM it comes from, install that and repeat. The exact
> >combination will obviously depend on how a specific distribution
> >divided things up into packages, and what you might already have
> >installed.
> 
> I admire the clever solutions. When the linker dies because something 
> called "libgcc_eh.a" is missing I assume it's a sign from the gods 
> saying it's not meant to build.
 
Often gods do not notice some things at all. To err is human. Tarno, it
seemed for me that you won't like a receipt the below, but, that would
be a useful for some atheists.

I use the wellknown variables and stream editor to play with eCos synth
target using the prebuilt i386-elf toolchain from eCosCentric

    ecosconfig new linux
    ecosconfig tree

    # No tweaks of ecos.ecc, let use vars
    make CC=i386-elf-gcc AR=i386-elf-ar

    # Is it a trick? Well, it is.
    sed -i 's/ libgcc_eh.a//' install/lib/target.ld

The sed has one nice option `-i' (edit files in place)

    $ head -4 install/lib/target.ld 
    STARTUP(vectors.o)
    ENTRY(_start)
    INPUT(extras.o)
    GROUP(libtarget.a libgcc.a libsupc++.a)


Then using the same parameters I can build the tests, etc.

    make CC=i386-elf-gcc AR=i386-elf-ar -C kernel/current tests

and play with them using native host's GDB

    gdb -q install/tests/kernel/current/tests/tm_basic


Of course, you can have something like such an alias the below to play
with synth target in ... a bash

    alias maksyn='make CC=i386-elf-gcc AR=i386-elf-ar'

or to use a scripting...


Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Synthetic target on linux x86_64 host

[Tarmo Kuuse]

Sergei Gavrikov wrote:
> On Sun, May 03, 2009 at 11:09:45PM +0300, Tarmo Kuuse wrote:
>> Thanks for the tips.
>>
>> Unfortunately I also host tools like rawether et al (no, they don't 
>> build either). eCos+gcc is a damn complex system and I don't have time 
>> (nor motivation, nor skill) for hacking it - when something breaks, 
>> result is pain, pain, pain. I'll just use a 32-bit environment.
>>
>> Nick Garnett wrote:
>>> Ross Younger <wry@ecoscentric.com> writes:
>>>
>>>> Tarmo Kuuse wrote:
>>>>> Can synthetic target even be built with native x86_64 tools?
>>>> As Andrew has said it's not a supported environment - synth predates
>>>> x86_64 by some years - and I suspect would require a proper porting
>>>> effort in due course.
>>>>
>>>> However, I did find myself poking at the synth target on my
>>>> workstation a few weeks ago (Ubuntu 8.10, 64-bit) and was able to get
>>>> it going, after a fashion, without very much trouble (and without
>>>> having to know much about x86/x86_64 guts!) in order to play with some
>>>> new code I was writing.
>>>>
>>>> I was using the eCos i386-elf toolchain; the syscalls and so on all
>>>> seemed to just work thanks to x86_64's backwards compatibility (and I
>>>> have various 32-bit compatibility libs installed, which may or may not
>>>> have helped).
>>>>
>>>> I manually configured my ecos.ecc to use i386-elf, and once I had
>>>> built eCos I had to edit target.ld by hand and remove the mention of
>>>> libgcc_eh.a in order for my test applications to link. For debugging,
>>>> the native gdb (not i386-elf-gcc!) just worked.
>>>>
>>>> Obviously, running synth cross-architecture in this way is not tested
>>>> at all - it seemed to work for my limited purposes, and might for you,
>>>> but if it breaks you get to keep both pieces :-)
>>>
>>> I have also been running the synthetic target on my OpenSuSE 11.0
>>> x86_64 system. I can do this without making any changes to eCos
>>> sources at all.
>>>
>>> I compile using the native "gcc" compiler, adding the -m32 flag. The
>>> default configuration tries to use i686-pc-linux-gnu-gcc, so I have
>>> put a script of that name in my path that simply contains the line
>>> "gcc -m32 $*". I have also had to define i686-pc-linux-gnu-ar to "ar
>>> $*". Those are the only two tools used during a build, and the
>>> standard native "gdb" then works to debug.
>>>
>>> Like Ross, I have the 32 bit compatibility libraries installed,
>>> together with the development packages for some. eCos synthetic target
>>> executables are not dynamically linked, so it may be necessary to
>>> install the static versions of libraries you already have in dynamic
>>> form. I simply used trial and error to work out which libraries were
>>> needed: try a build, work out which header or library is missing, find
>>> out which RPM it comes from, install that and repeat. The exact
>>> combination will obviously depend on how a specific distribution
>>> divided things up into packages, and what you might already have
>>> installed.
>> I admire the clever solutions. When the linker dies because something 
>> called "libgcc_eh.a" is missing I assume it's a sign from the gods 
>> saying it's not meant to build.
>  
> Often gods do not notice some things at all. To err is human. Tarno, it
> seemed for me that you won't like a receipt the below, but, that would
> be a useful for some atheists.
> 
> I use the wellknown variables and stream editor to play with eCos synth
> target using the prebuilt i386-elf toolchain from eCosCentric
> 
>     ecosconfig new linux
>     ecosconfig tree
> 
>     # No tweaks of ecos.ecc, let use vars
>     make CC=i386-elf-gcc AR=i386-elf-ar
> 
>     # Is it a trick? Well, it is.
>     sed -i 's/ libgcc_eh.a//' install/lib/target.ld
> 
> The sed has one nice option `-i' (edit files in place)
> 
>     $ head -4 install/lib/target.ld 
>     STARTUP(vectors.o)
>     ENTRY(_start)
>     INPUT(extras.o)
>     GROUP(libtarget.a libgcc.a libsupc++.a)
> 
> 
> Then using the same parameters I can build the tests, etc.
> 
>     make CC=i386-elf-gcc AR=i386-elf-ar -C kernel/current tests
> 
> and play with them using native host's GDB
> 
>     gdb -q install/tests/kernel/current/tests/tm_basic
> 
> 
> Of course, you can have something like such an alias the below to play
> with synth target in ... a bash
> 
>     alias maksyn='make CC=i386-elf-gcc AR=i386-elf-ar'
> 
> or to use a scripting...

I humbly suggest updating the FAQ or documentation with a note on 64-bit 
hosts (and the solid know-how provided by previous posters so novices 
have at least a dim glow in the black of night).

OT: Have the eCos web site maintainers ever considered adding a wiki?

--
Kind regards,
Tarmo Kuuse


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Synthetic target on linux x86_64 host

[Bart Veer]

>>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes:

    <snip>
    Nick> I have also been running the synthetic target on my OpenSuSE
    Nick> 11.0 x86_64 system. I can do this without making any changes
    Nick> to eCos sources at all.

    Nick> I compile using the native "gcc" compiler, adding the -m32
    Nick> flag. The default configuration tries to use
    Nick> i686-pc-linux-gnu-gcc, so I have put a script of that name
    Nick> in my path that simply contains the line "gcc -m32 $*". I
    Nick> have also had to define i686-pc-linux-gnu-ar to "ar $*".
    Nick> Those are the only two tools used during a build, and the
    Nick> standard native "gdb" then works to debug.

Interesting. That suggest something like the following patch should
sort out the target-side:

Index: hal_synth_i386.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/synth/i386linux/current/cdl/hal_synth_i386.cdl,v
retrieving revision 1.7
diff -u -p -r1.7 hal_synth_i386.cdl
--- hal_synth_i386.cdl2 Feb 2009 17:56:43 -00001.7
+++ hal_synth_i386.cdl7 May 2009 11:32:31 -0000
@@ -104,7 +104,9 @@ cdl_package CYGPKG_HAL_SYNTH_I386 {
             display "Global command prefix"
             flavor  data
             no_define
-    if { ($tcl_platform(os) == "Linux") && [string match "i*86" $tcl_platform(machine)] } {
+    if { ($tcl_platform(os) == "Linux") &&
+             ([string match "i*86" $tcl_platform(machine)] ||
	       +              [string match "x86_64" $tcl_platform(machine)]) } {
default_value { "" }
    } else {
default_value { "i686-pc-linux-gnu" }
@@ -120,7 +122,9 @@ cdl_package CYGPKG_HAL_SYNTH_I386 {
             display "Global compiler flags"
             flavor  data
             no_define
-            default_value { CYGBLD_GLOBAL_WARNFLAGS . " -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions " }
+            default_value { CYGBLD_GLOBAL_WARNFLAGS .
+                ([string match "x86_64" $tcl_platform(machine)] ? " -m32" : "") .
+                " -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions " }
             description   "
                 This option controls the global compiler flags which
                 are used to compile all packages by
@@ -132,7 +136,8 @@ cdl_package CYGPKG_HAL_SYNTH_I386 {
             display "Global linker flags"
             flavor  data
             no_define
-            default_value { "-g -nostdlib -Wl,--gc-sections -Wl,-static" }
+            default_value { ([string match "x86_64" $tcl_platform(machine)] ? "-m32 " : "") .
+                "-g -nostdlib -Wl,--gc-sections -Wl,-static" }
             description   "
                 This option controls the global linker flags. Individual
                 packages may define options which override these global flags."

Possibly the -m32 should be a hard requirement, not just a default
setting.

    Nick> Like Ross, I have the 32 bit compatibility libraries
    Nick> installed, together with the development packages for some.
    Nick> eCos synthetic target executables are not dynamically
    Nick> linked, so it may be necessary to install the static
    Nick> versions of libraries you already have in dynamic form. I
    Nick> simply used trial and error to work out which libraries were
    Nick> needed: try a build, work out which header or library is
    Nick> missing, find out which RPM it comes from, install that and
    Nick> repeat. The exact combination will obviously depend on how a
    Nick> specific distribution divided things up into packages, and
    Nick> what you might already have installed.

This is indeed where things get messy. On 32-bit machines the
synthetic target currently needs static versions of libgcc.a,
libsupc++, and libgcc_eh.a. I suspect the same will be true when
building with a 64-bit gcc and -m32, but there is no easy way of
knowing what strange things the compiler folks may have done. It also
seems unlikely that the various distributions will be consistent about
any of this. Unfortunately all the machines I use regularly are
32-bit, not 64-bit, so I cannot do a lot of experimenting.

That still leaves the host-side, i.e. ecosynth, rawether, ... I
would not expect major 64-bit problems with any of those, and there
should be no sharing of pointers between the host and target sides.
However the current autoconf-based build mechanism for those only
supports 32-bit mode, and updating it for 64-bit builds has not been a
priority to date.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss