From owner-svn-ports-all@freebsd.org Mon Nov 2 15:07:41 2015 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E86D9A02F02; Mon, 2 Nov 2015 15:07:41 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0DE91E04; Mon, 2 Nov 2015 15:07:41 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.22] (210.Red-81-38-187.dynamicIP.rima-tde.net [81.38.187.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 0AA0943BA6; Mon, 2 Nov 2015 09:07:38 -0600 (CST) Subject: Re: svn commit: r400565 - head/security/pam_krb5 To: Cy Schubert References: <201511021501.tA2F1kAp070299@slippy.cwsent.com> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, hrs@freebsd.org Reply-To: marino@freebsd.org From: John Marino Message-ID: <56377C39.5000401@marino.st> Date: Mon, 2 Nov 2015 16:07:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <201511021501.tA2F1kAp070299@slippy.cwsent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 15:07:42 -0000 On 11/2/2015 4:01 PM, Cy Schubert wrote: > In message <5637766F.6000404@marino.st>, John Marino writes: >> On 11/2/2015 3:37 PM, Cy Schubert wrote: >>> >>> Looks like the tarball (port) never supported heimdal in ports in the first >> >>> place. From ./configure: >> >> Why did it build before then? >> >> >>> >>> ac_fn_c_check_member "$LINENO" "krb5_creds" "session" >>> "ac_cv_member_krb5_creds_s >>> ession" " >>> #if HAVE_KRB5_H >>> # include >>> #else >>> # include >>> #endif >>> >>> ./portable/krb5.h has the same code. >>> >>> Hiemdal in ports installs krb5.h ${LOCALBASE}/include/heimdal/krb5. I can >>> remove the option for now or (better) we can symlink >>> ${LOCALBASE}/include/heimdal to ${LOCALBASE}/include/krb5 in the heimdal >>> port. See attached patch. >> >> Heimdal ports is the only option that builds in dports, so removing it >> means removing it from dports. >> >> krb.h is there (poudriere testport -i) : >> >> # ls /usr/local/include/heimdal/krb5.h >> /usr/local/include/heimdal/krb5.h >> >> It should configure, right? > > Nope. ls /usr/local/include/krb5.h /usr/local/include/krb5/krb5.h It is *already* using /usr/local/include/heimdal as it should be. It's just not getting used in configure: libtool: compile: cc -DHAVE_CONFIG_H -I. -I/usr/local/include/heimdal -pipe -O2 -fno-strict-aliasing -MT portable/pam_vsyslog.lo -MD -MP -MF portable/.deps/pam_vsyslog.Tpo -c portable/pam_vsyslog.c -fPIC -DPIC -o portable/.libs/pam_vsyslog.o libtool: compile: cc -DHAVE_CONFIG_H -I. -I/usr/local/include/heimdal -pipe -O2 -fno-strict-aliasing -MT portable/reallocarray.lo -MD -MP -MF portable/.deps/reallocarray.Tpo -c portable/reallocarray.c -fPIC -DPIC -o portable/.libs/reallocarray.o libtool: compile: cc -DHAVE_CONFIG_H -I. -I/usr/local/include/heimdal -pipe -O2 -fno-strict-aliasing -MT portable/pam_syslog.lo -MD -MP -MF portable/.deps/pam_syslog.Tpo -c portable/pam_syslog.c -fPIC -DPIC -o portable/.libs/pam_syslog.o libtool: compile: cc -DHAVE_CONFIG_H -I. -I/usr/local/include/heimdal -pipe -O2 -fno-strict-aliasing -MT account.lo -MD -MP -MF .deps/account.Tpo -c account.c -fPIC -DPIC -o .libs/account.o In file included from account.c:21:0: ./portable/krb5.h:48:24: fatal error: krb5/krb5.h: No such file or directory compilation terminated. We don't have to settle for what it is. We can control the build flags. The bottom line is that a regression happened. If the current makefile can't be fixed to operate as it was before, the change should be reverted, right? John