[csw-maintainers] apr-util - searches for libiconv.la - how to use .so ?

rupert THURNER rupert at opencsw.org
Sat Jun 19 12:53:29 CEST 2010


On Sat, May 22, 2010 at 14:26, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from rupert THURNER's message of Sat May 22 07:41:14 -0400 2010:
>
> Hi Rupert,
>
>> how could one convince apr-util to not search for  libiconv.la, but
>> use what is existing and working?
>
> Have you turned on the 'STRIP_LIBTOOL = 1' option in your GAR recipe?
> If not, try that first.  If it still doesn't work nicely, you'll need
> a bigger hammer...I've got one recipe where the trick about didn't
> work and I had to correct it through other means.  See the Openjade
> build recipe here:
> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openjade/trunk/Makefile

ben, you meen this code?
echo 'ARGS=`echo "$$@" | gsed
"s#/opt/csw/lib/libosp.la#/opt/csw/lib/libosp.so#g"`' >> libtool;

i tried to grep for libiconv ... but is seems to be nowhere?
$ ggrep -r libiconv trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/
Binary file trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/xlate/.libs/xlate.o
matches
Binary file trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/xlate/xlate.o
matches
Binary file trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/.libs/libaprutil-1.so
matches
Binary file trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/.libs/libaprutil-1.a
matches
Binary file trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/.libs/libaprutil-1.so.0.3.9
matches
Binary file trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/.libs/libaprutil-1.so.0
matches
trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/CHANGES:
 as required by missing libiconv.  [William Rowe]
trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/config.log:libiconv_open
                      conftest.o
trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/config.log:libiconv
                           conftest.o


currently i only see two possibilities:

1. somebody with more knowledge and/or more time takes that up

2. we remove apr for the moment from unstable
    and the buildserver to not block the new apache
    build unecessarily.

rupert.


More information about the maintainers mailing list