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 <pe...@freebsd.org> 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: > > > >> <SNIP> > > > > > > > >> 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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"