26 Jan 16 17:59, you wrote to me: VS>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205256 VS>>>> Hаступил на грабли в полный рост, когда после очередного "pkg VS>>>> upgrade" виндовая шара не смонтировалась из fstab. Откат до VS>>>> libiconv-1.14_8.txz (вытащил из дампа) помог. JI>>> Аналогичную проблему с mount_msdosfs порешал таким quick&dirty JI>>> hack: $ cat iconvcompat.c VS>> Для меня в этой истории самое непонятное то, как libiconv из VS>> *портов* может влиять на mount_smbfs из *базовой системы*? $ ldd VS>> `which mount_smbfs ` /usr/sbin/mount_smbfs: VS>> libsmb.so.4 => /usr/lib/libsmb.so.4 (0x28076000) VS>> libkiconv.so.4 => /lib/libkiconv.so.4 (0x28082000) VS>> libc.so.7 => /lib/libc.so.7 (0x28086000) JI> Посредством libkiconv.so.4 вестимо. Оно libiconv.so dlopen(3) JI> и пытается из него dlsym(3) iconv_open. А начиная с libiconv-1.14_9 JI> iconv_open там больше нет. Вместо него теперь libiconv_open. JI> Hу а libkiconv.so.4 на такую засаду никак не рассчитывает...
Зачем оно вообще рассчитывает на наличие libiconv? А если бы converters/libiconv вообще не был установлен (это же порт), оно бы что делало?
JI> Так что пока в libkiconv.so.4 порядок не наведут либо оставаться JI> на libiconv-1.14_8, либо как у меня.
Не желаешь добавиться в CC List к багу 205256? Или знаешь более релевантный баг на обсуждаемую тему?
