On Mon, May 27 2019, Philip Guenther <[email protected]> wrote:
> On Mon, May 27, 2019 at 3:43 PM Brian Callahan <[email protected]> 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...
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
