Skip to content
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

More information in ocamlc -config #7172

Closed
vicuna opened this issue Mar 11, 2016 · 22 comments · Fixed by #11819
Closed

More information in ocamlc -config #7172

vicuna opened this issue Mar 11, 2016 · 22 comments · Fixed by #11819

Comments

@vicuna
Copy link

vicuna commented Mar 11, 2016

Original bug ID: 7172
Reporter: @dbuenzli
Assigned to: @dra27
Status: assigned (set by @mshinwell on 2016-12-14T11:38:40Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.3
Target version: 4.07.0+dev/beta2/rc1/rc2
Category: configure and build/install
Monitored by: @gasche @diml @dbuenzli

Bug description

It would be nice if ocamlc -config could report whether:

  1. Native compilation is available
  2. Native dynlinking is available.
@vicuna
Copy link
Author

vicuna commented Mar 11, 2016

Comment author: @mshinwell

I think we may need to fix matters for 4.03 such that there is a means of discovering whether Flambda is enabled or not. Perhaps we could just fix these all at once.

@vicuna
Copy link
Author

vicuna commented Mar 11, 2016

Comment author: @dbuenzli

@shinwell I'd be delighted if this could go into 4.03 and I may be tempted to hide the fact that ocamlc -config already reports if flambda is enabled or not.

@vicuna
Copy link
Author

vicuna commented Mar 11, 2016

Comment author: @mshinwell

Oh, so it does. Well it will probably have to wait then :p

@vicuna
Copy link
Author

vicuna commented Mar 11, 2016

Comment author: @dbuenzli

Grrrrr.

@vicuna
Copy link
Author

vicuna commented Mar 16, 2016

Comment author: @dbuenzli

Somehow I had hoped that I could fill the missing slots with:

$(ocamlc -where)/Makefile.config

but in fact this file seems to reflect the output of the configure process, not of what is actually installed, e.g. on a bytecode only switch like:

https://github.com/ocaml/opam-repository/blob/master/compilers/4.02.3/4.02.3%2Bbytecode-only/4.02.3%2Bbytecode-only.comp

NATDYNLINK will be true even though there no actual dynlink.cmxa. In fact reading the INSTALL file it seems there's no way to configure ocaml to be bytecode only.

So I guess I'm left with discovery hacks.

I'm thinking about:

  • native code compilation is available if $(ocamlc -where)/libasmrun.$(EXT_DLL) exists
    (looking up ocamlopt in the path can be a bit unreliable, for example in a bytecode only switch ocamlopt may actually be in the path, but it's the ocamlopt of the system compiler...)

  • native dynlinking is available if $(ocamlc -where)/dynlink.cmxa exists

Does it sound reasonable ?

@vicuna
Copy link
Author

vicuna commented Mar 16, 2016

Comment author: @dbuenzli

That is libasmrun.$(EXT_LIB) rather than $(EXT_DLL).

@vicuna
Copy link
Author

vicuna commented Mar 16, 2016

Comment author: @gasche

I needed a -no-native-compiler configure option to test the bytecode-only build of ocamlbuild, and added it to the script in #387. The relevant variables should be set to a meaningful value in this case, and the fact that this is not done for NATDYNLINK comes from an (independent) omission in the relevant logic:

https://github.com/ocaml/ocaml/blob/d3d30f3/configure#L874-L878

I need to document the -no-native-compiler switch in the INSTALL file, and I think I will fix the configure script as well.

@vicuna
Copy link
Author

vicuna commented Mar 17, 2016

Comment author: @dbuenzli

Also it would be nice to give us ext_exe, since the logic is a little bit twisted and requires to consult both ccomp_type and os_type. There is the EXE variable in Makefile.config but I now decided I'd rely only on the output of ocamlc -config.

@vicuna
Copy link
Author

vicuna commented Mar 24, 2016

Comment author: @damiendoligez

@dbuenzli your "discovery hacks" look quite reasonable to me.

It's not clear to me how ocamlc -config could know whether the native compiler was built or anything about the build process. Currently, it relies only on information from configure.

I agree with ext_exe.

@vicuna
Copy link
Author

vicuna commented Mar 24, 2016

Comment author: @dbuenzli

@doligez The solution is to be able to specify whether native compilers should be built in the configure of course.

@vicuna
Copy link
Author

vicuna commented Mar 24, 2016

Comment author: @gasche

I proposed
#513
to solve this issue.

@vicuna
Copy link
Author

vicuna commented Apr 4, 2016

Comment author: @gasche

#513 has just been merged in 4.03 and trunk. ./configure -no-native-compiler now sets NATDYNLINK=false in Makefile.config.

@vicuna
Copy link
Author

vicuna commented Jun 30, 2016

Comment author: @dbuenzli

Another bit that is useful for build systems to know an that should be reported by ocamlc -config is the value of Sys.word_size on the target platform. This is useful even for OCaml programs as it affects the size of ocaml integers.

Currently workarounds include:

  1. Grepping for SIZEOF_PTR in $(ocamlc -where)/caml/config.h
  2. Trying to pattern match on the values of architecture: and model: of ocamlc -config and try to infer the size based on the meaning of these keys according to

    ocaml/configure

    Lines 810 to 862 in 4ca0ca4

    case "$target" in
    sparc*-*-solaris2.*) arch=sparc; system=solaris;;
    sparc*-*-*bsd*) arch=sparc; system=bsd;;
    sparc*-*-linux*) arch=sparc; system=linux;;
    sparc*-*-gnu*) arch=sparc; system=gnu;;
    i[3456]86-*-linux*) arch=i386; system=linux_`sh ./runtest elf.c`;;
    i[3456]86-*-*bsd*) arch=i386; system=bsd_`sh ./runtest elf.c`;;
    i[3456]86-*-nextstep*) arch=i386; system=nextstep;;
    i[3456]86-*-solaris*) if $arch64; then
    arch=amd64; system=solaris
    else
    arch=i386; system=solaris
    fi;;
    i[3456]86-*-haiku*) arch=i386; system=beos;;
    i[3456]86-*-beos*) arch=i386; system=beos;;
    i[3456]86-*-cygwin*) arch=i386; system=cygwin;;
    i[3456]86-*-darwin*) if $arch64; then
    arch=amd64; system=macosx
    else
    arch=i386; system=macosx
    fi;;
    i[3456]86-*-gnu*) arch=i386; system=gnu;;
    i[3456]86-*-mingw*) arch=i386; system=mingw;;
    powerpc64le*-*-linux*) arch=power; model=ppc64le; system=elf;;
    powerpc*-*-linux*) arch=power;
    if $arch64; then model=ppc64; else model=ppc; fi
    system=elf;;
    powerpc-*-netbsd*) arch=power; model=ppc; system=elf;;
    powerpc-*-openbsd*) arch=power; model=ppc; system=bsd_elf;;
    s390x*-*-linux*) arch=s390x; model=z10; system=elf;;
    armv6*-*-linux-gnueabihf) arch=arm; model=armv6; system=linux_eabihf;;
    arm*-*-linux-gnueabihf) arch=arm; system=linux_eabihf;;
    armv7*-*-linux-gnueabi) arch=arm; model=armv7; system=linux_eabi;;
    armv6t2*-*-linux-gnueabi) arch=arm; model=armv6t2; system=linux_eabi;;
    armv6*-*-linux-gnueabi) arch=arm; model=armv6; system=linux_eabi;;
    armv6*-*-freebsd*) arch=arm; model=armv6; system=freebsd;;
    earmv6*-*-netbsd*) arch=arm; model=armv6; system=netbsd;;
    earmv7*-*-netbsd*) arch=arm; model=armv7; system=netbsd;;
    armv5te*-*-linux-gnueabi) arch=arm; model=armv5te; system=linux_eabi;;
    armv5*-*-linux-gnueabi) arch=arm; model=armv5; system=linux_eabi;;
    arm*-*-linux-gnueabi) arch=arm; system=linux_eabi;;
    arm*-*-openbsd*) arch=arm; system=bsd;;
    zaurus*-*-openbsd*) arch=arm; system=bsd;;
    x86_64-*-linux*) arch=amd64; system=linux;;
    x86_64-*-gnu*) arch=amd64; system=gnu;;
    x86_64-*-freebsd*) arch=amd64; system=freebsd;;
    x86_64-*-netbsd*) arch=amd64; system=netbsd;;
    x86_64-*-openbsd*) arch=amd64; system=openbsd;;
    x86_64-*-darwin*) arch=amd64; system=macosx;;
    x86_64-*-mingw*) arch=amd64; system=mingw;;
    aarch64-*-linux*) arch=arm64; system=linux;;
    x86_64-*-cygwin*) arch=amd64; system=cygwin;;
    esac

@vicuna
Copy link
Author

vicuna commented Dec 13, 2016

Comment author: @dbuenzli

shinwell asked me to update on the status of this bug. So in 4.04, ocamlc -config still does not report the following useful tidbits:

  • ext_exe
  • word_size
  • natdynlink
  • nativecomp

@vicuna
Copy link
Author

vicuna commented Dec 13, 2016

Comment author: @gasche

#970

@vicuna
Copy link
Author

vicuna commented Dec 14, 2016

Comment author: @dra27

#970 adds ext_exe, word_size and possibly natdynlink.

A suggestion for nativecomp (and really natdynlink) would to be change the logic for make install. At present, if native code has been built then it is installed, but we could instead make it that if native code has been configured then make install fails if it has not also been built (same could sensibly be done at the same time for opt.opt).

At present, Windows should be configured so that opt and opt.opt are assumed.

@vicuna
Copy link
Author

vicuna commented Dec 14, 2016

Comment author: @gasche

So after discussion with dra, #970 only includes int_size, word_size and ext_exe. I won't work on natdynlink and nativecomp myself in the 4.05 timeline, so I just un-assigned myself.

@vicuna
Copy link
Author

vicuna commented Dec 14, 2016

Comment author: @dra27

So int_size, word_size and ext_exe are merged and will be in 4.05.0

I've assigned the issue and hope to have a GPR for natdynlink and nativecomp ready for the 4.05 freeze.

@dbuenzli
Copy link
Contributor

dbuenzli commented Jun 12, 2020

  • natdynlink
  • nativecomp

Are still missing (at least in 4.10) and would be nice to have.

@dbuenzli
Copy link
Contributor

I think I can do without nativecomp. But natdynlink is needed to understand the output of ocamlmklib for C stubs (if not available only a .a is generated).

Is natdynlink implied by supports_shared_libraries by any chance ?

@dbuenzli
Copy link
Contributor

But natdynlink is needed to understand the output of ocamlmklib for C stubs (if not available only a .a is generated).

That formulation is a bit inexact I'm confusing two things here:

  1. There is support for C dynamic linking (e.g. used by bytecode for loading primitives of C stubs)
  2. The OCaml native dynlink API, (i.e. the ability to produce .cmxs files)

I highly suspect supports_shared_libraries answers at least 1. I'm unsure whether it answers 2.

@ocaml ocaml deleted a comment from github-actions bot Dec 22, 2022
@shindere shindere reopened this Dec 23, 2022
@shindere
Copy link
Contributor

This has now been fixed by #11819, which should be available in OCaml 5.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants