Bug 231393
| Summary: | lang/gprolog: Update to 1.4.5, Fix gcc8 run failure on FreeBSD11.2S, Use clang | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | dewayne |
| Component: | Individual Port(s) | Assignee: | Eugene Grosbein <eugen> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | danfe, eugen, lantw44, mandree, rene, sax |
| Priority: | --- | Keywords: | needs-patch, needs-qa |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 236372 | ||
Can you provide a diff for version 1.4.5 ? The port expired today, but this PR could save it. (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> 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? 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 (?) (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. Any update on this? *** Bug 236372 has been marked as a duplicate of this bug. *** I've removed ther DEPRECATED tag and bumped EXPIRATION_DATE to 2019-08-31 to avoid fatalities when someone wields the scythe, or axe... (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 @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 (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. (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); :-) Hi, do you have any news on this? (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). (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). Expired port removed. 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 Reassigning to committer who actually solved the problem. Thanks for the heavy lifting on this, Eugene! |
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