New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adapt build system for cross-compilation #5737
Comments
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.
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). 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? |
Comment author: william Hello, 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 : Changes to ocamlbuild were made mainly in order to make ocamlbuild usable for cross targets with ocamlfind integration. Regards, |
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.
Thanks, |
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. Comments
looks good apart from the part it would be good to:
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.
but looks OK. With a reservation it will be tested on Windows.
I trust this cases remained the same, so looks ok.
Same as above.
It's certainly improvement to use it but increases a risk, of breaking some exotic builds.
We should be able to replace these patterns: 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.
This:
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.
|
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'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: 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: if target_type is "unknown", the script will try to cross-compile for the "unknown" architecture-target_type=unknown second, |
Comment author: meyer Thanks for the patches, here are my further comments:
I like the cleanup you have made for DBM. I've applied this patch.
Looks good. Applied, thanks.
Not applied. What kind of problems compatibilty.h gives? If there are problems we should fix it in the header.
I like the attempt you've made to improve the ./configure script. I'm also quite reserved about redirecting everything to stderr. Your By any means, I am tempted to apply these changes, once I know if there
I am resistant to warn the user, would be better to support both
Is incorrect. cd config/auto-aux/cc=gcc sh ./runtest sizes.c4 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 However you have issued: ret=$?set $retwhich just sets the first argument to the return code of the command.
I'm resistant, looking closely I think it would be a premature It's a small improvement that buys nothing, and might be reverted in a
target_type is initially set to "unknown" therefore we shouldn't check
Follow up of 4, so skipped for time being.
I wouldn't drop "support" for old buggy gcc versions, however in general Follow up of 4 so not applied yet.
Looks all right, applied.
Don't have mingw system to test it, so I would rather not apply it Overall, thank you for your efforts, Wojciech |
Comment author: Camarade_Tux
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.
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.
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
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.
The unused variable in the case/in/esac constructs did not cause me any issue so far. I'll drop it.
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.
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. |
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. |
Comment author: meyer Dear Adrien, Sorry to keep you waiting, I'm going to look at your cross-compilation patches this week. |
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. Try to have them in? Try to have them but after the other ones? Forget about them (for now)? Thanks. :-) |
Comment author: meyer Thanks for all the patches. My initial comments below, I said I applied
Patch 1/ Patch 2/ Patch 3/ Patch 4/ Patch 5/* $ ./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/ Patch 7/ Patch 8/ Patch 9/ Patch 10/ I suspect TOOLPREF/TOOLCHAIN are a mingw specific variable, but can't My worry here is that we are hardcoding the sizes, instead of detecting I'll apply this patch however, because can't think about anything better Patch 11/ Patch 12/* I'd prefer nicer prefix, like TODO or FIXME. However it's not a show Patch 13/ Patch 14/ Patch 15/* It would be much safer if the you matched for example like this: Also: Patch 16/ Patch 17/ Patch 18/ Patch 19/ Patch 20/ Patch 21/ EDIT: Sorry, I notice that the file have a lot leading whitespaces, I'll Patch 22/ Patch 23/ Patch 24/* Patch 25/* Patch 26/ Patch 27/* Patch 28/* Patch 29-40 |
Comment author: meyer
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. |
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. Btw, for TOOLPREF, it's not specific to anything. It's either arbitrary or already somewhere in the ocaml sources. |
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. |
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 : the ones that do not need to be cross compiled : For all of them, it is important to be able to have them "prefixed", like So would it be possible to have a build system that preserves building of those tools ? |
Comment author: Camarade_Tux Well, it's difficult to have them build during the same build. I believe it should be a requirement that if you want to build a cross ocaml X.Y.Z, you need to have a native ocaml X.Y.Z on your system. That means that in order to build the cross-compiler, you will have to have a matching native toolchain. In that case you will be able to reuse most of it to get the right tools. If you need to have specific names for these tools too, simply 'cp' or 'ln -s' them. They will exist for sure during build: they're really needed. It might be doable to have them built as native tools during the build of the cross-compiler but it's really much more work. That will basically require that it is possible to cross-compile a native compiler. For now, 'cp' or 'ln -s' are very good ways to do it and actually the configure of the cross-compiler will fail if the version of the native compiler and the version of the cross-compiler you're building don't match. |
Comment author: meyer Dear William and Adrien, Maybe a small chime in: building a cross-compiler does not preclude requirement of not having the compiler on the path. It does however simplify a lot the build process. In general the problem could be solved by a separate recursive step for Makefile, so in normal world OCaml is built like this:
in the cross-compilation world additional recursive invokation of Makefile would happen with all the variables set up to met the requirement building the cross-compiler. In practice, it's not that simple however and I don't think it's needed at a cost of making it more complex. So I'd assume we already have the native toolchain already in place. |
Comment author: Camarade_Tux I forgot to mention that both gfortran and gnat have the same requirement for cross-compilers and that's why I stopped trying to not require a native toolchain. |
Comment author: william Indeed you are right. |
Comment author: meyer I tried your patches with arm toolchain on x86: $ ./configure --target arm-linux-gnueabi -e Configuring for host i686-pc-linux-gnu ... -e Configuring for target arm-linux-gnueabi ... -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... ./tst: 1: Syntax error: word unexpected (expecting ")") ERROR: -e Unable to compile the test program. Make sure the C compiler 'arm-linux-gnueabi-gcc -O ' is properly installed. 2 things:
Also I would suggest testing on both on mingw and any other popular architecture (ARM for instance). |
Comment author: william could you please explain how to patch sources with cross-patches-rev2-2013-02-17.tar.gz ? |
Comment author: meyer William, git am *.patch if not than: for f in *.patch; do patch -p1 < $f; done (not that < {} will not work as it will splice two halves to redirection) |
Comment author: william based on the git directory : and get : same problem with git version of 17/02/2013 |
Comment author: Camarade_Tux Here's a new version of the patches. It's against HEAD~ (damn people commiting on sundays!) but with the patch in #5887. The file is "cross-patches-rev4-2013-02-24.tar.gz". I've moved commits around and I've squashed some of them together and got 31 commits (down from 40 or so). There are three directories inside the archive:
Their names should be fairly explicit. The 03-wip directory is included for completeness but is not mergeable. If moved the error messages from "echo -e" to "printf '%b\n'" since echo isn't portable: The fact that there is a newline after "WARNING:" and "ERROR!" is on purpose: I've found it to look nicer and be easier to stop. Actually, I've added a new line before the tag and another one after the error message. I've improved some messages. In particular, the error you had with the arm toolchain is because the patches have a hardcoded list of integers/pointers/shorts/longs sizes when cross-compiling since they cannot be guessed. Currently, only windows 32bit and 64bit are there. I prefer to leave someone else add the entries for other toolchains. I've documented -target in the INSTALL file. The TOOLPREF/TOOLCHAIN variables are mostly arbitrary: they appear like that in some other projects but there is absolutely no rule about them. I haven't changed their name in these patches but there is no reason to not do it if it is wished. I've tried the configure script with ash too (instead of bash invoked as sh) and had no issue. About the use of the "ws2_32" library, the 32 is both for 32bit and 64bit. Windows 64 provides the "win32" API. It's a name, they could also have named it "windows-api-after-dos" and it's not going away nor changing in incompatible ways any time soon. I've replaced the invocation of "ocamlrun -version" with "ocamlc -version": That made it possible to replace sed with cut (in order to strip the +dev... part in the version). For patch 15, you said: For patch 23, you said: I've replaced: Is it what you had in mind? |
Comment author: Camarade_Tux Actually I've borked the change in byterun/Makefile. I wrote: The corresponding file is 02-safe/0014-build-select-win32-variants-of-unix-and-graph-for-mi.patch . |
Comment author: meyer Adrien, thanks for the next round of patches. My answers for your questions:
My bad typo, I actually meant: don't put space after the comma. The space after comma is significant. Correct syntax is: I'd not use cut, sed seems to be better tool for that, but you are right if we want just base version than probably the regex you submitted is OK. |
Comment author: meyer Adrien, I tested and committed first 5 patches from 01-non-specific/. Please excuse doing that piece by piece, but I am also reviewing them during the tour. The next commits will contain the rest of the patches from 01-non-specific. |
Comment author: meyer Adrien, A small update: Sorry, as usually, I got very limited means of time, to commit and test the patches, but in essence I really like what you did with sub-dividing them. I will do my best to commit the rest from 01-non-specific/ during the week so we can move on with the rest of the patches. I will look if the compilation actually worked on anything else than mingw, like ARM. |
Comment author: meyer Patch 6/ inf() { printf "%b\n" "$*" 1>&3 } wrn() { printf "\nWARNING:\n" 1>&3 printf "%b\n\n" "$*" 1>&3 } err() { printf "\nERROR!\n" 1>&3 printf "%b\n\n" "$*" 1>&3 exit 2 } exec 3>&1 First you are writing to a custom descriptor 3, and then you will redirect everything from 3 to stdout (descriptor 1). What's the purpose? Patch 7/ -if echo $configure_options | grep -q ' --\?[a-zA-Z0-9-]\+='; then +if echo "$configure_options" | grep -qe '--\?[a-zA-Z0-9-]\+='; then two things:
Patch 8/ Sporious lines here: + amd64,macosx) as='as -arch x86_64' + aspp='gcc -arch x86_64 -c';; |
Comment author: Camarade_Tux Soooo. Back on this.
The reason is that the patch also does:
If stdout was used, the output from inf would pollute the one from echo. I prefer to make the function safer by also avoiding redirecting to stderr directly. I've checked the commit that was merged as rev 13312 and then reverted by Damien with rev 13456. It factored some code so that the right ranlib was called for some step. I'll update patch 7 to reflect your comments For patch 8, I don't have the spurious lines you mention. I'll continue after I have some sleep. |
Comment author: Camarade_Tux Here's another patch: 0001-build-replace-build-mk-config-myocamlbuild_config-.s.patch I've had to remove mkconfig.sh and mkmyocamlbuild_config.sh since they prevented me from doing other changes and I couldn't change them. Plus the approach wasn't the best. The next big change will be the removal of ocamlcomp.sh and the use of something more flexible which will make it possible to use the system compilers. |
Comment author: william Adrien, Could you please have a quick look at it, and give me hints on what I could do to simplify things further ? |
Comment author: meyer Your patch is very welcome. Few remarks from Damien:
otherwise looks good! and comments from me:
I attached modified patch, with exception for fix of --no-print-directory flag, has that been tested on BSD system? |
Comment author: Camarade_Tux Thanks for the feedback.
|
Comment author: meyer
So the most portable way to fix it would be to pattern match against the output you expect using grep, to filter out the messages from the Makefiles. |
Comment author: Camarade_Tux I've uploaded 0001-build-replace-build-mk-config-myocamlbuild_config-.s-2.patch It uses & instead of \0 for sed. It uses [:lower:] and [:upper:] instead of [a-z] and [A-Z] for tr. It keeps $(). --no-print-directory has been removed and instead the MAKEFLAGS and MAKELEVEL variables are unset in the shell script. This has been tested on Linux and FreeBSD. Windows should be like Linux since it's built with GNU userland too. |
Comment author: @protz I maintain the OCaml installer for Windows. If you want me to try one (or several) of your patches, let me know which ones, and I'll give it a try on Monday :). |
Comment author: Camarade_Tux I'm fairly certain this particular change won't break on Windows (I have a VM available but I've avoided starting it). That said, more testing is definitely welcome and even more for the windows installer. I don't have the next patches ready in advance since that would mean updating them for trunk very often and repeatedly but testing the current trunk (and with the mkconfig/myocamlbuild_config patch if possible) would already be great. Thanks. |
Comment author: Camarade_Tux William, it's fairly difficult to tell you which patch would still be needed and even more because you have patches that only apply to you/mxe. Instead I can tell you which patches I still have to get integrated. Before I forget about it, there's the bug 5887.
|
Comment author: Camarade_Tux New patches. :) Archive file is cross-patches-2013-09-07.tar.gz . The archive contains a new version of the last patch: on Windows, the ml code from the config makefiles has to be at the end of the file because it refers to other variables.
Also, something had to break on Windows for stupid reasons: an unused variable "DO" in the config makefiles, turned into "let do = ..." in OCaml, which gives a syntax error. Well, frustrating and fixed:
I've also been running full tests on Windows, FreeBSD and Linux: configure, build, make, install, testsuite. I found a few issues, notably that ocamldoc.opt was not built anymore on Windows:
The new big patch is "build: replace ocamlcomp*.sh.". This patch requires a new boot/myocamlbuild.boot file. It's described in the commit message but I've also added a specific patch so that the myocamlbuild.boot update is not forgotten.
Then, 3 patches make it possible to chose the ocamldoc command to run during the build since for cross-compilation, ocamldoc won't be built and we'll have to use the one from the system.
Finally, a cosmetic patch:
edit: this leaves only very few changes left: #5887, using int64 instead of nativeint in asmcomp, introduce variables to distinguish between host and target compilers, and make sure we use the right commands everywhere. (and a couple more misc changes) |
Comment author: Camarade_Tux I've pushed cross-patches-2013-09-07-fixed.tar.gz .
Discard the previous tarball and the two previous patches: this new tarball includes everything. |
Comment author: Camarade_Tux The jenkins build bots have uncovered three issues with the most recent patches.
I've uploaded fixes for the first two issues. This leaves the last one which I'll tackle on tomorrow. The patches have been tested on gnu/linux with make and with pmake (which is the parent to the bsd makes) and also on openbsd. The two patches are available as: 0001-build-fix-make-clean-failure-when-.-configure-hasn-t.patch Sorry for the breakage. |
Comment author: Camarade_Tux I've uploaded a new patch to fix the issue on Windows: I have only tried it on my machine but it doesn't introduce anything new: it simply adds a variable to a blacklist and matches better the blacklist of build/mk{config,myocamlbuild_config}.sh. |
Comment author: meyer Thank you applied. |
Comment author: Camarade_Tux I've uploaded two patches: 0001-build-ocamlmklib-on-Windows-expect-a-Windows-style-p.patch They fix the current issues noticed on the jenkins build bots. Basically, the first one adds a call to "cygpath -m" because ocamlmklib is a Win32 executable and requires Win32 paths. The second one fixes a change I had done in config/Makefile.mingw but skipped in config/Makefile.{mingw64,msvc,msvc64}. |
Comment author: @garrigue Small bug in trunk: ocamlbuild uses ocamlc.opt even if it isn't the newest compiler. |
Comment author: Camarade_Tux Hi, I'm really sorry for this issue. There is indeed clearly an issue in myocamlbuild.ml. I'll have it a go at it this evening. |
Comment author: Camarade_Tux I spent some time on the issue and something doesn't feel right in myocamlbuild.ml. I can't understand why the "native_deps" list in the code below refers to .cmxa, .cmx and .o files. Unless I'm mistaken, these files won't be used during the compilation or link process. The corresponding code: |
Comment author: meyer Adrien, at the moment we should not care too much about myocamlbuild.ml as we don't use it normally, and these scripts are planned to be removed in the future. I'm committing your patches at the moment. Please note that there are bootstrapping problems at the moment on trunk, e.g. the ocamllex used to build fresh ocaml is being build with the new ocaml and not the bootstrapped version. |
Comment author: Camarade_Tux Well, something has to be changed to fix the aforementionned issue. I believe the patch will be quite simple but I need to understand why using the opt-compiled bytecode compiler requires to have .cmx(a) files around. As for other patches, I'm not sure which ones you have in mind. |
Comment author: meyer currently these ones are pending:
I'm going to spend some time on it, over the week, probably I will get Damien to review them. |
Comment author: Camarade_Tux Hmm, in this list, patches up to 6 (included) at least are already in. That said, we should probably wait for one or two weeks for the current things to settle before continuing. |
Comment author: Camarade_Tux I've uploaded one file: Also, there is no need to consider previous patches in mantis; I will take care of reuploading updated versions of the ones that haven't been applied. The patch fixes the issue reported above by Jacques and the second one fixes bootstrapping issues Alain Frisch has encountered. I've checked that the .cmx/cmxa/o files that ocamlbuild was looking for were not required by chown root:root + chmod 640; the build process didn't fail unlike when I applied that to the .cmo file. PS: I really wish I could remove some of the files I've uploaded (found out they were broken right after uploading) |
Comment author: @gasche Sorry for not having any time to look at the ocamlbuild issue. Re. faulty uploads: just send me a precise list of stuff to remove, here or by email. I haven't followed the discussion recently but I can still click "Delete". |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
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 :
Best regards,
William
File attachments
The text was updated successfully, but these errors were encountered: