Date: Sun, 18 Aug 2013 15:47:14 -0700 From: Peter Wemm <peter@wemm.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, FreeBSD Ports <freebsd-ports@freebsd.org>, Peter Wemm <peter@FreeBSD.org> Subject: Re: svn commit: r254273 - in head: . include lib lib/libc/iconv lib/libiconv_compat lib/libkiconv share/mk sys/sys tools/build/mk Message-ID: <52114EF2.6040901@wemm.org> In-Reply-To: <3887D7C7-D766-40DF-B154-D05768B86AA6@FreeBSD.org> References: <201308130715.r7D7F1nu076335@svn.freebsd.org> <3887D7C7-D766-40DF-B154-D05768B86AA6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1108D0dque474thv0WB72TSxd6TVLrlWF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 8/17/13 3:34 PM, Dimitry Andric wrote: > On Aug 13, 2013, at 09:15, Peter Wemm <peter@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 G= NU >> extensions and also tried to be link time compatible with ports libic= onv. >> 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 reduc= e >> the possibilities of foot-shooting as much as I can. I've successful= ly >> recompiled to enable and disable the libiconv_compat modes, ports tha= t 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 stan= dard >> libc interface and libiconv port expects to be able to run alongside = it on >> systems that have it. >=20 > Unfortunately I expect this will break many ports, when the libiconv > port is installed. A simple example is the following: >=20 > #include <iconv.h> >=20 > int main(void) > { > iconv_t ic =3D iconv_open("UTF-8", "ISO-8859-1"); > iconv_close(ic); > return 0; > } >=20 > If you compile this on a system after r254273 with -I/usr/local/include= , > and the libiconv port installed, it will result in: >=20 > $ 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 invo= cation) >=20 > This is because libiconv's iconv.h does: >=20 > #define iconv_open libiconv_open > ... > #define iconv_close libiconv_close >=20 > and so on for most of its functions. Yep, but since <iconv.h> is a standard include file, even on Linux system= s. Autoconf/libtool/etc know this, that's why it typically compiles and lin= ks 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: 00220c0 45 FUNC GLOBAL DEFAULT 12 iconv_close@@GLIBC_2.2.= 5 1745: 0021f10 418 FUNC GLOBAL DEFAULT 12 iconv@@GLIBC_2.2.5 1764: 0021d00 523 FUNC GLOBAL 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 wo= rking. I compile my personal systems like this: Index: Mk/Uses/iconv.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Mk/Uses/iconv.mk (revision 324679) +++ Mk/Uses/iconv.mk (working copy) @@ -16,6 +16,8 @@ IGNORE=3D USES=3Diconv does not require args .endif +.if !exists(/usr/include/iconv.h) LIB_DEPENDS+=3D libiconv.so.3:${PORTSDIR}/converters/libiconv +.endif .endif =2E. and keep libiconv completely off them. There's a couple of other po= rts with it hard coded in, but this covers most of them. eg: glib20, epic5, unzip, php-iconv. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV 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" --1108D0dque474thv0WB72TSxd6TVLrlWF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIRTvIACgkQFRKuUnJ3cX+A6wCbBf8CKXehHv+8PLCikmiZwDZT LUkAoJJ448BiqHMW5bxl3GINw3kE5ZZD =T+p9 -----END PGP SIGNATURE----- --1108D0dque474thv0WB72TSxd6TVLrlWF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52114EF2.6040901>