From: Enrico Weigelt <weigelt@metux.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] crosscompile problem
Date: Sat, 27 Aug 2005 08:20:52 +0200 [thread overview]
Message-ID: <20050827062052.GA5364@nibiru.local> (raw)
In-Reply-To: <1125096423.25384.46.camel@localhost.localdomain>
* skaller <skaller@users.sourceforge.net> wrote:
<snip>
> > Since almost all packages have to cope with this problem and
> > also widely used buildsystems like autoconf also have no clean
> > way of handling this, I suggest moving away this configuration
> > from individual packages to some central point - an global
> > config database.
>
> Acceptance would require standardisation of some kind.
Shouldn't be such a problem. We just have to found a separate
group (outside of the caml project), which thinks carefully and
makes some definitions ...
<snip>
> > This can be easily solved by a tiny shellscript and some carefully
> > maintained text database. (see attachement)
>
> Not so easy. Briefly, I am porting Felix to full cross-compilation
> support right now. This includes supporting Windows and OSX, as well
> as all Unix variants. I have to distinguish FOUR separate platforms:
>
> * build machine -- where package source is built
> * host machine -- where developers run Felix
> * target machine -- where the generated code is compiled
> * run machine -- where the compiled code is run
Well, just a job for namespaces ... (build.*, host.*, ...)
<snip>
> BTW: please do not use the archaic term 'Ansi C'. Responsibility
> for C was taken over by ISO decades ago. References to the
Okay, s/ansi/iso/g;
<snip>
> You need to recognize that the 'sizes' are dependent on many
> factors including the compiler and options. For example gcc
> can be coaxed into generating 32 bit code on a 64 bit platform
> by using -m32 option.
In this case you explicitly change the host platform, so it also
requires proper adaption of the config-db.
<snip>
> For Ocaml in general there will be 3 machines: build/host, target, and
> run platforms.
>
> Note that using bytecode compiler, you can cross-compile ..
BTW: is the output of the ocaml-compiler platform dependent ?
> It isn't clear that it is all that easy to 'cross-compile' native
> code, since it is not just a matter of emitting architecture
> dependent instructions -- it also depends on the availability
> of libraries, and assemblers and linkers with cross-compilation support,
> eg not everyone uses ELF object files.
Well, I'm crosscompiling quite evrything. It normally works.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
next prev parent reply other threads:[~2005-08-27 6:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-26 12:00 Enrico Weigelt
2005-08-26 12:18 ` [Caml-list] " David MENTRE
2005-08-26 12:33 ` Enrico Weigelt
2005-08-26 12:18 ` Sebastian Egner
2005-08-26 13:50 ` Enrico Weigelt
2005-08-26 13:42 ` Eric Cooper
2005-08-26 17:38 ` Enrico Weigelt
2005-08-26 20:11 ` Enrico Weigelt
2005-08-26 19:50 ` Enrico Weigelt
2005-08-26 22:47 ` skaller
2005-08-27 6:20 ` Enrico Weigelt [this message]
2005-08-28 17:39 ` Quôc Peyrot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050827062052.GA5364@nibiru.local \
--to=weigelt@metux.de \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox