On 5/28/19 8:21 AM, Jeremie Courreges-Anglas wrote:
On Mon, May 27 2019, Philip Guenther <guent...@gmail.com> wrote:
On Mon, May 27, 2019 at 3:43 PM Brian Callahan <call...@rpi.edu> wrote:
Below is a small diff in response to some configuration attempts
found in ports land.
lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to
determine whether or not we're on a 64-bit platform.
It needs to know that at the scripting level, outside of the C code itself
where it can directly test LONG_BIT (or perhaps better, _LP64)? Huh.
However, our getconf(1) doesn't support reporting LONG_BIT.
This diff enables it. GNU/FreeBSD/DragonFly/MacOS getconf reports
LONG_BIT, but NetBSD getconf does not.
Desirable? OK?
That's the way to do it, I just have this vague "what tempting lunacy has
led them to this?" lurking in my mind.
I'll let Brian confirm but this got me curious. Here's the dance
I found in the Makefile for ponyc:
--8<--
# Default settings (silent release build).
config ?= release
arch ?= native
tune ?= generic
cpu ?= $(arch)
fpu ?=
bits ?= $(shell getconf LONG_BIT)
[...]
# Determine pointer size in bits.
BITS := $(bits)
UNAME_M := $(shell uname -m)
ifeq ($(BITS),64)
ifeq ($(UNAME_M),x86_64)
ifeq (,$(filter $(arch), armv8-a))
BUILD_FLAGS += -mcx16
LINKER_FLAGS += -mcx16
endif
endif
endif
-->8--
So IIUC the build tries to use -mcx16 on amd64, except if the target
architecture is armv8-a. This looks bogus, I guess what upstream wants
is to use -mcx16 only when doing a build *targetting* amd64. The value
of LONG_BIT on the build machine doesn't seem relevant to achieve that,
but I may be missing something.
Welcome to ports...
I can confirm with upstream, but I read it as they want to avoid adding
the flag if you're using the x32 ABI... but I agree with you in that
using the build machine info to understand something about the target
machine isn't the right way to go about it.
~Brian
