Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv

On 09/07/13 21:46, O. Hartmann wrote:
> On Sat, 07 Sep 2013 14:27:48 +0200
> Guido Falsi <madpilot_at_FreeBSD.org> wrote:
>
>> On 09/07/13 14:10, olli hauer wrote:
>>> There are 13 ports using --with-iconv=${LOCALBASE}
>>>    devel/apr1
>>>    devel/apr2
>>>    devel/git
>>>    irc/epic5
>>>    lang/gauche
>>>    net-mgmt/ettercap
>>>    net/ssltunnel-client
>>>    net/yaz
>>>    net/zebra-server
>>>    textproc/libxml2
>>>    textproc/py-libxml2
>>>    www/apache22
>>>    www/apache24
>>>
>>
>> Most of these do work anyway. I'm sure about various of these. I have
>> them working on my PCs. This does not mean they don't need to be
>> tweaked anyway, but they have lower priority.
>>
>> net-mgmt/ettercap is known broken and I have it in my pipe. I'm
>> giving this all the time I can, but I can''t spend too much time on
>> this right now. I'm going to check these and fix the broken ones asap.
>>
>>
>>>
>>> and devel/glib20, print/ghostscript8, print/ghostscript9 using
>>>    --with-libiconv=gnu
>>>    --with-libiconv=native
>>>    --with-libiconv=no
>>>    --with-libiconv=no
>>>
>>
>> glib20 I already fixed in the big commit. uses native or gnu where
>> appropriate. I'll also have a look at the ghostscript ports asap, but
>> at least ghostscript9 I have seen it working on my PCs.
>>
>>>
>>> Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
>>>
>>> If Uses/iconv.mk can be extended with something like ICON_PATH, then
>>> the 13 ports can be changed quickly to use the right iconv.
>>>
>>
>> Most of those will use the right iconv anyway if only one is found.
>> Extending iconv.mk should be discussed with portmgr, adding a
>> variable shouldn't be a problem though.
>>
>
>
> This happens in editors/abiword:
>
>
> libtool: link: ( cd ".libs" && rm -f "libimp.la" && ln -s
> "../libimp.la" "libimp.la" ) gmake[7]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
> gmake[6]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument/imp'
> gmake[6]: Entering directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument' ../../doltlibtool
> --tag=CXX   --mode=link c++  -O2 -pipe -O3 -march=native
> -fno-strict-aliasing -lgsf-1 -lgobject-2.0 -lglib-2.0 -lintl
> -L/usr/local/lib -lxml2   -lgthread-2.0 -pthread -lgobject-2.0
> -L/usr/local/lib -lglib-2.0 -lintl   -L../../src -labiword-2.8 -lz
> -avoid-version -module -no-undefined -L/usr/local/lib -o
> opendocument.la -rpath /usr/local/lib/abiword-2.8/plugins
> common/libcommon.la exp/libexp.la imp/libimp.la -ljpeg
> grep: /usr/local/lib/libiconv.la: No such file or directory
> sed: /usr/local/lib/libiconv.la: No such file or directory libtool:
> link: `/usr/local/lib/libiconv.la' is not a valid libtool archive
> gmake[6]: *** [opendocument.la] Error 1 gmake[6]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
> gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6/plugins/opendocument'
> gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6/plugins' gmake[3]: ***
> [all-recursive] Error 1 gmake[3]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6' gmake[2]: *** [all]
> Error 2 gmake[2]: Leaving directory
> `/usr/ports/editors/abiword/work/abiword-2.8.6' ===> Compilation failed
> unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before
> reporting the failure to the maintainer. *** Error code 1
>

This one looks like you still have some old libtoool archive which 
references libiconv laying around.

Can you try again this command line(I rewrite here for convenience):

find /usr/local/lib -name '*.la' -exec grep -qi iconv {} \; -print |
xargs -n 1 pkg which -oq | sort -u

and force rebuild of any port which still shows up?

If none shows up (which would be strange, but I can't exclude anything) 
Hope is not lost and there are still some things we can try.

-- 
Guido Falsi <madpilot_at_FreeBSD.org>