Subject: iconv / LDFLAGS question (opensolaris)
To: None <pkgsrc-users@netbsd.org>
From: Mark Mayo <mark@vmunix.com>
List: pkgsrc-users
Date: 04/10/2007 19:09:14
Hi there, I'm using pkgsrc on OpenSolaris (b56) and have run into
various problems where configure scripts are picking up the GNU libiconv
in /usr/local (my LOCALBASE) that got pulled in as a dependency but
then are not linking properly. Using shells/zsh-current as an example
(I've also encountered this with graphics/gd and print/teTex3-bin so
far) I can see:

the gnu libiconv header get picked up:

	checking iconv.h usability... yes
	checking iconv.h presence... yes
	checking for iconv.h... yes

and later:

	checking for iconv... yes
	checking whether _libiconv_version is declared... yes
	checking for libiconv in -liconv... no
	checking for iconv declaration... const

and I end up with this as it's compiling:

gcc -Wl,-R/usr/local/lib   -o zsh main.o  `cat stamp-modobjs`   -lsocket
-ldl -lnsl -lcurses -lm  -lc
Undefined                       first referenced
symbol                             in file
libiconv_close                      utils.o
libiconv_open                       utils.o
libiconv                            utils.o
ld: fatal: Symbol referencing errors. No output written to zsh
collect2: ld returned 1 exit status

[wrapper.sh] note: The real command line, after the pkgsrc wrapper, was:
/export/pkgsrc/shells/zsh-current/work/.gcc/bin/gcc -Wl,-R/usr/local/lib
-o zsh main.o builtin.o compat.o cond.o exec.o glob.o hashtable.o hist.o
init.o input.o jobs.o lex.o linklist.o loop.o math.o mem.o module.o
options.o params.o parse.o pattern.o prompt.o signals.o signames.o
string.o subst.o text.o utils.o watch.o
-I/export/pkgsrc/shells/zsh-current/work/.buildlink/include
-L/export/pkgsrc/shells/zsh-current/work/.buildlink/lib  -lsocket -ldl
-lnsl -lcurses -lm -lc


So I think I know what it's doing, and if I build zsh manually from the
tarball I can simply "force" the linker's hand by setting some
LDFLAGS. I tried this via export and via the port's Makefile:

LDFLAGS+=       /usr/local/lib/libiconv.so -R/usr/local/lib

But I get:

===> Configuring for zsh-4.3.2nb1
=> Modifying GNU configure scripts to avoid --recheck
=> Replacing config-guess with pkgsrc versions
=> Replacing config-sub with pkgsrc versions
configure: WARNING: If you wanted to set the --build type, don't use
--host.
If a cross compiler is detected then cross compile mode will be
used.
configuring for zsh 4.3.2
checking build system type... i386-pc-solaris2.11
checking host system type... i386-sun-solaris2
checking for i386-sun-solaris2-gcc... gcc
checking for C compiler default output file name... configure:
error: C compiler cannot create executables
See `config.log' for more details.
*** Error code 77

Stop.
bmake: stopped in /export/pkgsrc/shells/zsh-current
*** Error code 1

config.log:

configure:2231: checking for C compiler default output file name
configure:2234: gcc -O  /usr/local/lib/libiconv.so -R/usr/local/lib
-Wl,-R/usr/local/lib conftest.c  >&5
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to a.out
collect2: ld returned 1 exit status

[wrapper.sh] note: The real command line, after the pkgsrc wrapper,
was:
/export/pkgsrc/shells/zsh-current/work/.gcc/bin/gcc -O
-L/export/pkgsrc/shells/zsh-current/work/.buildlink/lib
-R/usr/local/lib -Wl,-R/usr/local/
lib conftest.c
-I/export/pkgsrc/shells/zsh-current/work/.buildlink/include  -liconv



I'm guessing the -liconv was the first "linker test" looking for
-liconv.

Any suggestions on how to properly deal with this? I'm sorry but I'm
completely new to pkgsrc and my Makefile skills are very rusty,
otherwise I'd have made more progress with understanding how things
come together.. Except for the libiconv problem, I've built about 100
ports now with the stock gcc compiler in /usr/sfw/bin and things have
been working well.

Thx,
-Mark

--
Mark Mayo <mark@vmunix.com>