Created attachment 155600 [details] options file for the squid
Created attachment 155601 [details] ldd output of the squid binary
Squid 3.5.3 on a stable/9 machine was configured with explicit request to not link against any gssapi libraries. Despite that, it was linked against base gssapi. See the attached options and ldd output. Since the machine has openssl installed from ports, and squid linked to openssl, the image now depends on both base and port openssl, which is broken.
At first glance it looks like it's rather a bug in squid itself, not in the port. Because everything needed to switch off the kerberos was passed to squid's configure script, i.e --without-heimdal-krb5 --without-mit-krb5 --without-gss and --enable-auth-negotiate=none. I'll create a PR in squid bugzilla and see what happens.
(In reply to timp87 from comment #3) http://bugs.squid-cache.org/show_bug.cgi?id=4228
Created attachment 155671 [details] patch The krb5-config is guilty. Just put that file to /usr/ports/www/squid/files and rebuild port.
Comment on attachment 155671 [details] patch Dang! It's wrong >:(
Note: This port has no maintainer, and submitter is committer.
Created attachment 155672 [details] patch Make it ~never use pkg-config or krb5-config for detecting krb5 since we handle all of the krb5 options properly and pass the right paths to them. Checked on 8, 9 and 10. All of them are amd64.
(In reply to timp87 from comment #8) I suppose this patch, even if works, cannot be upstreamed. The configure.ac should be fixed to do the right thing, and then configure regenerated. IMO such bug must be fixed in the upstream.
(In reply to Konstantin Belousov from comment #9) > I suppose this patch, even if works, cannot be upstreamed. Definitely yes. > The configure.ac should be fixed to do the right thing, and then configure regenerated. > > IMO such bug must be fixed in the upstream. I agree again. And I hope they will fix it, but it seems to me they won't change anything in krb5 detection stuff before the next major release.
(In reply to Konstantin Belousov from comment #9) I suggest to apply my ugly patch now and wait when upstream fix it. So, when they fix it we will remove ugly and apply their patch.
Any objection? I would apply this ugly piece in next minor update for this port. Im gonna make it in a few days.
(In reply to timp87 from comment #12) Are you asking me ? I have no opinion, and I am not a port committer. Ideally, some fix would come from upstream, but what is there now is probably fine for the temporal measure.
Hi! Squid-3.5.5 has just been committed with workaround for this problem. Try it, please.
(In reply to timp87 from comment #14) Freshly rebuilt squid 3.5.5. Output of ldd /usr/local/sbin/squid: /usr/local/sbin/squid: librt.so.1 => /usr/lib/librt.so.1 (0x800d33000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800f38000) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x801157000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013c9000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x8017fa000) libm.so.5 => /lib/libm.so.5 (0x801b01000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801d22000) libthr.so.3 => /lib/libthr.so.3 (0x801f30000) libc.so.7 => /lib/libc.so.7 (0x802153000) Seems it worked, thanks.