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
Cross-compilers cannot link bytecode executables using custom primitives #6779
Comments
Comment author: @gasche This could be discussed with Adrien Nader which worked on the topic previously -- I suspect generally on cross-compilation you're duplicating a bit of the design/work he's done, so maybe his opinion could be a good double-check. |
Comment author: adrien I've already raised the issue but I don't remember where the discussion happened: caml-list or mantis (it's already been more than one year). Basically, Xavier Leroy said he was quite eager to keep the current compile-time safety rather than delaying the checks at run-time. I don't think there's a simple and fast way to do such checks for cross-compilation. I have to say it's quite low on my list of issues: full support for cross-compilation in upstream releases is quite far from being available and this is simple to patch away and I've settled on keeping a patch that disables the check. |
Comment author: @whitequark Actually 4.02.2 is likely to have patch-less support for cross-compilation (assuming you provide Makefile.config, m.h and s.h.) I've built a lot of libraries for opam-android1. Pure OCaml cma, cmxa, cmxs build perfectly well as well as those with C components. I think this would be the main issue left actually. |
Comment author: @whitequark I actually think the check could be still made during cross-compiling in the same way as objinfo currently works: using a helper executable using libbfd. I think it would be even better if this was done also when /not/ cross-compiling, so that the compiler will not invoke any side effects on loading a stubs library (like invoking the global C++ constructors). I believe this is actually a problem for stubs produced for statically linked LLVM. |
Comment author: adrien
I think that still leaves out Windows which is my criteria (along with using ./configure).
Quite probably. The need to spawn an external executable is why I wrote "fast" too. :)
Agreed. I won't be touching this anytime soon however so at least it's unlikely that effort is duplicated. |
Comment author: @whitequark
Well, you could make a direct interface using C stubs, but that's considerably more annoying to handle conditionally. libbfd isn't present everywhere, too, although the detection code is already there for objinfo. We could reuse it to get rid of the objinfo_helper, too... |
Comment author: adrien BFD is GPL. |
Comment author: @whitequark spawn it is, then. |
Comment author: @damiendoligez I don't think it's reasonable to expect a BFD-based solution before 4.02.2. How easy is it to check for cross-compilation? Dropping the check for all compilations is not acceptable, but we could do it for cross-compilation as an interim solution. |
Comment author: @whitequark OCaml's buildsystem currently has no knowledge of whether it builds a cross-compiler or not. An explicit HOST/TARGET variables in Makefile.config might be the solution. |
Comment author: adrien HOST and TARGET variables are already there. These variables can be found in config/Makefile and utils/config.mlp at least. They should be visible everywhere. |
Comment author: @damiendoligez I have committed a fix in 4.02 (rev 16057). Please test and tell me if it does the right thing in a cross-compilation setup. |
Comment author: @whitequark Nice short fix. I confirm that it works. |
Comment author: @whitequark I think the fix should be forward-ported to trunk. |
Comment author: @gasche This has now been merged in trunk by Damien's big merge commit. |
Comment author: adrien I only recently realized that such checks were wanted by more than OCaml. For instance, mageia uses ld's --no-undefined:
There's also libtool for Windows which has -no-undefined (only one dash and not the same executable) which hits the same things but differently I think. I know both work for cross-compilation and it should be interesting to see whether they can be used to get the check for ocaml's cross-compilation too (because of lack of time for that, I haven't /tried/ to think about much so I have absolutely no idea whether that will be useful or not but I thought it was important to share these if someone were to start working on this). |
Comment author: @whitequark Yes, it should be very much possible to use --no-undefined for this purpose. However, it sometimes breaks badly written code, so some care would be needed to roll it out. |
Comment author: adrien I'm fairly confident. There are around 120 (C) packages in win-builds.org and I haven't yet seen such issues or they were issues that would have happened at runtime anyway. Moreover, Mageia uses that for all of its packages and they have quite a lot of them. |
git-svn-id: http://caml.inria.fr/svn/ocaml/version/4.02@16057 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Original bug ID: 6779
Reporter: @whitequark
Assigned to: @damiendoligez
Status: closed (set by @xavierleroy on 2016-12-07T10:29:43Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.02.2+dev / +rc1
Fixed in version: 4.02.2
Category: ~DO NOT USE (was: OCaml general)
Related to: #6845
Monitored by: @gasche
Bug description
The reason is that Symtable.num_of_prim uses Dll, but a cross-compiler cannot load shared libraries at compile-time. Thus a cross-compiler should always build executables with -custom, or at least do that if any cma's using custom primitives are linked in.
Alternatively, just drop the check entirely if cross-compiling. It does not seem to serve any purpose besides making really sure that the primitive actually exists.
The text was updated successfully, but these errors were encountered: