#14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox):
That being said, I am a bit confused about the armv7a-hardfloat-linux- gnueabi target. Shouldn't that be armv7-unknown-linux-gnueabihf
This triplet is recognized by autoconf, gcc, glibc and binutils just fine and generated by GHC binaries worked.
Should we use Autoconf triple canonicalization here?
I don't think canonicalization will give you much here. You can't match triples for exat match anyways. A few fields can be used to inject custom strings, like ${vendor}. I use ${vendor} a lot to distinct between locally installed toolchains (default-pie, default-nopie, etc.) {{{ ghc $ ./config.sub armv7a-hardfloat-linux-gnueabi armv7a-hardfloat-linux-gnueabi ghc $ ./config.sub armv7a-unknown-linux-gnueabi armv7a-unknown-linux-gnueabi ghc $ ./config.sub x86_64-UNREG-linux-gnu x86_64-UNREG-linux-gnu }}} I guess it depends what gen-data-layout.sh script tries to fish out of the triple. It looks like what it really needs is: - CPU architecture (that's the first field of triple) - FPU ABI Normally how autoconf scripts do it is they match for known templates: {{{ case ${target} in armv[78]-*) something;; *-ghueabihf) something-else;; armv[678]-hardfloat-*) another-thing;; ... }}} It's a bit fragile though. More precise way would be to interrogate available toolchain. Either through dumping of defined macros for a target compiler and check for features you need to construct proper llvm string or compile-test things in autoconf way. If all above it tedious I'm fine to have a manual mechanism of passing required info manually at ./configure time (or whenever appropriate). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14261#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler