adapt build system for cross-compilation

[vicuna]

Original bug ID: 5737
Reporter: william
Status: assigned (set by meyer on 2012-12-30T03:13:09Z)
Resolution: open
Priority: normal
Severity: feature
Platform: mxe
OS: linux
Version: 3.12.1
Category: configure and build/install
Tags: patch
Related to: #6613
Monitored by: J5lx william @glondu @xclerc Camarade_Tux kerneis jm @hcarty

Bug description

Hello,
I am using mxe on linux to cross-compile my application for windows. It uses camlimages, lablgtk2, lablgl, cairo, xml-light (and ocamlbuild+findlib)
Mxe is a platform for cross-compilation, it includes patches and make commands for hundreds of packages.
http://mxe.cc/ (main site)
https://github.com/mxe/mxe (sources)
https://github.com/william3/mxe (fork being integrated)

To build ocaml I adapted debian patches maintained by Romain Beauxis, to make it usable with many different targets (i686-pc-mingw32, i686-w64-mingw32, x86_64-w64-mingw32 for 32/64bits targets).

Though it works fine with ocaml 3.12.1, I would like :

• to get your feed back if possible, to know if the process could be simplified (I do not really understand the patch)
• to know if you could integrate part of the code for next versions

Best regards,
William

File attachments

• 0001-Do-not-run-tests-when-cross-compiling.patch
• 0001-build-always-build-lex-tools-and-ocamlc-with-the-com-fixed.patch
• 0001-build-avoid-an-unneeded-gnu-style-conditional-in-Mak.patch
• 0001-build-fix-build-on-Windows.patch
• 0001-build-fix-make-clean-failure-when-.-configure-hasn-t.patch
• 0001-build-ocamlmklib-on-Windows-expect-a-Windows-style-p.patch
• 0001-build-pass-f-Makefile.nt-to-sub-make-processes-of-Ma.patch
• 0001-build-replace-build-mk-config-myocamlbuild_config-.s-2.patch
• 0001-build-replace-build-mk-config-myocamlbuild_config-.s.modified.patch
• 0001-build-replace-build-mk-config-myocamlbuild_config-.s.patch
• 0001-build-skip-IFLEXDIR-in-mk_shell_and_ocamlbuild_confi.patch
• 0001-build-typo-that-recursively-called-the-wrong-make-ru.patch
• 0001-config-Makefile.mingw64-remove-redundant-mms-bitfiel.patch
• 0001-myocamlbuild.ml-only-build-with-.opt-compilers-if-th.patch
• 0001-various-patches-to-build-an-ocaml-cross-compiler.patch
• 0002-.gitignore-ignore-vim-temp-files-and-.cm-stuff.patch
• 0002-build-always-build-lex-and-tools-with-the-compiler-f.patch
• 0002-build-don-t-use-make-s-C-it-s-not-available-everywhe.patch
• 0002-build-typo-on-config-Makefile.mingw64-msvc-and-msvc6.patch
• 0003-configure-use-stderr-for-all-messages-targetted-at-t.patch
• 0004-build-fix-filename-case.patch
• 0005-build-prefer-forward-slashes-to-backward-slashes.patch
• 0006-configure-fix-detection-of-non-working-C-compiler.patch
• 0007-configure-remove-unused-variable-from-case.in-test.patch
• 0008-configure-remove-unused-variable-from-case.in-test.patch
• 0009-configure-add-target-and-use-target-instead-of-host-.patch
• 0010-configure-when-cross-compiling-set-TOOLPREF-and-use-.patch
• 0011-configure-support-cross-compilation-with-mingw.patch
• 0012-windows-makefiles-remove-unused-DO-variable.patch
• 0013-windows-makefiles-use-dll-for-the-SO-extension.patch
• cross-build_20130829.tar.gz
• cross-patches-2013-07-27-configure-to-disable-ocamldebug-ocamlbuild-ocamldoc.tar.gz
• cross-patches-2013-09-07-fixed.tar.gz
• cross-patches-2013-09-07.tar.gz
• cross-patches-rev2-2012-12-29.tar.gz
• cross-patches-rev2-2013-02-17.tar.gz
• cross-patches-rev4-2013-02-24.tar.gz
• cross-patches-rev4-2013-06-27-non-specific.tar.gz
• cross-patches-rev4-2013-06-28-safe2.tar.gz
• cross-patches-rev4-2013-07-01-safe3.tar.gz
• fix-build-failures-2013-07-01.tar.gz
• patches_dump.tar.gz

[vicuna]

Comment author: @gasche

I have no authority on the question of whether such patches could be accepted in a future state. I just had a look at the patches related to the OCaml compiler proper (very quick, so feel free to correct misunderstandings): I must they they're not really that convincing.

• some part of them amount to hardcode that the target is windows (see for example https://github.com/william3/mxe/blob/master/src/ocaml-core-1-fixes.patch#L589 and below)

• some part of them are terribly hackish ("Give up and just define _finddata_t explicitly here")

• some part of them seems to be bugfixes or code changes that are independent of the cross-compilation question (I suppose you integrated all debian patches, not only those that straighten the build system). That seems to be the case of the ocamlbuild changes for example https://github.com/william3/mxe/blob/master/src/ocaml-ocamlbuild-1-fixes.patch

I would understand their integration in a source tree designed solely for unix-to-windows compilation, with the understanding that they will remain as a fork forever. Even then, I would be a bit wary of this integration of all those independent changes in a single patch, making potential errors/divergences more difficult to track (that seems unrelated to your work and inevitable under the current project organization, though; they should consider moving to a structure with multiple patches per project).
But integrating them upstream is clearly impossible in their current state.

If I were a maintainer I wouldn't touch this until the changes are sorted out and given more structure and justification.

I also noticed that a lot of the "ocaml"-related patches do not concern the ocaml compiler proper: cairo, findlib, camlimages, xml-light, etc. are third-party libraries. If you have not yet contacted the upstream of those projects, you should consider doing so. A post on the caml-list may also interest people that would learn about how to make their programs portable with respect to this specific situation and, one can always hope, motivate a few charitable souls to help you getting the patches in better shape?

[vicuna]

Comment author: william

Hello,
Thanks for this analysis. My questions were only targeting this:
https://github.com/william3/mxe/blob/master/src/ocaml-core-1-fixes.patch

Indeed, I tried to submit other patches to related people, but did not get many answers...

I would appreciate any hint that would improve the ocaml related patch :
https://github.com/william3/mxe/blob/master/src/ocaml-core-1-fixes.patch
which is the patch given above :
http://caml.inria.fr/mantis/file_download.php?file_id=731&type=bug

Changes to ocamlbuild were made mainly in order to make ocamlbuild usable for cross targets with ocamlfind integration.

Regards,
William

[vicuna]

Comment author: Camarade_Tux

Hi,

Based on William's patch, I made a series of smaller patches.

First one is: 0001-config-Makefile.mingw64-remove-redundant-mms-bitfiel.patch (and last one is 13th). The patch 0002 is something I forgot (I should have moved it out and not submit it). The patchs have some details if you select "show content" so I won't repeat it here. Some patches are trivial but for others, I have some questions on the approach.

• 0003-configure-use-stderr-for-all-messages-targetted-at-t.patch
  Some things were printed to stdout and some others to stderr; I now send everything to stderr.

• 0010, 0011, 0013:
  Are they a "right" approach? These changes need some polishing but is it ok to add special cases for cross-compilation with hardcoded settings?

Thanks,
Adrien Nader

[vicuna]

Comment author: meyer

Hi,

Thanks for the patches. It looks like it's only a build system.

I reviewed them all, my comments below, however haven't attempted to cross compile OCaml yet. I might try it for ARM this weekend.
I think we need at least a second pair of eyes to look at the patches because they look really promising!

Comments

• patch 1

looks good apart from the part it would be good to:

• document why we are disabling the -mms-bitfields and what kind of
  implications it has

• maybe making it configurable, like a variable for cross compilation
  that is empty

• patch 2; ignored, spurious .gitignore/vim stuff

• patch 3

I admire simplicity and portability here, but we should use automatic redirection or custom command. Then if somebody adds another echo, she would be forced to use 'msg' command instead of echo and redirection I can see however that we use it in all the places, so looks Ok.

• patch 4
  Looks OK.

• patch 5
  Why do we need to touch Makefile.nt?

but looks OK. With a reservation it will be tested on Windows.

• patch 6
  Looks OK.

• patch 7

I trust this cases remained the same, so looks ok.

• patch 8

Same as above.

• patch 9
  Looks a bit hairy.
  First of all why just not substitute host for target before it's been used?

It's certainly improvement to use it but increases a risk, of breaking some exotic builds.

• patch 10
  We should initialise TOOLPREF in the begining if we plan to use it.

We should be able to replace these patterns:
-gcc
with something like:
gcc
thus avoiding a lot of redundant pattern matches

it might cause troubles only when something like 'mygcc' was used which is fairly unrelastic.

I think better way of using TOOLPREF would be to, once it's defined, redefine the interesting tools (as & gcc) to ${AS} & ${GCC} with TOOLPREF prefix and then use these variables.

• patch 11

This:

• x86_64--mingw) echo "Wow! A 64 bit architecture!" 1>&2

•                 echo "#undef ARCH_SIXTYFOUR" >> m.h
  

doesn't sound like a win situation.

It will be more consistent to use variables like ${TOOLCHAIN}. Instead of ${toolchain} but that's just cosmetic.

I've gone through all the mingw cases, but can't guarantee they are correct until I would see myself ocaml crosscompiling.

• Patches 12,13
  Looks OK.

[vicuna]

Comment author: Camarade_Tux

Thanks for the review.

So far I'm not cross-compiling OCaml successfully. By posting them here I'm trying to get the overall approach validated. There are also some changes that can be merged independently of the others and doing so will reduce the size of subsequent patches (including out-of-tree ones in the case cross-compilation support cannot be included easily).

I've updated the set of patches and I'm going to post them inside a tarball now or this page will soon be unreadable. I've reorganized the patches to move the least intrusive and least dangerous ones first so the patch numbers have changed but in this comment I'll use the same numbers as you did.

The file is named "cross-patches-rev2-2012-12-29.tar.gz".

I've dropped the patch about -mms-bitfields. This switch is now enabled by default for -w64-mingw. However this changed only happened in gcc 4.7.

I've introduced inf()/wrn()/err() functions. inf() writes its arguments to stderr; wrn() also writes "WARNING:\n" before; err() also "exit 2".

Forward slashes work just as well on windows. I've changed Makefile.nt to use forward slashes in advance. I'm not sure yet whether I'll be able to use the regular Makefiles or if I'll have to rely on Makefile.nt ones. I've moved the patch down in the list; we'll see a bit later.

Regarding "host" vs. "target" in the configure file, I simply started and went over all the cases using "$host". It turned out that all of them actually want the "target". However it's quite likely "host" will also be needed (probably for ocamlobjinfo for instance: it runs on $host and needs to link to a C library).

I think better way of using TOOLPREF would be to, once it's defined, redefine the interesting tools (as & gcc) to ${AS} & ${GCC} with TOOLPREF prefix and then use these variables.

I've tried to do that but it touches areas for which I'm not sure I understand the intent. The biggest use of ${TOOLPREF}gcc is around line 830 and starts with:
case "$arch,$system" in
amd64,macosx) as="${TOOLPREF}as -arch x86_64"
aspp="${TOOLPREF}gcc -arch x86_64 -c";;
As far as I understand, ocaml requires aspp to come from gcc in this setup. Was that the intent or is it because the only compiler available was gcc? And what about clang/llvm?

I need some more input on that.

I've fixed the "#undef ARCH_SIXTYFOUR" issue and I've replaced "toolchain" with "TOOLCHAIN".

edit: I've fixed two issues but I'm not uploading another archive right now:
first,

if target_type is "unknown", the script will try to cross-compile for the "unknown" architecture

-target_type=unknown
+target_type=""

second,
inf/wrn/err functions need to invoke echo with "-e" and need to quote the arguments

[vicuna]

Comment author: meyer

Thanks for the patches, here are my further comments:

• patch 1

I like the cleanup you have made for DBM. I've applied this patch.

• patch 2

Looks good. Applied, thanks.

• patch 3

Not applied.

What kind of problems compatibilty.h gives?

If there are problems we should fix it in the header.

• patch 4

I like the attempt you've made to improve the ./configure script.

I'm also quite reserved about redirecting everything to stderr. Your
patch probably just changes how the user will interact with the script
as instead the user will filter the messages by string which might be
better or not.

By any means, I am tempted to apply these changes, once I know if there
are mandatory, thanks.

• Patch 5

I am resistant to warn the user, would be better to support both
notations? If you decide to do this, please do it for all the flags.

• patch 6

Is incorrect.

cd config/auto-aux/

cc=gcc sh ./runtest sizes.c

4 4 4 2

This will print to stdout the sizes of the primitive types.

Quotation will make them spliced into set builtin shell command, thus
setting the arguments to each of the sizes.

However you have issued:

ret=$?

set $ret

which just sets the first argument to the return code of the command.

• Patch 7

I'm resistant, looking closely I think it would be a premature
optimisation.

It's a small improvement that buys nothing, and might be reverted in a
future. Is there any particular reason for this cleanup?

• Patch 8

target_type is initially set to "unknown" therefore we shouldn't check
it with test -n. Also, we should print un-coditionaly information about
target, consistency here is more important. I also think we shouldn't
check-in mechanical renaming changes from $target to $host before we
have working cross-compilation so I'd refrain from checking-in the patch
now

• patch 9

Follow up of 4, so skipped for time being.

• patch 10

I wouldn't drop "support" for old buggy gcc versions, however in general
I am in favour of some cleanups.

Follow up of 4 so not applied yet.

• patch 11

Looks all right, applied.

• patches 12, 13

Don't have mingw system to test it, so I would rather not apply it
before I know it's important to change.

Overall, thank you for your efforts,

Wojciech

[vicuna]

Comment author: Camarade_Tux

• patch 3

The renaming from stat_alloc() to caml_stat_alloc() comes from William's patch. I haven't had an issue myself and thinking more about it, I'm not sure what would have caused an issue for William. I saw it as an opportunity for a slight update. I'm going to remove it for now; if "namespaced" function names are preferred, it will probably be better to change all of them and not only stat_alloc(), and do it at once. But for now, removed.

• patch 4

I started redirecting messages to stderr because there were some blocks of code that I wanted to use as functions (and therefore have them write to stdout (or stderr or anything)) but which were already writing to stdout. Usage between stderr and stdout was inconsistant but stderr seemed to prevail so I settled for that.

I think that I don't have the original issue anymore and I don't mind where the messages are sent as long as it's consistent. Progress messages are probably better on stdout but if warnings and errors go to stderr, they will probably in the wrong place or out of context. So, everything to stdout?

I think I'll try to redirect inf/wrn/err to "3" or something like that and use the "exec" command to redirect 3 to stdout. That should free stdout and stderr for use in other places and display properly in the terminal. (I'll see how it goes)

It could be good to use colour too for wrn and err but doing it in a portable fashion might be difficult. For later.

• patch 5

I added the check for "-option=val" vs. "-option val" because I made the mistake myself. The check is easy to implement but I'm not sure the support for "=" is. I'll see if '=' can be added to $IFS. However, it seems standard not to use '=' for ocaml

• patch 6

Very good catch. I'm wondering if the issue can be solved with "set". If not, I'll probably introduce size_short/size_long/size_... variables.

• patch 7

The unused variable in the case/in/esac constructs did not cause me any issue so far. I'll drop it.

• patch 8

I caught the issue with target initially being "unknown" but only after making the archive. I've fixed it by making the default "" instead of "unknown".

I'll make it always print the target.

• patch 10

I haven't dropped support for gcc 2.96/2.95. I've simply not touched them. This means the warnings won't appear if you cross-compile with gcc 2.96/29.5, which I consider an unlikely scenario.

Thanks a lot.

[vicuna]

Comment author: Camarade_Tux

Hi,

I've attached a new file. This is close to a code dump but I that way I'm somehow creating a backup for the patches. It's not really worth looking at them right now since they need cleaning.

[vicuna]

Comment author: meyer

Dear Adrien,

Sorry to keep you waiting, I'm going to look at your cross-compilation patches this week.

[vicuna]

Comment author: Camarade_Tux

I've add "cross-patches-rev2-2013-02-17.tar.gz" (still "rev2" by mistake). I still need to clean things a bit but...

ocamlopt.opt works!

There's one thing I'm not verry happy with: I had to do changes asmcomp/ because it uses nativeints for many integers and I build on a 64bit system for a 32bit one; I ended up with several bad integer litterals in the generated assembly. This will definitely need proofreading.

Also, at first I had tried to cross-compile things like ocamldoc while building the cross-compiler. That didn't make much sense (that would only make sense if I were cross-compiling the compiler). In the end I added the ability to disable building ocamldoc and a few others like it is doable for camlp4.
So I did something that will improve cross-compiling the compiler but that is not needed for this bug report. What should I do about these patches?

Try to have them in? Try to have them but after the other ones? Forget about them (for now)?
Depending on the answer I'll reorganize the order of my patches to match so wait for rev4 before reading these patches.

Thanks. :-)

[vicuna]

Comment author: meyer

Thanks for all the patches. My initial comments below, I said I applied

• but just realised after reviewing 31 small patches that there are 40 of
  them, so I'll postpone it for tomorrow. The general comment is that it's
  getting into the right track. Some of the patches needs a really
  thorough reviewing before we commit them. The ones I marked with a
  star are the ones that I think needs some improvements. I'm updating
  this in-place as it goes along with applying and testing them. Short
  note: did you try your cross-compile patches on a different
  architecture, i.e ARM? Also we might try porting them to OPAM.
  The reason why I ask is that I do have an ARM device, and would like to
  build packages for it, and probably many other people would like.

Patch 1/
I don't think we should keep flexdll.h it in the triangle quotes - it's
not a system header.
However I think it's a part of OCaml installation so we should apply this patch.

Patch 2/
I trust it works, however I am not able to test it.

Patch 3/
Looks fine, thanks. I am not sure if we should prefix it with
underscore, my initial thought was that we shouldn't, but it's a header
not used anywhere else so maybe not worth to change.

Patch 4/
Looks OK to me, applied.

Patch 5/*
The echo -e command prints on my machine also leading -e.

$ ./configure --prefix $PWD
-e Configuring for host i686-pc-linux-gnu ...
-e Configuring for target i686-pc-linux-gnu ...
-e Using compiler gcc.

also the message prefix breaks the line:

./configure -help
ERROR:
-e Unknown option "-help".

The script continues to run even with error:

-e Using compiler arm-linux-gnueabi-gcc.
./tst: 1: Syntax error: word unexpected (expecting ")")
WARNING:
-e Unable to compile the test program.
-e This failure is expected for cross-compilation: we will assume the C compiler is ANSI-compliant.
-e Checking the sizes of integers and pointers...

Patch 6/
It's always best to inform the user about his failure. Applied.

Patch 7/
Applied. Thanks.

Patch 8/
I don't think we need $model anymore, so thanks for cleaning this up. I've applied this patch too.

Patch 9/
This needs to be documented. Probably additional entries to the manual
needs to be done. Especially that we are able to cross compile now at all.

Patch 10/
We should use conventional lowercase variable names in the Caml build
system. TOOLPREF and TOOLCHAIN all are not obeying the convention.

I suspect TOOLPREF/TOOLCHAIN are a mingw specific variable, but can't
find it anywhere. If we decide to expose it, then it needs to be
documented - I propose in the configure script itself as a commentary. But I'd leave it as it is.

My worry here is that we are hardcoding the sizes, instead of detecting
them.

I'll apply this patch however, because can't think about anything better
at the moment.

Patch 11/
I like this patch, applied. Did you try to test it on a different shell than bash?

Patch 12/*
I don't like this: '# XXX' prefix for the comment.

I'd prefer nicer prefix, like TODO or FIXME. However it's not a show
stopper, patch looks complicated so need to make a sweep over this
again.

Patch 13/
I don't have mingw system to test it, and there is 32 how about 64? If
there is another flavour of the library we need to cover that. I
tentatively applied.

Patch 14/
Looks OK.

Patch 15/*
ocaml -version can print other characters than specified in the sed command.

It would be much safer if the you matched for example like this:
sed 's/.version (.)/\1/g'

Also:
if test x"$target" != x"$host"; then
we should be using ==.

Patch 16/
Makes sense, applied.
It looks like a continuation of the previous patch, it would be easier to collate them.

Patch 17/
Looks OK, applied.

Patch 18/
Looks good to me, applied.

Patch 19/
Looks OK, applied.

Patch 20/
Fine. Applied.

Patch 21/
Apart from visible whitespaces it, looks OK.

EDIT: Sorry, I notice that the file have a lot leading whitespaces, I'll
clean them up as they polluting (not necessarily) the file.

Patch 22/
Thank you, applied.

Patch 23/
Don't put comma after `if' condition. Otherwise applied.

Patch 24/*
To be reviewed.

Patch 25/*
Yet to be reviewed again.

Patch 26/
Looks good to me. Thanks.

Patch 27/*
Needs to be reviewed.

Patch 28/*
I like it, but needs more looking.

Patch 29-40
Needs to be reviewed.

[vicuna]

Comment author: meyer

Try to have them in? Try to have them but after the other ones? Forget about them (for now)?
Depending on the answer I'll reorganize the order of my patches to match so wait for rev4 before reading these patches.

We could consider them as an extra set of patches, if you separate them nicely, it would be a nice addition, but be careful to not over complicate what is now.

[vicuna]

Comment author: Camarade_Tux

Thanks for the comments.

I'll reorganize the commits so that the patches that could benefit cross-compilation of the compiler appear last.
I'll need a few more days to do that. Probably this week-end.

Btw, for TOOLPREF, it's not specific to anything. It's either arbitrary or already somewhere in the ocaml sources.

[vicuna]

Comment author: meyer

Absolutely no rush, I'm going to look at it again in few days time - I have a fully booked week too.

[vicuna]

Comment author: william

about Camarade_Tux comment from 2013-02-17 22:57, regarding ocamldoc and camlp4 :

There are two categories of executables :

the ones that need to be cross compiled :
ocamlc ocamlrun ocamlcp ocamldep ocamlmklib ocamlmktop ocamlopt ocamlprof

the ones that do not need to be cross compiled :
camlp4prof camlp4boot camlp4 camlp4oof camlp4of camlp4o camlp4rf camlp4r camlp4orf ocamldoc ocamllex ocamlyacc

For all of them, it is important to be able to have them "prefixed", like
i686-w64-mingw32-ocamlc, even if this is for a program such as ocamldoc that is not really cross compiled. Because when building other libraries and programs, it is easier to use prefixed tools no matter if it is ocamldoc or ocamlc.

So would it be possible to have a build system that preserves building of those tools ?