Bug 231393 - lang/gprolog: Update to 1.4.5, Fix gcc8 run failure on FreeBSD11.2S, Use clang
Summary: lang/gprolog: Update to 1.4.5, Fix gcc8 run failure on FreeBSD11.2S, Use clang
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Eugene Grosbein
URL:
Keywords: needs-patch, needs-qa
: 236372 (view as bug list)
Depends on:
Blocks: 236372
  Show dependency treegraph
 
Reported: 2018-09-16 08:51 UTC by dewayne
Modified: 2020-11-27 04:30 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dewayne 2018-09-16 08:51:58 UTC
Environment
FreeBSD 11.2-STABLE  r338612M amd64 hqdev-amd64-smp-vga 1102501 1102501
clang 6.0.1 and/or gcc8.2.0 

Suggest that the following changes are made to the Makefile
1. Remove the need for gcc.  As gprolog does NOT work with gcc8, clang 6.0.1 ok
2. Add the requirement to disable-regs for amd64 (already in place for i386)
3. Upgrade the version from 1.4.4 to 1.4.5

1. With gcc8, the package is correctly built, however both
gprolog
gplc $FILE
hang indefinitely. To my pleasant surprise this port works with clang 6.0.1.

2. Without disable-regs, on amd64 we get 
gplc -c -C '-pipe -g0 -fno-math-errno -fomit-frame-pointer -march=haswell -O3 -fno-stack-protector -fno-strict-aliasing' machine.c
receive error messages such as 
cc: error: unknown argument: '-ffixed-r12'
cc: error: unknown argument: '-ffixed-r13'
cc: error: unknown argument: '-ffixed-r14'
cc: error: unknown argument: '-ffixed-r15'

A similar result occurs on i386 (and yes there is a conditional in the Makefile that sets this, but worth mentioning).

Perhaps an additional test would be in order
.if ${OPSYS} == FreeBSD && ${OSVERSION} > 1102500
CONFIGURE_ARGS+=               --disable-regs
.else
USE_GCC=       any
.endif

I spent a lot of time getting this to work, my Makefile is dotted with comments otherwise I'd provide a diff.

3. After getting 1.4.4 to work again, I successfully built 1.4.5 with and without FD.  However with "registers", a compile fails using both clang, refer to message in point 2 above; while with gcc8 gprolog builds but hangs consuming 100% of a cpu (I suspect a spin lock).  So disable-regs is required.  I don't have other gcc versions, though 1.4.4 did run successfully with gcc7 on FreeBSD11.1S around May 2018.

An aside I also tested with cc -Ofast :)  all good; but I suspect that the option has made no difference. :/

-r-xr-xr-x  1 root  wheel  685248 Sep 16 18:04 /usr/local//gprolog-1.4.5/bin/gprolog # O3
-r-xr-xr-x  1 root  wheel  685248 Sep 16 18:10 /usr/local//gprolog-1.4.5/bin/gprolog # Ofast


and a very simple PROLOG file compiles to 

-rwxr-xr-x  1 root  wheel  751056 Sep 16 17:59 /tmp/a  # O3
-rwxr-xr-x  1 root  wheel  751056 Sep 16 18:11 /tmp/a  # Ofast
Comment 1 Rene Ladan freebsd_committer 2018-12-19 12:46:00 UTC
Can you provide a diff for version 1.4.5 ? The port expired today, but this PR could save it.
Comment 2 dewayne 2018-12-21 01:33:53 UTC
(In reply to Rene Ladan from comment #1)
I've modified the port's Makefile quite substantially. Things to note: I clang 6.0.1 to build and (this for a prescott build); and regs need to be disabled!

CFLAGS=-pipe -Wl,-m,elf_i386_fbsd -Wl,--strip-debug -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UEBUGGING -UDEBUG -fno-math-errno -fomit-frame-pointer -march=prescott -march=prescott  -Ofast -fno-strict-aliasing
LDFLAGS=-Wl,--strip-debug

Unfortunately I'm working remotely, so can't attach, only screen cut/paste; hope that this is of some use.
 
--- /usr/ports/lang/gprolog/Makefile    (revision 487933)
+++ /usr/ports/lang/gprolog/Makefile    (working copy)
@@ -2,8 +2,8 @@
 # $FreeBSD$

 PORTNAME=      gprolog
-PORTVERSION=   1.4.4
-PORTREVISION=  8
+PORTVERSION=   1.4.5
+#PORTREVISION= 7
 CATEGORIES=    lang
 MASTER_SITES=  http://www.gprolog.org/

@@ -12,15 +12,17 @@

 LICENSE=       GPLv2

-BROKEN=                fails to build
-DEPRECATED=            Abandonware upstream (more than five years), fails in various ways with remotely recent compilers
-EXPIRATION_DATE=       2018-12-18
+#BROKEN=               fails to build
+#DEPRECATED=           Abandonware upstream (more than five years), fails in various ways with remotely recent compilers
+#EXPIRATION_DATE=      2018-12-18

 ONLY_FOR_ARCHS=        i386 amd64

 USES=          gmake
-USE_GCC=       any
-CFLAGS+=       -O3 # gcc5/gcc6 + -O2 = pl2wam hangs
+# USE_GCC=     gcc8
+# gcc5/gcc6 + -O2 = pl2wam hangs (badly!) gcc -O3 seg faults with march=core-avx-i
+#CFLAGS+=      -O3
+CFLAGS+=       -Ofast
 PLIST_SUB=     GPROLOG_VER=${PORTVERSION}
 GNU_CONFIGURE= yes
 CONFIGURE_ARGS=        --with-c-flags="${CFLAGS}" \
@@ -42,8 +44,10 @@
 # Disable registers on i386. This fixes build with gcc6.
 # See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852008
 .if ${ARCH} == i386
+#CONFIGURE_ARGS+=              --disable-regs
+.endif
+# Required for both i386 and amd64
 CONFIGURE_ARGS+=               --disable-regs
-.endif

 post-patch:
        @${REINPLACE_CMD} \
@@ -50,4 +54,15 @@
                '/LINKS_DIR/s|$$(INSTALL_DIR)|../${PORTNAME}-${PORTVERSION}|' \
                ${WRKSRC}/Makefile.in

+post-install:
+        ${STRIP_CMD} ${STAGEDIR}${PREFIX}/sbin
+        ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin
+        ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib
+
+post-install-EXAMPLES-off:
+       ${RM} -r ${STAGEDIR}${EXAMPLESDIR}
+
+post-install-DOCS-off:
+       ${RM} -r ${STAGEDIR}${DOCSDIR}
+
 .include <bsd.port.mk>
Comment 3 Rene Ladan freebsd_committer 2018-12-22 17:33:22 UTC
I got it building on i386 (11.2, 12.0 and 13) but it fails to build on amd64 because of an assertion failure.

Build log for 11.2-amd64 is at http://82.161.212.209/data/11_2-amd64-default/2018-12-22_18h25m03s/logs/errors/gprolog-1.4.5.log

The patch is at https://people.freebsd.org/~rene/patches/gprolog.diff

Can you investigate the assertion failure? Also, would you like to become the new maintainer for this port?
Comment 4 dewayne 2018-12-29 23:45:29 UTC
Hi Rene.  Thank-you for looking into this.  My lang/gprolog (1.4.5) is running properly on amd64 FreeBSD11.2 but (!) it was built on 26 Sept.  Something has changed.  I'm currently rebuilding FreeBSD 11.2S to Last Changed Rev: 342588 (yesterday), as I noticed a revert that may matter (ast, mpx?

A quick look revealed that the .jcr elf segment exists in both the working i386 and amd64 grpolog and .jcr doesn't exist on the amd64 one that doesn't.  I'm struggling to find out what this segment does (dyn mem??)

i386
  [21] .jcr              PROGBITS        080c42bc 07b2bc 000004 00  WA  0   0  4

amd64
 [21] .jcr              PROGBITS        00000000006a4da8 0a4da8 000008 00  WA  0   0  8

Building gprolog on i386 is ok. Building with finite domains causes a Seg violation, as you describe. Building without finite domains results in a successful build, but a gprolog that stalls, consuming 100% of a cpu.  I recall something in the gprolog bug system, I'm continuing to look into it. I suspect somethings not right with gplc mixing CFLAGS parameters (?)
Comment 5 dewayne 2019-01-01 09:18:20 UTC
(In reply to dewayne from comment #4)
Unfortunately I've only been able to spend 5 hours on this.  After trying a lot of different options for an amd64 build I've had to give up (for now).

I suspect that the gprolog project is trying to be too smart by configuring various parameters during the build (refer to Makefile.in).  This 
https://sourceforge.net/p/gprolog/code/ci/68d4fa3796cbb350385e66848962fd6b279044d2/
seems to be configuring for PIC, but when gplc -C '-fPIC -fPIE' is consistently forced across the build, it fails; and when it isn't it fails.

Both Debian and Redhat appear to have problems too.  Also it doesn't help when a few bug reports, in other places, suggest that gprolog is (or has) identified gcc6+ compiler issues.  Which suggests that its either: really smart in how it operations; pushes the compiler to the limits; is trying to do things that it shouldn't or ?.  (suggest read through some of the wam src)

So I need to determine do I spend time manipulating the SWI prolog to run minimally (ie CLI, is that possible?), continue what I think will be a futile build-fix on gprolog, or turn to yap-devel...  As I have at best 4 hours on build issues per week, I might have to take the easy option.
Comment 6 Rene Ladan freebsd_committer 2019-02-24 15:20:07 UTC
Any update on this?
Comment 7 Matthias Andree freebsd_committer 2019-03-08 09:49:39 UTC
*** Bug 236372 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Andree freebsd_committer 2019-03-08 09:53:57 UTC
I've removed ther DEPRECATED tag and bumped EXPIRATION_DATE to 2019-08-31 to avoid fatalities when someone wields the scythe, or axe...
Comment 9 Rene Ladan freebsd_committer 2019-03-08 10:26:06 UTC
(In reply to Matthias Andree from comment #8)

Please add back the DEPRECATED tag, you cannot have a port with an expiration date that is not deprecated. See https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-deprecated.html
Comment 10 Rene Ladan freebsd_committer 2019-06-01 18:43:32 UTC
@dewayne: any updates on this? Version 1.4.5 at least builds fine on the i386 variant of 11.2, 12.0 and 13.0 (r347608), but it fails on amd64 (11.2 and 12.0 have the same error, but the one in 13.0 differs):

11.2 / 12.0:
> gplc -o pl2wam --no-fd-lib-warn --no-top-level pl2wam.o read_file.o syn_sugar.o internal.o code_gen.o reg_alloc.o inst_codif.o first_arg.o indexing.o wam_emit.o
> gplc -c --fast-math fd2c.pl
>
> Fatal Error: Segmentation Violation (bad address: 0x100ec814853)
> compilation failed

head:
> gplc -o pl2wam --no-fd-lib-warn --no-top-level pl2wam.o read_file.o syn_sugar.o internal.o code_gen.o reg_alloc.o inst_codif.o first_arg.o indexing.o wam_emit.o
> gplc -c --fast-math fd2c.pl
>
> Fatal Error: atom: invalid ATOM_NIL (should be 257)
> compilation failed
Comment 11 dewayne 2019-06-08 01:38:11 UTC
(In reply to Rene Ladan from comment #10)
Unfortunately no progress.  I applied the patch derived from a RedHat fix at
 https://lists.gnu.org/archive/html/bug-prolog/2018-11/msg00000.html
https://lists.gnu.org/archive/html/bug-prolog/2018-11/txtTqsnlDbpEZ.txt
but the build process failed with
...
gplc -c -C '-O2 -pipe  -O2 -fstack-protector-strong -fno-strict-aliasing  -funsigned-char' bc_supp.c
gplc -c foreign.wam
/tmp/gplc0A0izd.s: Assembler messages:
/tmp/gplc0A0izd.s:19: Error: junk `@hidden' after expression
/tmp/gplc0A0izd.s:29: Error: junk `@hidden' after expression
/tmp/gplc0A0izd.s:29: Error: too many memory references for `movq'
/tmp/gplc0A0izd.s:30: Error: junk `@hidden' after expression
/tmp/gplc0A0izd.s:30: Error: too many memory references for `movq'
/tmp/gplc0A0izd.s:31: Error: junk `@hidden' after expression
/tmp/gplc0A0izd.s:31: Error: too many memory references for `movq'
/tmp/gplc0A0izd.s:32: Error: junk `@hidden' after expression
...
/tmp/gplc0A0izd.s:75: Error: too many memory references for `movq'
/tmp/gplc0A0izd.s:76: Error: junk `@hidden' after expression
compilation failed

Unfortunately I lack the assembler skills to advance.
Comment 12 Alexey Dokuchaev freebsd_committer 2019-06-27 10:40:57 UTC
(In reply to dewayne from comment #11)

Let me try to resolve the mystery behind those weird assembler error messages you quoted.

If you downloaded the "x86_64_any.c" file via the link you've provided, not checked out from their repository, the file will be served mangled: all "foo@bar" strings would be treated as email addresses and thus hidden from spammers.  So the lines like

> Inst_Printf("jmp", UN "%s@PLT", label);
become

> Inst_Printf("jmp", UN "address@hidden", label);
:-)
Comment 13 Rene Ladan freebsd_committer 2019-07-28 11:11:10 UTC
Hi,

do you have any news on this?
Comment 14 dewayne 2019-07-29 06:34:51 UTC
(In reply to Alexey Dokuchaev from comment #12)
Thanks Alexey.  I didn't check the actual detail of the patch, only that the indentation and line changes were ok.

So I pulled code from 
https://sourceforge.net/p/gprolog/code/ci/9237de3b8a9a2ca20ac05e595c97cd923158568e/tree/src/Ma2Asm/x86_64_any.c
and 
https://mirror.freedif.org/GNU/gprolog/gprolog-latest.tar.gz which is actually 1.4.5 which is what I'm trying to use.  I did get gprolog 1.4.5 working on both i386 and amd64, but I didn't record the configuration (make.conf) details.

I've returned to the problem, but can only get a working gprolog on i386 (now on 11.3-Stable with clang 8.0.1).  The amd64 version doesn't get past 
/usr/bin/ld: /var/ports/usr/ports/lang/gprolog/work/gprolog-1.4.5/src/EnginePl/libengine_pl.a(engine1.o): relocation R_X86_64_32S against undefined symbol `pl_ensure_reserved' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
cc: error: linker command failed with exit code 1 (use -v to see invocation)
compilation failed

Unfortunately I'm resigned to this situation on amd64, and I'm now using caio and  lang/swi-pl (SWI-PROLOG) which I've hacked to only need the CLI (no xpce, no GPL code).
Comment 15 Alexey Dokuchaev freebsd_committer 2019-07-30 12:47:05 UTC
(In reply to dewayne from comment #14)

> lang/swi-pl (SWI-PROLOG) which I've hacked to only need the CLI (no xpce,
> no GPL code).
Could you upload your CLI-only'ing patch somewhere?  I should probably also try to update the port to the latest version (8.0.3).
Comment 16 Rene Ladan freebsd_committer 2019-09-01 15:37:29 UTC
Expired port removed.
Comment 17 commit-hook freebsd_committer 2020-11-23 13:26:23 UTC
A commit references this bug:

Author: eugen
Date: Mon Nov 23 13:26:16 UTC 2020
New revision: 556106
URL: https://svnweb.freebsd.org/changeset/ports/556106

Log:
  lang/gprolog: recover GNU Prolog under FreeBSD.

  Update to version 1.4.5 released in 2020.
  Make it build and run with Clang 10:

  - clang has no register reservation for x86, hence patch-EnginePl_machine.h
    and -DNO_MACHINE_REG_FOR_REG_BANK to prevent using missing feature;
  - add patch-Ma2Asm_x86__64__any.c fetched from upstream SourceForge
    post-release commit dealing with PIC issues;
  - disable usage of spinlocks that results in a hang eating all available
    CPU cycles; fixed with -DUSE_LOCKS=1 -DUSE_RECURSIVE_LOCKS=1
    -DUSE_SPIN_LOCKS=0;
  - the software uses bundled dlmalloc dated back 2011 that replaces
    functions like calloc() with own implemenations and it's calloc()
    sometimes fails to clear allocated memory; this results in SIGSEGV
    when its own hash-table implementation dereferences junk that
    supposed to be NULL pointer, so it fails to complete build;
    fixed with MMAP_CLEARS=0.

  PR:		231393

Changes:
  head/MOVED
  head/lang/Makefile
  head/lang/gprolog/
  head/lang/gprolog/Makefile
  head/lang/gprolog/distinfo
  head/lang/gprolog/files/
  head/lang/gprolog/files/patch-EnginePl_machine.h
  head/lang/gprolog/files/patch-Ma2Asm_x86__64__any.c
Comment 18 Alexey Dokuchaev freebsd_committer 2020-11-27 04:30:08 UTC
Reassigning to committer who actually solved the problem.  Thanks for the heavy lifting on this, Eugene!