Building a cross-compiling ocaml

Building a cross-compiling ocaml

[Matthew S. Harris]

I am trying to get ocaml to produce code that can be linked against
the libc of a different operating system (the University of Utah's
OSKit project, for those who may know it).  The key facts are:

  - The target architecture is the same, so all the normal build tools
    and commands work; I just need to add some compile-time and
    link-time options so gcc will use the proper header files and
    libraries.

  - I'm using a different libc than the native (Linux) one, so the
    ocamlrun produced in this manner cannot be run locally.  In other
    words, the normal build process gives me a broken ocamlc.

I am not very familiar with the OCaml architecture because I am only
trying to link with some functions written in OCaml.  I tried
following the directions given by Xavier a year ago
<http://pauillac.inria.fr/caml/caml-list/1160.html>, which involved
changing NATIVECCCOMPOPTS and NATIVECCLINKOPTS in config/Makefile, but
the make procedure for stdlib/ involves running ocamlrun, which was
linked with the byterun/* files produced with these options.

My understanding is that bytecode files are entirely
system-independent, so I should just need to get the byterun/* files
built with the alternate library.  But since ocamlrun, which is used
by ocamlc, is built from these files, I have a circular dependency: I
need to run an ocamlc under Linux to produce the files that I will
link with the alternate libc.  What is the best way to resolve this?


Matthew

Re: Building a cross-compiling ocaml

[Sven LUTHER]

On Mon, Mar 06, 2000 at 04:30:35PM -0500, Matthew S. Harris wrote:
> I am trying to get ocaml to produce code that can be linked against
> the libc of a different operating system (the University of Utah's
> OSKit project, for those who may know it).  The key facts are:

HAs anyone been so crazy as to try to build a palm pilot version of ocaml ? or
even a TI 89/92 version ? todays palm come with 8MB of memory, this is
plentifull for an caml toplevel. the TI version could cause more problems
(having only ~500kb memory i think).

both of these computer use a 68000, or some modified version thereof, so it
should be possible to reuse the m68k code that is already in ocaml.

Friendly,

Sven LUTHER

Re: Building a cross-compiling ocaml

[Benjamin C. Pierce]

> HAs anyone been so crazy as to try to build a palm pilot version of ocaml ? or
> even a TI 89/92 version ? todays palm come with 8MB of memory, this is
> plentifull for an caml toplevel. the TI version could cause more problems
> (having only ~500kb memory i think).
> 
> both of these computer use a 68000, or some modified version thereof, so it
> should be possible to reuse the m68k code that is already in ocaml.

Alternatively: has anybody tried an EPOC port?  I just saw mark Jones'
HUGS interpreter running on a Psion Revo, and the author of the port
claimed it was quite easy...

        B

 

Re: Building a cross-compiling ocaml

[Olivier Bouyssou]

Sven LUTHER wrote:
> 
> On Mon, Mar 06, 2000 at 04:30:35PM -0500, Matthew S. Harris wrote:
> > I am trying to get ocaml to produce code that can be linked against
> > the libc of a different operating system (the University of Utah's
> > OSKit project, for those who may know it).  The key facts are:
> 
> HAs anyone been so crazy as to try to build a palm pilot version of ocaml ? or
> even a TI 89/92 version ? todays palm come with 8MB of memory, this is
> plentifull for an caml toplevel. the TI version could cause more problems
> (having only ~500kb memory i think).
> 
> both of these computer use a 68000, or some modified version thereof, so it
> should be possible to reuse the m68k code that is already in ocaml.
> 
> Friendly,
> 
> Sven LUTHER

Yes... for me ocamlrun work well on uClinux for ColdFire with 16Mo of ram.

Screenshots :

Hard Reset
DRAM Size: 16M

Copyright 1997-1998 Motorola, Inc.  All Rights Reserved.
ColdFire MCF5206e EVS Debugger v1.4.1 (Jul 13 1998 12:12:00)
Enter 'help' for help.

dBUG> dn -i image.bin
Address:  0x00020000
Ethernet Address: 00:00:00:00:00:00
Downloading Image 'image.bin' from 192.0.5.100
M
1380504 bytes read via TFTP
dBUG> go 20000


uClinux/COLDFIRE(m5206e)
COLDFIRE port done by Greg Ungerer, gerg@moreton.com.au
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
KERNEL -> TEXT=0x020000-0x07e1dc DATA=0x07e1dc-0x090094
BSS=0x090094-0x0ae9d8
KERNEL -> ROMFS=0x0ae9d8-0x18f7f0 MEM=0x18f7f0-0xfff000
STACK=0xfff000-0x1000000
Calibrating delay loop.. ok - 35.73 BogoMIPS
Memory available: 14560k/15875k RAM, 0k/0k ROM (1820k kernel data, 376k
code)
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
uClinux version 2.0.38.0 (root@yeti.sobel) (gcc version egcs-2.91.66
19990314 (egcs-1.1.2 release)) #30 mer déc 29
 18:40:57 CET 1999
ColdFire internal UART serial driver version 1.00
ttyS0 at 0x10000140 (irq = 224) is a builtin ColdFire UART
ttyS1 at 0x10000180 (irq = 225) is a builtin ColdFire UART
Ramdisk driver initialized : 16 ramdisks of 4096K size
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: AE9D8-18F9D7 (RO)
PPP: version 2.2.0 (dynamic channel allocation)
TCP compression code copyright 1989 Regents of the University of
California
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256) (6 bit
encapsulation enabled).
CSLIP: code copyright 1989 Regents of the University of California.
SLIP linefill/keepalive option.
ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
NE*000 ethercard probe at 0x300: 00 00 00 00 00 00
eth0: NE2000 found at 0x300, using IRQ 4.
VFS: Mounted root (romfs filesystem) readonly.
Shell invoked to run file: /etc/rc
Command: hostname uClinux-coldfire
Command: /bin/expand /etc/ramfs.img /dev/ram0
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram0 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: ifconfig lo 127.0.0.1
Command: route add -net 127.0.0.0 lo
Command: ifconfig eth0 192.0.5.101
Command: route add -net 192.0.5.0 netmask 255.255.255.0
Command: route add default gw 192.0.5.1
Command: /bin/mount -n -t nfs
192.0.5.100:/home/bouyssou/uClinux-coldfire/user /mnt
Execution Finished, Exitingÿ
Sash command shell (version 1.1.1)
/> cd /mnt/byterun
/mnt/byterun> ./ocamlrun ./ocaml
        Objective Caml version 2.02

# let f = function _ -> "Hello World" ;;
val f : 'a -> string = <fun>
# f () ;;
- : string = "Hello World"
#



-- 
Olivier Bouyssou (F1NXH), Sobel  		olivier.bouyssou@wanadoo.fr
22 rue paul verlaine				31570 st Foy d'Aigrefeuille
Tel : +33.5.62.18.81.82				Fax : +33.4.68.94.54.16

Re: Building a cross-compiling ocaml

[Francois Rouaix]

> HAs anyone been so crazy as to try to build a palm pilot version of
> ocaml ?

Of course not. However, I've worked on a port of Caml Light a long time ago
(you'll find that from my INRIA Web page). The fact that the device comes
with 8MB is misleading. This is not really memory you can allocate into (in
order to protect data from bogus programs, the Palm has memory protection on
most of its address space). Back in the time of the Pilot 5000, the actual
available memory was something like 64k. I had a small lambda-calculus 
evaluator
running on my Pilot 5000 (isn't that useful ?).
Hopefully these days with 8MB devices, we should get more heap (128k?).

Porting Caml Light is easier than OCaml because the runtime used to work for
platforms where ints are 16bits, which is the case in the Palm development
environment.

--f

Re: Building a cross-compiling ocaml

[Sven LUTHER]

On Wed, Mar 08, 2000 at 10:20:48AM -0800, Francois Rouaix wrote:
> > HAs anyone been so crazy as to try to build a palm pilot version of
> > ocaml ?
> 
> Of course not. However, I've worked on a port of Caml Light a long time ago
> (you'll find that from my INRIA Web page). The fact that the device comes
> with 8MB is misleading. This is not really memory you can allocate into (in
> order to protect data from bogus programs, the Palm has memory protection on
> most of its address space). Back in the time of the Pilot 5000, the actual
> available memory was something like 64k. I had a small lambda-calculus 
> evaluator
> running on my Pilot 5000 (isn't that useful ?).
> Hopefully these days with 8MB devices, we should get more heap (128k?).
> 
> Porting Caml Light is easier than OCaml because the runtime used to work for
> platforms where ints are 16bits, which is the case in the Palm development
> environment.

ints are 16bits, ...

i thought the 68000's where true 32 bit processors from the programming side.
is it the same for ulinux ?

Friendly,

Sven LUTHER

Re: Building a cross-compiling ocaml

[Xavier Leroy]

> I am trying to get ocaml to produce code that can be linked against
> the libc of a different operating system (the University of Utah's
> OSKit project, for those who may know it).  The key facts are:
> 
>   - The target architecture is the same, so all the normal build tools
>     and commands work; I just need to add some compile-time and
>     link-time options so gcc will use the proper header files and
>     libraries.
> 
>   - I'm using a different libc than the native (Linux) one, so the
>     ocamlrun produced in this manner cannot be run locally.  In other
>     words, the normal build process gives me a broken ocamlc.

Right.  You need a native ocamlrun to run ocamlc, not the
cross-compiled ocamlrun.

The easiest solution is as follows:
- leave the sources in byterun/ unchanged, so that the normal build
  procedure of ocaml will work;
- make a copy of byterun/ in, say, byterun.cross;
- modify the sources and Makefile in byterun.cross so that they can be
  cross-compiled and produce an ocamlrun for your target OS;
- use byterun.cross/ocamlrun to run OCaml bytecode executables
  on the target OS.

> My understanding is that bytecode files are entirely
> system-independent

They are almost entirely system-independent.  For instance, if the
target system has different ASCII codes for '\n' and '\r' than the
native system, text I/O will look funny.  (This is the case if you
cross-compile between MacOS on the one side, and Unix or Windows on
the other side.)  This is the only system dependence that I can
remember right now.

- Xavier Leroy