Re: [ports-gcc/all archs] fix lang/hashlink

On Thu, Mar 05, 2020 at 01:56:43PM +0100, Charlene Wendling wrote:
> Hi,
>
> > http://build-failures.rhaalovely.net/sparc64/2020-03-01/lang/hashlink.log
>
> - C11 requires ports-gcc, so i added COMPILER

This does build on sparc64. Not sure how to test it though, as haxe is
marked broken.

Shouldn't this set COMPILER_LANGS = c also? At least that's what
Makefile.template seems to imply:

# Ports that require a non-default compiler that do *not* use C++ should
# set this:
#COMPILER_LANGS = c

Apart from that your patch looks good to me.

ok tb


Further comments for thfr@ below.

> - then the build fails because we don't have gethostbyaddr_r(), so i
> used the fallback code like it was already the case for other
> functions. Clang is unhappy as well, but too permissive as usual.
> - while collecting the patch i have found out that it had DOS line
> endings, so i fixed all patches that have them. Because of that
> i'm attaching the diff.
>
> Once all that stuff has been done, it builds on powerpc [0] and is still
> good on amd64.
>
> Comments/feedback are welcome :)


The use of pthread_self() in patches/patch-src_std_thread_c looks fishy.
It generates this warning:

src/std/thread.c: In function 'hl_thread_id':
src/std/thread.c:374:9: warning: returning 'pthread_t' {aka 'struct pthread *'} from a function with return type 'int' makes integer from pointer without a cast
[-Wint-conversion]
return pthread_self();
^~~~~~~~~~~~~~

Is this intended and really correct?


The second one is ugly but probably harmless:

===> Building for hashlink-1.10p0
getconf: LONG_BIT: unknown variable

The Makefile tries to set some arch-specific things using this:

LBITS := $(shell getconf LONG_BIT)
ARCH ?= $(LBITS)
[...]
ifeq ($(ARCH),32)
CFLAGS += -I /usr/include/i386-linux-gnu
LIBFLAGS += -L/opt/libjpeg-turbo/lib
else
LIBFLAGS += -L/opt/libjpeg-turbo/lib64
endif