Bug 248288 - www/squid3: Fails to build on 11.4-RELEASE (clang -werror)
Summary: www/squid3: Fails to build on 11.4-RELEASE (clang -werror)
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Kubilay Kocak
Keywords: needs-qa
Depends on:
Reported: 2020-07-27 04:55 UTC by Victor Sudakov
Modified: 2021-01-07 05:08 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (timp87)
koobs: merge-quarterly?

Poudriere log (250.40 KB, text/plain)
2020-07-27 04:55 UTC, Victor Sudakov
no flags Details
port patch (400 bytes, patch)
2020-07-30 08:29 UTC, timp87
timp87: maintainer-approval+
Details | Diff
Successful build on i386 (57.72 KB, application/octet-stream)
2020-07-31 03:55 UTC, Victor Sudakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Sudakov 2020-07-27 04:55:30 UTC
Created attachment 216791 [details]
Poudriere log

Would it be possible to revive the www/squid3 port? squid4 has some not-easily-reproduceable problems with Kerberos authentication, so squid3 is still used where Kerberos is needed.

The error is 

-Wno-dynamic-class-memaccess -I/usr/local/include -MT InnerNode.lo -MD -MP -MF .deps/InnerNode.Tpo -c InnerNode.cc  -fPIC -DPIC -o .libs/InnerNode.o
InnerNode.cc:24:52: error: 'mem_fun<void, ACL>' is deprecated [-Werror,-Wdeprecated-declarations]
    std::for_each(nodes.begin(), nodes.end(), std::mem_fun(&ACL::prepareForUse));
/usr/include/c++/v1/functional:1155:1: note: 'mem_fun<void, ACL>' has been explicitly marked deprecated here
/usr/include/c++/v1/__config:972:39: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX11'
/usr/include/c++/v1/__config:961:48: note: expanded from macro '_LIBCPP_DEPRECATED'
#    define _LIBCPP_DEPRECATED __attribute__ ((deprecated))
1 error generated.
*** Error code 1

make[4]: stopped in /wrkdirs/usr/ports/www/squid3/work/squid-3.5.28/src/acl
*** Error code 1

make[3]: stopped in /wrkdirs/usr/ports/www/squid3/work/squid-3.5.28/src
*** Error code 1

make[2]: stopped in /wrkdirs/usr/ports/www/squid3/work/squid-3.5.28/src
*** Error code 1

make[1]: stopped in /wrkdirs/usr/ports/www/squid3/work/squid-3.5.28
*** Error code 1

make: stopped in /usr/ports/www/squid3
=>> Cleaning up wrkdir
===>  Cleaning for squid3-3.5.28_4
build of www/squid3 | squid3-3.5.28_4 ended at Mon Jul 27 11:02:58 +07 2020
build time: 00:01:26
!!! build failure encountered !!!
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-27 08:30:21 UTC
Does the build pass bypassing -Werror with CFLAGS=-Wno-error or similar?

www/squid3 is currently marked BROKEN: Does not build on FreeBSD 12 with OpenSSL 1.1. You may add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf as a workaround

Fixing that need to be tested/verified as well

Note: -Werror removal (or overriding) is:

Approved by: portmgr (blanket, ports compliance)
Comment 2 Victor Sudakov 2020-07-27 09:54:12 UTC
(In reply to Kubilay Kocak from comment #1)
I wish I knew how to set those options for just 1 port in /usr/local/etc/poudriere.d/make.conf 

And besides, I don't have SSL_* options enabled in this build:

Comment 3 timp87 2020-07-27 10:07:15 UTC
Could you please provide FreeBSD version and squid port options set?
I'd try to reproduce it.
Comment 4 Victor Sudakov 2020-07-27 10:08:35 UTC
(In reply to timp87 from comment #3)
I've attached the poudriere build log, it's all there.
Comment 5 timp87 2020-07-30 08:29:53 UTC
Created attachment 216878 [details]
port patch

Well, as proposed by koobs@ add -Wno-error
I tested it only on amd64
Comment 6 Victor Sudakov 2020-07-31 03:54:31 UTC
(In reply to timp87 from comment #5)
"-Wno-error" fixed the problem for me on both amd54 and i386 too.
Comment 7 Victor Sudakov 2020-07-31 03:55:59 UTC
Created attachment 216899 [details]
Successful build on i386
Comment 8 Victor Sudakov 2020-07-31 03:56:44 UTC
(In reply to Victor Sudakov from comment #6)
> amd54
amd64 of course
Comment 9 timp87 2020-08-17 17:04:33 UTC
Any luck this to be committed?
Comment 10 timp87 2021-01-05 19:23:55 UTC
I think this one may be closed now
Comment 11 Victor Sudakov 2021-01-06 02:35:15 UTC
(In reply to timp87 from comment #10)
Will the patch not be integrated into the ports tree?
Comment 12 timp87 2021-01-06 05:27:34 UTC
(In reply to Victor Sudakov from comment #11)
Well, there were some other commits into ports tree and I can't reproduce this problem now.
Comment 13 timp87 2021-01-07 05:08:11 UTC
(In reply to Victor Sudakov from comment #11)
can you try to reproduce it now?