You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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: 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";;
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.
The text was updated successfully, but these errors were encountered: