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

[cross-compilation] Use target's ld as a basis for ${partialld} #7121

Closed
vicuna opened this issue Jan 11, 2016 · 1 comment
Closed

[cross-compilation] Use target's ld as a basis for ${partialld} #7121

vicuna opened this issue Jan 11, 2016 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Jan 11, 2016

Original bug ID: 7121
Reporter: adrien
Status: acknowledged (set by @damiendoligez on 2016-02-08T11:38:08Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.3
Category: configure and build/install
Tags: cross-compilation, patch

Bug description

Currently, the ${partialld} variable in configure is either provided or guessed as "ld -r" or "ld -r -arch ppc64/x86_64" or "ld -r -m elf_x86_64". For cross-compilation, something starting with "${TARGET_TRIPLET}-ld" is needed.

The following diff, which I'm not very happy with, solves the issue for me:

diff --git a/configure b/configure
index e5ae7a5..0fd96b5 100755
--- a/configure
+++ b/configure
@@ -884,6 +884,7 @@ case "$arch,$nativecc,$system,$model" in
power,gcc*,elf,ppc) partialld="ld -r -m elf32ppclinux";;
power,gcc*,elf,ppc64) partialld="ld -r -m elf64ppc";;
power,gcc*,elf,ppc64le) partialld="ld -r -m elf64lppc";;

  • ,gcc,,*) partialld="${target}-ld -r";;
    esac

asppprofflags='-DPROFILING'

If the user has provided the value for partialld on the ./configure command-line, the value can get overwritten (this is already the case). The current case/in/esac construct also seems to have grown quite organically.

Does anyone know whether the architectures in the list (nextstep, rhapsody, mac os x amd64, solaris amd64, linux ppc32, ppc64, ppc64le) are supported and whether they come with prefixed toolchains.

Strictly speaking, binutils can support various file formats. For instance, slackware64 doesn't ship a 32-bits nor windows toolchains but its binutils have been configured to handle the corresponding executables (I guess that some maintainers like to play with old games [ or UEFI but that's less likely :) ]). However, it seems unlikely someone would rely on that to build OCaml and figuring out the values to -m or -arch is very difficult (and probably impossible to automate in a sane way). Therefore, trying to prefixed tools seems like the best option to me.

@github-actions
Copy link

github-actions bot commented May 9, 2020

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.

@github-actions github-actions bot added the Stale label May 9, 2020
dra27 added a commit to dra27/ocaml that referenced this issue May 13, 2020
dra27 added a commit to dra27/ocaml that referenced this issue May 13, 2020
dra27 added a commit to dra27/ocaml that referenced this issue Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant