Bug 220355 - dns/knot2: Use GCC on i386, Remove BROKEN on i386
Summary: dns/knot2: Use GCC on i386, Remove BROKEN on i386
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Matthew Seaman
URL: https://lists.nic.cz/pipermail/knot-d...
Keywords: needs-qa
Depends on:
Blocks: 220419
  Show dependency treegraph
 
Reported: 2017-06-29 12:20 UTC by Leo Vandewoestijne
Modified: 2017-07-19 07:34 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback+


Attachments
unbroken i386 in dns/knot2 (1.32 KB, patch)
2017-06-29 12:20 UTC, Leo Vandewoestijne
freebsd: maintainer-approval+
Details | Diff
unbroken atomic issue i386 in dns/knot2 (919 bytes, patch)
2017-06-29 15:43 UTC, Leo Vandewoestijne
freebsd: maintainer-approval+
Details | Diff
unbroken atomic issue i386 in dns/knot2 - w/o compiler clause (943 bytes, patch)
2017-07-05 13:44 UTC, Leo Vandewoestijne
no flags Details | Diff
unbroken i386 in dns/knot2 - another attempt (944 bytes, patch)
2017-07-09 22:48 UTC, Leo Vandewoestijne
no flags Details | Diff
knot2 update (1.76 KB, patch)
2017-07-18 14:42 UTC, Leo Vandewoestijne
freebsd: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Leo Vandewoestijne 2017-06-29 12:20:09 UTC
Created attachment 183908 [details]
unbroken i386 in dns/knot2

Ondřej Surý of CZ.NIC found the cause why i386 had atomic issues, or better said; the solution.
https://lists.nic.cz/pipermail/knot-dns-users/2017-June/001156.html

I tested that in poudriere; it's OK for 110i386 (and 103amd64 & 110amd64).

I explicitly did not set PORTREVISION, to prevent users to "update" without a cause.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2017-06-29 12:34:44 UTC
Thank you Leo.

I don't believe it is accepted to use CC=clang (hardcoded, rather than framework mechanisms such as USES=compiler et al).
 
Additionally, why is HAS_CONFIGURE used in the !i386 case instead of GNU_CONFIGURE (in all cases)

Also, for this and future issues, please separate out logically distinct changes, in this case combining CONFLICTS->CONFLICTS_INSTALL with changes required to only fix BROKEN
Comment 2 Leo Vandewoestijne 2017-06-29 15:43:08 UTC
Created attachment 183915 [details]
unbroken atomic issue i386 in dns/knot2

Hello Kubilay Kocak,

> don't believe it is accepted to use CC=clang
>
Thinking of it, actually it isn't needed to define it for !i386.

> why is HAS_CONFIGURE used in the !i386 case instead of GNU_CONFIGURE (in all cases)
>
Ah, re-reading 6.5.3 of porters manual I'd discover I had a wrong understanding of the two.

> separate out logically distinct changes / combining CONFLICTS->CONFLICTS_INSTALL
>
True, that's indeed not related to the BROKEN issue.

Thanks for your pointers, I made the change even smaller.
Attached patch is tested in poudriere, on both 10.3 as 11.0 and both i386 as amd64.
Comment 3 Matthew Seaman freebsd_committer freebsd_triage 2017-07-02 23:00:07 UTC
I'm still getting compile failures on 11.0 i386:
```
libtool: link: cc -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -Wall -Werror=format-security -Werror=implicit -Wstrict-prototypes -fstack-protector -o .libs/keymgr utils/keymgr/keymgr-bind_privkey.o utils/keymgr/keymgr-functions.o utils/keymgr/keymgr-main.o  ./.libs/libknotd.a -L/usr/local/lib /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src/zscanner/.libs/libzscanner.so -lurcu ./.libs/libcontrib.a ./.libs/libknotus.a /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src/.libs/libknot.so /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src/dnssec/.libs/libdnssec.so -ledit -lncurses dnssec/.libs/libdnssec.so dnssec/.libs/libshared.a zscanner/.libs/libzscanner.so -llmdb -lgnutls -lnettle -lpthread -lm -Wl,-rpath -Wl,/usr/local/lib
./.libs/libknotd.a(libknotd_la-query_module.o): In function `knotd_mod_stats_incr':
knot/nameserver/query_module.c:(.text+0x9e0): undefined reference to `__atomic_fetch_add_8'
./.libs/libknotd.a(libknotd_la-query_module.o): In function `knotd_mod_stats_decr':
knot/nameserver/query_module.c:(.text+0xa80): undefined reference to `__atomic_fetch_sub_8'
./.libs/libknotd.a(libknotd_la-query_module.o): In function `knotd_mod_stats_store':
knot/nameserver/query_module.c:(.text+0xb20): undefined reference to `__atomic_store_8'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [keymgr] Error code 1

make[4]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
--- kjournalprint ---
libtool: link: cc -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -Wall -Werror=format-security -Werror=implicit -Wstrict-prototypes -fstack-protector -o .libs/kjournalprint utils/kjournalprint/kjournalprint-main.o  ./.libs/libknotd.a /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src/.libs/libknot.so -L/usr/local/lib /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src/dnssec/.libs/libdnssec.so /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src/zscanner/.libs/libzscanner.so -lurcu ./.libs/libcontrib.a -llmdb -lgnutls -lnettle -lpthread -lm -Wl,-rpath -Wl,/usr/local/lib
./.libs/libknotd.a(libknotd_la-query_module.o): In function `knotd_mod_stats_incr':
knot/nameserver/query_module.c:(.text+0x9e0): undefined reference to `__atomic_fetch_add_8'
./.libs/libknotd.a(libknotd_la-query_module.o): In function `knotd_mod_stats_decr':
knot/nameserver/query_module.c:(.text+0xa80): undefined reference to `__atomic_fetch_sub_8'
./.libs/libknotd.a(libknotd_la-query_module.o): In function `knotd_mod_stats_store':
knot/nameserver/query_module.c:(.text+0xb20): undefined reference to `__atomic_store_8'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [kjournalprint] Error code 1

make[4]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
2 errors

make[4]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
*** [all-recursive] Error code 1

make[3]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
1 error

make[3]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
*** [all] Error code 2

make[2]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
1 error

make[2]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2/src
*** [all-recursive] Error code 1

make[1]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2
1 error

make[1]: stopped in /wrkdirs/usr/ports/dns/knot2/work/knot-2.5.2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
```
Comment 4 Leo Vandewoestijne 2017-07-05 12:10:58 UTC
> I'm still getting compile failures on 11.0 i386:
>
That's disappointing.
So I assume your 'cc' is gcc (or is it clang)?
Comment 5 Matthew Seaman freebsd_committer freebsd_triage 2017-07-05 13:20:07 UTC
(In reply to Leo Vandewoestijne from comment #4)

It's the default c compiler on 11.0-RELEASE, which is:
```
% cc -v 
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
```

Well, ccache is involved, but that doesn't affect the outcome.
Comment 6 Leo Vandewoestijne 2017-07-05 13:44:39 UTC
Created attachment 184074 [details]
unbroken atomic issue i386 in dns/knot2 - w/o compiler clause

@Matthew:
In that case, could you please try this patch instead there?
It's the very same but without the compiler-type condition.
Comment 7 Matthew Seaman freebsd_committer freebsd_triage 2017-07-05 13:53:51 UTC
(In reply to Leo Vandewoestijne from comment #6)

Sure.  I'll try that this evening.
Comment 8 Matthew Seaman freebsd_committer freebsd_triage 2017-07-06 09:19:19 UTC
(In reply to Matthew Seaman from comment #7)

Unfortunately the updated patch made no difference
Comment 9 Leo Vandewoestijne 2017-07-09 22:48:26 UTC
Created attachment 184209 [details]
unbroken i386 in dns/knot2 - another attempt

@Matthew,
OK, since I can't replicate that error, and you can...
can you try and see if this patch then does solve it?

The only difference with the previous is adding CPUTYPE=i686 also, besides the already added CFLAGS.
Comment 10 Matthew Seaman freebsd_committer freebsd_triage 2017-07-10 07:57:59 UTC
(In reply to Leo Vandewoestijne from comment #9)

Still no joy I'm afraid.  You say this works for you? 

How exactly are you running your test compiles?  I'm testing with poudriere trying to run as close to a vanilla  environment as possible.
Comment 11 Leo Vandewoestijne 2017-07-18 14:42:12 UTC
Created attachment 184472 [details]
knot2 update

I used poudriere on an AMD64 ZFS instance on DigitalOcean, all fine.

Yesterday I did the same on an AMD64 ZFS EC2 instance, and 10.3/i386 was fine, but now 11.0/i386 failed with my suggested modifications.
(so there I get the same result as you).

Today I did more testing and found out the solution to the i386 problem on >= 11 is USE_GCC.

In the meanwhile 2.5.3 was released:
https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.5.3/NEWS

Attached patch was tested successfully on both i386 & amd64 on 10.3, 11.0 and 12.0.
Comment 12 Matthew Seaman freebsd_committer freebsd_triage 2017-07-19 07:34:01 UTC
Committed, thanks!
Comment 13 commit-hook freebsd_committer freebsd_triage 2017-07-19 07:34:40 UTC
A commit references this bug:

Author: matthew
Date: Wed Jul 19 07:33:35 UTC 2017
New revision: 446186
URL: https://svnweb.freebsd.org/changeset/ports/446186

Log:
  Update to 2.5.3

  Require gcc to allow compilation to succeed on FreeBSD 11+ i386

  ChangeLog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.5.3/NEWS

  PR:		220355
  Submitted by:	freebsd@dns-lab.com (maintainer)

Changes:
  head/dns/knot2/Makefile
  head/dns/knot2/distinfo