Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On Fri, Sep 13, 2013 at 12:19:27AM +0200, Jilles Tjoelker wrote:
On Thu, Sep 05, 2013 at 10:15:40PM +0200, Joel Dahl wrote:
Installworld is still broken on systems with readonly /usr/obj.
I use this. It makes the mapper.dir and similar files depend on their
actual sources instead of phony targets, and therefore only rebuilt when
needed.
The previous patch had some problems (two makes in parallel in the same
directory, no rebuild when the sources of the $i/foo.$i files changed in
-DNOCLEAN mode). This patch should work better. It avoids changing the
targets and instead leaves the destination file untouched if the content
remains the same.
Index: share/i18n/csmapper/Makefile
===
--- share/i18n/csmapper/Makefile(revision 255570)
+++ share/i18n/csmapper/Makefile(working copy)
@@ -7,10 +7,11 @@
KAZAKH KOI KS MISC TCVN
mapper.dir: ${SUBDIR}
-${.TARGET}
-.for i in ${SUBDIR}
- cat ${i}/mapper.dir.${i} ${.TARGET}
-.endfor
+ newfile=$$(for i in ${SUBDIR}; do \
+ cat $$i/mapper.dir.$$i; \
+ done); \
+ [ $$newfile = $$(cat ${.TARGET} 2/dev/null) ] || \
+ printf '%s\n' $$newfile ${.TARGET}
mapper.dir.db: mapper.dir
${MKCSMAPPER} -m -o ${.TARGET} ${.ALLSRC}
@@ -18,10 +19,11 @@
CLEANFILES+= mapper.dir mapper.dir.db
charset.pivot: ${SUBDIR}
-${.TARGET}
-.for i in ${SUBDIR}
- cat ${i}/charset.pivot.${i} ${.TARGET}
-.endfor
+ newfile=$$(for i in ${SUBDIR}; do \
+ cat $$i/charset.pivot.$$i; \
+ done); \
+ [ $$newfile = $$(cat ${.TARGET} 2/dev/null) ] || \
+ printf '%s\n' $$newfile ${.TARGET}
charset.pivot.pvdb: charset.pivot
${MKCSMAPPER} -p -o ${.TARGET} ${.ALLSRC}
Index: share/i18n/esdb/Makefile
===
--- share/i18n/esdb/Makefile(revision 255570)
+++ share/i18n/esdb/Makefile(working copy)
@@ -10,18 +10,20 @@
CLEANFILES= ${FILES}
esdb.dir: ${SUBDIR}
-$@
-.for i in ${SUBDIR}
- cat ${i}/esdb.dir.${i} ${.TARGET}
-.endfor
+ newfile=$$(for i in ${SUBDIR}; do \
+ cat $$i/esdb.dir.$$i; \
+ done); \
+ [ $$newfile = $$(cat ${.TARGET} 2/dev/null) ] || \
+ printf '%s\n' $$newfile ${.TARGET}
esdb.dir.db: esdb.dir
${MKESDB} -m -o ${.TARGET} ${.ALLSRC}
esdb.alias: ${SUBDIR}
-$@
-.for i in ${SUBDIR}
- cat ${i}/esdb.alias.${i} ${.TARGET}
-.endfor
+ newfile=$$(for i in ${SUBDIR}; do \
+ cat $$i/esdb.alias.$$i; \
+ done); \
+ [ $$newfile = $$(cat ${.TARGET} 2/dev/null) ] || \
+ printf '%s\n' $$newfile ${.TARGET}
esdb.alias.db: esdb.alias
${MKESDB} -m -o ${.TARGET} ${.ALLSRC}
--
Jilles Tjoelker
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On Thu, Sep 05, 2013 at 10:15:40PM +0200, Joel Dahl wrote:
Installworld is still broken on systems with readonly /usr/obj.
I use this. It makes the mapper.dir and similar files depend on their
actual sources instead of phony targets, and therefore only rebuilt when
needed.
Index: share/i18n/csmapper/Makefile
===
--- share/i18n/csmapper/Makefile(revision 255496)
+++ share/i18n/csmapper/Makefile(working copy)
@@ -6,7 +6,16 @@
SUBDIR=APPLE AST BIG5 CNS CP EBCDIC GB GEORGIAN ISO646 ISO-8859 JIS \
KAZAKH KOI KS MISC TCVN
-mapper.dir: ${SUBDIR}
+.for i in ${SUBDIR}
+${i}/mapper.dir.${i}:
+ ${MAKE} -C ${.CURDIR}/${i} all
+mapper.dir: ${i}/mapper.dir.${i}
+${i}/charset.pivot.${i}:
+ ${MAKE} -C ${.CURDIR}/${i} all
+charset.pivot: ${i}/charset.pivot.${i}
+.endfor
+
+mapper.dir:
${.TARGET}
.for i in ${SUBDIR}
cat ${i}/mapper.dir.${i} ${.TARGET}
@@ -17,7 +26,7 @@
FILES+=mapper.dir mapper.dir.db
CLEANFILES+= mapper.dir mapper.dir.db
-charset.pivot: ${SUBDIR}
+charset.pivot:
${.TARGET}
.for i in ${SUBDIR}
cat ${i}/charset.pivot.${i} ${.TARGET}
Index: share/i18n/esdb/Makefile
===
--- share/i18n/esdb/Makefile(revision 255496)
+++ share/i18n/esdb/Makefile(working copy)
@@ -9,7 +9,16 @@
FILES+=esdb.dir esdb.dir.db esdb.alias esdb.alias.db
CLEANFILES= ${FILES}
-esdb.dir: ${SUBDIR}
+.for i in ${SUBDIR}
+${i}/esdb.dir.${i}:
+ ${MAKE} -C ${.CURDIR}/${i} all
+esdb.dir: ${i}/esdb.dir.${i}
+${i}/esdb.alias.${i}:
+ ${MAKE} -C ${.CURDIR}/${i} all
+esdb.alias: ${i}/esdb.alias.${i}
+.endfor
+
+esdb.dir:
$@
.for i in ${SUBDIR}
cat ${i}/esdb.dir.${i} ${.TARGET}
@@ -17,7 +26,7 @@
esdb.dir.db: esdb.dir
${MKESDB} -m -o ${.TARGET} ${.ALLSRC}
-esdb.alias: ${SUBDIR}
+esdb.alias:
$@
.for i in ${SUBDIR}
cat ${i}/esdb.alias.${i} ${.TARGET}
--
Jilles Tjoelker
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On Thu, Sep 05, 2013 at 10:13:34AM -0400, John Baldwin wrote:
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:
Well, that's a different problem. Installworld is still broken on systems with
readonly /usr/obj.
--
Joel
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On Thursday, September 05, 2013 10:46:48 am Baptiste Daroussin wrote:
On Thu, Sep 05, 2013 at 10:13:34AM -0400, John Baldwin wrote:
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.
This should work properly now, the ports tree received motification yesterday
and converters/libiconv is not installed anymore now.
Good grief, I just svn up'd my ports yesterday morning. :) I'll update again,
thanks!
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On Thursday, September 05, 2013 4:15:40 pm Joel Dahl wrote:
On Thu, Sep 05, 2013 at 10:13:34AM -0400, John Baldwin wrote:
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:
Well, that's a different problem. Installworld is still broken on systems with
readonly /usr/obj.
It is the problem originally reported by dim@ at the start of this thread. :)
My ports tree from today does build cups fine FWIW, but it seems there is still
a lot of fallout from this change. :(
--
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On 05.09.13 22:54, John Baldwin wrote:
On Thursday, September 05, 2013 4:15:40 pm Joel Dahl wrote:
On Thu, Sep 05, 2013 at 10:13:34AM -0400, John Baldwin wrote:
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:
Well, that's a different problem. Installworld is still broken on systems
with
readonly /usr/obj.
It is the problem originally reported by dim@ at the start of this thread. :)
My ports tree from today does build cups fine FWIW, but it seems there is
still
a lot of fallout from this change. :(
Jumping in an give my comment.
This has been fixed in the past few days. A lot of has been done and I
was also able to build my 600 pkg set w/o any iconv hickup.
A week ago I had to change the mobo of my workstation and I thought this
would be a good idea to rebuild every port I have installed. Bad idea,
every iconv related one failed. Yesterday I retried.
I had only one issue when building qcad which relies on openNURBS. And
the latter has to be compiled with -fPIC. But this is not related to the
topic.
So a big thanks to the ports people!
Andreas
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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.
--
Joel
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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.
--
Joel
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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. -- Joel ___ 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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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.
--
Jilles Tjoelker
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
On 8/17/13 3:34 PM, 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:
#include iconv.h
int main(void)
{
iconv_t ic = iconv_open(UTF-8, ISO-8859-1);
iconv_close(ic);
return 0;
}
If you compile this on a system after r254273 with -I/usr/local/include,
and the libiconv port installed, it will result in:
$ cc -I/usr/local/include iconv-test.c -o iconv-test
/tmp/iconv-test-I1ltw1.o: In function `main':
iconv-test.c:(.text+0x21): undefined reference to `libiconv_open'
iconv-test.c:(.text+0x2f): undefined reference to `libiconv_close'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
This is because libiconv's iconv.h does:
#define iconv_open libiconv_open
...
#define iconv_close libiconv_close
and so on for most of its functions.
Yep, but since iconv.h is a standard include file, even on Linux systems.
Autoconf/libtool/etc know this, that's why it typically compiles and links
like this:
cc -I/usr/local/include -L/usr/local/lib iconv-test.c -liconv
I'm sure there are exceptions though.
Random linux box (ubuntu fwiw):
peter@bit1:~$ readelf -a /lib/x86_64-linux-gnu/libc-2.15.so |grep iconv
1554: 00220c045 FUNCGLOBAL DEFAULT 12 iconv_close@@GLIBC_2.2.5
1745: 0021f10 418 FUNCGLOBAL DEFAULT 12 iconv@@GLIBC_2.2.5
1764: 0021d00 523 FUNCGLOBAL DEFAULT 12 iconv_open@@GLIBC_2.2.5
peter@bit1:~$ grep '^extern' /usr/include/iconv.h
extern iconv_t iconv_open (__const char *, __const char *);
extern size_t iconv (iconv_t, char **__restrict,
extern int iconv_close (iconv_t);
If you mix includes and libraries like in your example, it would fail on
linux too. However, linux tends to not add libiconv to the mix.
peter@bit1:~$ find / -mount -name 'libiconv*'
peter@bit1:~$ uname -a
Linux bit1 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
The WITH_LIBICONV_COMPAT switch can be turned on - that adds the
libiconv_open etc aliases. It was intended as a transition aid though - it
was intended to make 'pkg delete -f libiconv' on a running system keep working.
I compile my personal systems like this:
Index: Mk/Uses/iconv.mk
===
--- Mk/Uses/iconv.mk(revision 324679)
+++ Mk/Uses/iconv.mk(working copy)
@@ -16,6 +16,8 @@
IGNORE=USES=iconv does not require args
.endif
+.if !exists(/usr/include/iconv.h)
LIB_DEPENDS+= libiconv.so.3:${PORTSDIR}/converters/libiconv
+.endif
.endif
.. and keep libiconv completely off them. There's a couple of other ports
with it hard coded in, but this covers most of them. eg: glib20, epic5,
unzip, php-iconv.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
brueffer ZFS must be the bacon of file systems.
brueffer everything's better with ZFS
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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.
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
brueffer ZFS must be the bacon of file systems.
brueffer everything's better with ZFS
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
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:
#include iconv.h
int main(void)
{
iconv_t ic = iconv_open(UTF-8, ISO-8859-1);
iconv_close(ic);
return 0;
}
If you compile this on a system after r254273 with -I/usr/local/include,
and the libiconv port installed, it will result in:
$ cc -I/usr/local/include iconv-test.c -o iconv-test
/tmp/iconv-test-I1ltw1.o: In function `main':
iconv-test.c:(.text+0x21): undefined reference to `libiconv_open'
iconv-test.c:(.text+0x2f): undefined reference to `libiconv_close'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
This is because libiconv's iconv.h does:
#define iconv_open libiconv_open
...
#define iconv_close libiconv_close
and so on for most of its functions.
-Dimitry
___
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
Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk
Em 13-08-2013 09:15, Peter Wemm escreveu: 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. Thank you! Gabor ___ 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
