Re: [bug-gnu-libiconv] Compiling new libiconv version when an old version is installed

[Dagobert Michelsen]

Hello Bruno,

Am 11.04.2008 um 13:13 schrieb Bruno Haible:
> Dagobert Michelsen wrote:
> > I have a problem compiling a new version of libiconv (1.12) on
> > a system which already has an old version (1.9.2) installed.
> > Basically I do
> >    ./configure --prefix=/opt/csw
> >    gmake
> > to build the library and then make a DESTDIR-installation for
> > packaging with
> >    gmake DESTDIR=/tmp/pkgdir install
> > ...
> > Undefined                       first referenced
> >   symbol                             in file
> > iconv_canonicalize                  iconv.o
>
> This is a known problem with libtool and DESTDIR installations.
> On some systems you simply cannot create an executable that should
> link to /opt/csw/lib/libiconv.so if the library is not yet there.
> On the other systems, libtool could do a bit better when you ask
> to link with /tmp/pkgdir/opt/csw/lib/libiconv.la (it could use
> /tmp/pkgdir/opt/csw/lib/libiconv.so).

I tried this with

  --prefix=/tmp/pkgdir/
  --with-libintl-prefix=$(BOOTSTRAPINSTALLDIR) (where gettext is  
installed)
  --without-libiconv-prefix
  --enable-relocatable

but got the same error as in
  <http://lists.gnu.org/archive/html/bug-gnu-libiconv/2008-04/ 
msg00010.html>
on 'make install':

/opt/studio/SOS12/SUNWspro/bin/cc -I/tmp/pkgdir/include -I/root/ 
automatic-multiarch-compile/lib/libiconv/work/install-i386/tmp/pkgdir/ 
include -I/root/automatic-multiarch-compile/lib/libiconv/work/i386/ 
bootstrapinstall/include -xO3 -m32 -xarch=386 -I/root/automatic- 
multiarch-compile/lib/libiconv/work/i386/bootstrapinstall/include -I/ 
tmp/pkgdir/include -I/root/automatic-multiarch-compile/lib/libiconv/ 
work/install-i386/tmp/pkgdir/include -m32 -xarch=386 -L/root/ 
automatic-multiarch-compile/lib/libiconv/work/i386/bootstrapinstall/ 
lib -L/tmp/pkgdir/lib -L/root/automatic-multiarch-compile/lib/ 
libiconv/work/install-i386/tmp/pkgdir/lib -I../srclib -I../srclib - 
I.. -DHAVE_CONFIG_H -DIN_RELOCWRAPPER -DNO_XMALLOC -DINSTALLPREFIX="/ 
tmp/pkgdir/" -DINSTALLDIR="/root/automatic-multiarch-compile/lib/ 
libiconv/work/install-i386/tmp/pkgdir//bin" - 
DLIBPATHVAR="LD_LIBRARY_PATH" -DLIBDIRS="/tmp/pkgdir//lib", - 
DEXEEXT="" ../srclib/relocwrapper.c ../srclib/progname.c ../srclib/ 
progreloc.c ../srclib/xreadlink.c ../srclib/areadlink.c ../srclib/ 
readlink.c ../srclib/canonicalize-lgpl.c ../srclib/malloca.c ../ 
srclib/relocatable.c ../srclib/setenv.c ../srclib/strerror.c ../ 
srclib/c-ctype.c -o /root/automatic-multiarch-compile/lib/libiconv/ 
work/install-i386/tmp/pkgdir//bin/iconv.wrapper
../srclib/relocwrapper.c:
../srclib/progname.c:
../srclib/progreloc.c:
../srclib/xreadlink.c:
../srclib/areadlink.c:
../srclib/readlink.c:
../srclib/canonicalize-lgpl.c:
../srclib/malloca.c:
../srclib/relocatable.c:
../srclib/setenv.c:
../srclib/strerror.c:
../srclib/c-ctype.c:
Undefined                       first referenced
 symbol                             in file
xalloc_die                          xreadlink.o
ld: fatal: Symbol referencing errors. No output written to /root/ 
automatic-multiarch-compile/lib/libiconv/work/install-i386/tmp/ 
pkgdir//bin/iconv.wrapper
gmake[2]: *** [install] Error 1
gmake[2]: Leaving directory `/root/automatic-multiarch-compile/lib/ 
libiconv/work/i386/libiconv-1.12/src'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/root/automatic-multiarch-compile/lib/ 
libiconv/work/i386/libiconv-1.12'
gmake: *** [install-work/i386/libiconv-1.12/Makefile] Error 2

> So, in general, I recommend to do first the "make install" and then  
> only
> "make install DESTDIR=..."

Yes, that would work. Unfortunately I don't have root
access on the blastwave project build machines.

> > This fails with
> >            *) /bin/sh ../libtool --mode=link gcc  -g -O2 `if test -n
> > ''; then  /opt/csw/bin; fi` iconv.o ../srclib/libicrt.a /tmp/pkgdir/
> > opt/csw/lib/libiconv.la -L/opt/csw/lib -lintl -lsec -L/opt/csw/lib -
> > liconv -lc -R/opt/csw/lib  -o iconv;; \
>
> Where does the -lsec come from?

I do a bootstrap of gettext 0.17 first, and therefore added
this manually, as this library is needed on Solaris
or acl_trivial can not be found. See gettext bug #21604 for
details:
  http://savannah.gnu.org/bugs/?21604
The gettext flags are then pulled in automatically when
compiling libiconv.


Best regards

  -- Dago