Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006779OCaml~DO NOT USE (was: OCaml general)public2015-02-11 18:442016-12-07 11:29
Reporterwhitequark 
Assigned Todoligez 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.02.2+dev / +rc1Fixed in Version4.02.2 
Summary0006779: Cross-compilers cannot link bytecode executables using custom primitives
DescriptionThe 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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0006845closeddoligez New mode where ocamlc doesn't check list of primitives 

-  Notes
(0013270)
gasche (administrator)
2015-02-11 22:48

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.
(0013278)
adrien (reporter)
2015-02-15 18:24

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.
(0013279)
whitequark (developer)
2015-02-15 18:30

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-android[1]. 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.

[1]: https://github.com/whitequark/opam-android/ [^]
(0013280)
whitequark (developer)
2015-02-15 18:39

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.
(0013281)
adrien (reporter)
2015-02-15 18:48

> 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 think that still leaves out Windows which is my criteria (along with using ./configure).

> 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.

Quite probably. The need to spawn an external executable is why I wrote "fast" too. :)

> 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).

Agreed. I won't be touching this anytime soon however so at least it's unlikely that effort is duplicated.
(0013282)
whitequark (developer)
2015-02-15 18:52

>The need to spawn an external executable is why I wrote "fast" too. :)

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...
(0013283)
adrien (reporter)
2015-02-15 18:56

BFD is GPL.
(0013284)
whitequark (developer)
2015-02-15 18:59

spawn it is, then.
(0013753)
doligez (administrator)
2015-04-28 17:45

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.
(0013757)
whitequark (developer)
2015-04-28 17:55

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.
(0013759)
adrien (reporter)
2015-04-29 00:13

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.
(0013773)
doligez (administrator)
2015-04-30 21:51

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.
(0013779)
whitequark (developer)
2015-05-02 16:03

Nice short fix. I confirm that it works.
(0013780)
whitequark (developer)
2015-05-02 16:06

I think the fix should be forward-ported to trunk.
(0014274)
gasche (administrator)
2015-07-25 22:05

This has now been merged in trunk by Damien's big merge commit.
(0014471)
adrien (reporter)
2015-09-20 21:02

I only recently realized that such checks were wanted by more than OCaml. For instance, mageia uses ld's --no-undefined:

       --no-undefined
       -z defs
           Report unresolved symbol references from regular object files.
           This is done even if the linker is creating a non-symbolic shared
           library. The switch --[no-]allow-shlib-undefined controls the
           behaviour for reporting unresolved references found in shared
           libraries being linked in.

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).
(0014472)
whitequark (developer)
2015-09-20 22:38

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.
(0014473)
adrien (reporter)
2015-09-21 08:26

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.

- Issue History
Date Modified Username Field Change
2015-02-11 18:44 whitequark New Issue
2015-02-11 22:48 gasche Note Added: 0013270
2015-02-15 18:24 adrien Note Added: 0013278
2015-02-15 18:30 whitequark Note Added: 0013279
2015-02-15 18:39 whitequark Note Added: 0013280
2015-02-15 18:48 adrien Note Added: 0013281
2015-02-15 18:52 whitequark Note Added: 0013282
2015-02-15 18:56 adrien Note Added: 0013283
2015-02-15 18:59 whitequark Note Added: 0013284
2015-02-23 23:05 doligez Status new => acknowledged
2015-02-23 23:05 doligez Target Version => 4.02.2+dev / +rc1
2015-04-22 20:02 whitequark Relationship added related to 0006845
2015-04-28 17:45 doligez Note Added: 0013753
2015-04-28 17:45 doligez Assigned To => doligez
2015-04-28 17:45 doligez Status acknowledged => feedback
2015-04-28 17:55 whitequark Note Added: 0013757
2015-04-28 17:55 whitequark Status feedback => assigned
2015-04-29 00:13 adrien Note Added: 0013759
2015-04-30 21:51 doligez Note Added: 0013773
2015-04-30 21:51 doligez Status assigned => feedback
2015-05-02 16:03 whitequark Note Added: 0013779
2015-05-02 16:03 whitequark Status feedback => assigned
2015-05-02 16:03 whitequark Status assigned => resolved
2015-05-02 16:03 whitequark Resolution open => fixed
2015-05-02 16:06 whitequark Note Added: 0013780
2015-07-25 22:05 gasche Note Added: 0014274
2015-09-20 21:02 adrien Note Added: 0014471
2015-09-20 22:38 whitequark Note Added: 0014472
2015-09-21 08:26 adrien Note Added: 0014473
2015-11-23 14:58 xleroy Fixed in Version => 4.02.2
2016-12-07 11:29 xleroy Status resolved => closed
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker