Date: Thu, 28 Jan 2016 08:46:41 +0600 From: Victor Sudakov <vas@mpeks.tomsk.su> To: David Demelier <demelier.david@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Bug 205256 - Segmentation fault with mount_smbfs Message-ID: <20160128024641.GA64567@admin.sibptus.tomsk.ru> In-Reply-To: <56A79D47.4060703@gmail.com> References: <20160126055046.GA23116@admin.sibptus.tomsk.ru> <20160126123833.GA36004@admin.sibptus.tomsk.ru> <56A79D47.4060703@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Demelier wrote:
> > What I fail to understand is how converters/libiconv from the ports
> > collection should influence mount_smbfs from the base system. But it
> > does.
>
> It does because mount_smbfs dynamically load symbols by using
> dlopen("libiconv.so") which then search into several paths and that also
> includes /usr/local/lib/*
It does because mount_smbfs calls libkiconv.so.4, and libkiconv calls
dlopen("libiconv.so") in lib/libkiconv/xlat16_iconv.c (look in
my_iconv_init(void))
>
> I wonder what's wrong with libiconv-1.14_9 because it should be a minor
> update with no API breakage.
libkiconv calls dlsym(iconv_lib, "iconv_open"), but libiconv-1.14_9
does not contain "iconv_open" any more, it contains "libiconv_open"
only. Please compare:
$ pkg info -x libic
libiconv-1.14_9
$ objdump -x /usr/local/lib/libiconv.so | grep _open
000184d0 l F .text 00000780 .hidden iconv_open
000184d0 g F .text 00000780 libiconv_open
00017d70 g F .text 0000075d libiconv_open_into
$
$ pkg info -x libic
libiconv-1.14_8
$ objdump -x /usr/local/lib/libiconv.so | grep _open
00018560 g F .text 00000780 iconv_open
00018560 g F .text 00000780 libiconv_open
00017e00 g F .text 0000075d libiconv_open_into
$
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160128024641.GA64567>