From owner-svn-src-head@FreeBSD.ORG Thu Sep 5 14:32:22 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E6D1DE24; Thu, 5 Sep 2013 14:32:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C9B92395; Thu, 5 Sep 2013 14:32:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB169B9AB; Thu, 5 Sep 2013 10:32:21 -0400 (EDT) From: John Baldwin To: Joel Dahl Subject: Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk Date: Thu, 5 Sep 2013 10:13:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308130715.r7D7F1nu076335@svn.freebsd.org> <20130822155835.GA52789@devbox.vnode.local> <20130903195241.GA93218@devbox.vnode.local> In-Reply-To: <20130903195241.GA93218@devbox.vnode.local> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309051013.35286.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Sep 2013 10:32:21 -0400 (EDT) Cc: src-committers@freebsd.org, Jilles Tjoelker , Peter Wemm , svn-src-all@freebsd.org, Dimitry Andric , gabor@freebsd.org, svn-src-head@freebsd.org, Peter Wemm X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:32:23 -0000 On Tuesday, September 03, 2013 3:52:41 pm Joel Dahl wrote: > On Thu, Aug 22, 2013 at 05:58:35PM +0200, Joel Dahl wrote: > > On Sun, Aug 18, 2013 at 03:51:25PM -0700, Peter Wemm wrote: > > > On 8/18/13 3:42 PM, Jilles Tjoelker wrote: > > > > On Sun, Aug 18, 2013 at 09:53:04PM +0200, Joel Dahl wrote: > > > >> On Sun, Aug 18, 2013 at 12:34:30AM +0200, Dimitry Andric wrote: > > > >>> On Aug 13, 2013, at 09:15, Peter Wemm wrote: > > > >>>> Author: peter > > > >>>> Date: Tue Aug 13 07:15:01 2013 > > > >>>> New Revision: 254273 > > > >>>> URL: http://svnweb.freebsd.org/changeset/base/254273 > > > > > > > >>>> Log: > > > >>>> The iconv in libc did two things - implement the standard APIs, the GNU > > > >>>> extensions and also tried to be link time compatible with ports libiconv. > > > >>>> This splits that functionality and enables the parts that shouldn't > > > >>>> interfere with the port by default. > > > > > > > >>>> WITH_ICONV (now on by default) - adds iconv.h, iconv_open(3) etc. > > > >>>> WITH_LIBICONV_COMPAT (off by default) adds the libiconv_open etc API, linker > > > >>>> symbols and even a stub libiconv.so.3 that are good enough to be able > > > >>>> to 'pkg delete -f libiconv' on a running system and reasonably expect it > > > >>>> to work. > > > > > > > >>>> I have tortured many machines over the last few days to try and reduce > > > >>>> the possibilities of foot-shooting as much as I can. I've successfully > > > >>>> recompiled to enable and disable the libiconv_compat modes, ports that use > > > >>>> libiconv alongside system iconv etc. If you don't enable the > > > >>>> WITH_LIBICONV_COMPAT switch, they don't share symbol space. > > > > > > > >>>> This is an extension of behavior on other system. iconv(3) is a standard > > > >>>> libc interface and libiconv port expects to be able to run alongside it on > > > >>>> systems that have it. > > > > > > > >>> Unfortunately I expect this will break many ports, when the libiconv > > > >>> port is installed. A simple example is the following: > > > >> > > > > > > > >> It also breaks installworld when /usr/src and /usr/obj are NFS exported > > > >> read-only. > > > > > > > > I think it has to do with share/i18n/csmapper and share/i18n/esdb using > > > > directories as make targets. This apparently causes these files to be > > > > rebuilt at 'make installworld' time, which is always bad but is only > > > > detected when /usr/obj is read-only. > > > > > > > > A hack that works is to enclose the four targets depending on ${SUBDIR} > > > > in .if !make(install) . > > > > > > > > Unfortunately, the Makefiles were written to depend on the directories > > > > as make targets fairly deeply, so a real fix is harder. > > > > > > I was looking at this yesterday, but was tied up with other things. I'll > > > take a look at it today after getting a few other things done. It should be > > > easy enough to replicate by changing /usr/obj to readonly on test systems. > > > > FWIW, this is still broken. > > Again, this is still broken. Yeah, my laptop failed to build cups (required by ghostscript which is required by emacs) because of this: ===> FreeBSD 10 autotools fix applied to /usr/ports/print/cups-image/work/cups-1.5.4/configure Configuring CUPS with options: ... configure: WARNING: unrecognized options: --disable-pdftops ... checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for library containing iconv_open... none required ... Linking texttops... cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib -Wl,-R/usr/local/lib -Wall -Wno- format-y2k -Wunused -fPIC -Os -g -fstack-protector -Wno-tautological-compare -o texttops texttops.o textcommon.o common.o -lcups -lssl -lcrypto -lz -pthread -lcrypt -lm -lssp_nonshared ../cups/libcups.so: undefined reference to `libiconv' ../cups/libcups.so: undefined reference to `libiconv_close' ../cups/libcups.so: undefined reference to `libiconv_open' cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[9]: *** [commandtops] Error 1 ... Having cups broken will probably break all of kde, etc. Are we seeing this in HEAD package builds yet? (Maybe the world we are using doesn't have this change yet?) Note that this is just a clean build of HEAD and a fresh build of ports from scratch. -- John Baldwin