Bug 5532 - rsync / autoconf fails to detect libiconv on Solaris 10
Summary: rsync / autoconf fails to detect libiconv on Solaris 10
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.2
Hardware: Sparc Solaris
: P3 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-09 22:02 UTC by Greg Robinson
Modified: 2008-11-03 20:03 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Robinson 2008-06-09 22:02:14 UTC
Hi,

Solaris 10 Generic_127111-06 , gcc 3.4.3, built by sun in /usr/sfw/bin.

Problem:  autoconf fails to locate libiconv installed in /usr/local/lib, and thus rsync fails to link.

I'd like to request that a note be put in the INSTALL documentation that libiconv is a pre-requisite for rsync to build.  I couldn't find a mention of it anywhere.

I suspect that configure should also bomb out with a fatal error if libiconv is not detected.

Workaround:  setenv LDFLAGS -L/usr/local/lib  will detect and successfully build and link an rsync binary.

Without the env var, configure gueses incorrectly:

checking for library containing libiconv_open... no
checking for iconv declaration... 
         extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);

With it set, it guesses correctly:

checking for library containing libiconv_open... -liconv
checking for iconv declaration... 
         extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);

I compile with these (working) options:

tcsh# setenv CC /usr/sfw/bin/gcc
tcsh# setenv LDFLAGS -L/usr/local/lib
tcsh# ./configure --with-rsyncd-conf=/usr/local/etc/rsyncd.conf --datarootdir=/usr/local
Comment 1 Wayne Davison 2008-06-10 09:43:39 UTC
Rsync does not require iconv to build, so something has to be confusing configure.  The use of /usr/local/lib may indeed need to be manually specified if it is not in the default load path of the system, and that won't change (since it is not rsync's place to override the default load path for the system without being told to do so, and you can set your system's default load path to include /usr/local/lib if you so desire).

As for the build error, configure must have found iconv_open when doing an earlier check (one that doesn't look to see if it needs an extra library), as that is the only time that rsync tries to compile the iconv-using code.  If that is the case, HAVE_ICONV_OPEN will be defined in config.h, and no -liconv will be specified in the Makefile.  If you could figure out why the configure check manages to build its iconv_open test without a library, yet rsync fails to link, we could hopefully get HAVE_ICONV_OPEN to be disabled when the function is not really available.
Comment 2 podlipnik 2008-07-08 07:11:59 UTC
Starting with rsync version 3.0.0 through 3.0.2 I just
used default installing steps in tcsh: configure, make, make install
and my ksh scripts were working fine.
With rsync version 3.0.3 I have a problem when running rsync in ksh,
which wasn't a case before. 
My cron job produce this output:

ld.so.1: rsync: fatal:libiconv.so.2: open failed: No such file or directory

Workaround: I added next line to my ksh script:
LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH

To set environment variable LDFLAGS -L/usr/local/lib before running
configure didn't help.

Solaris 10 Generic_127112-11, gcc 3.4.6
Solaris 11 snv_70b
Comment 3 Greg Robinson 2008-07-08 19:59:59 UTC
Hi,

You are right.  Solaris 10 does not need iconv to build.  I built it on a system which doesn't have this /usr/local and it built fine.

I ran another test on this /usr/local and I think configure is checking /usr/local/lib by itself, and somehow passing the test, and then expecting libiconv to be there.

Checking config.log for all instances of iconv I find:

configure.sh:12409: checking for library containing libiconv_open
configure.sh:12450: /usr/sfw/bin/gcc -std=gnu99 -o conftest -g -O2 -DHAVE_CONFIG
_H -Wall -W   conftest.c -lsocket -lnsl  >&5
Undefined                       first referenced
 symbol                             in file
libiconv_open                       /var/tmp//ccsRkaQS.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure.sh:12456: $? = 1

And then the next occurance (roughly):

configure.sh:12450: /usr/sfw/bin/gcc -std=gnu99 -o conftest -g -O2 -DHAVE_CONFIG
_H -Wall -W   conftest.c -liconv  -lsocket -lnsl  >&5
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
configure.sh:12456: $? = 1

But, the next occurance (my iconv is 2 years old):

configure.sh:12493: checking for iconv declaration
configure.sh:12532: /usr/sfw/bin/gcc -std=gnu99 -c -g -O2 -DHAVE_CONFIG_H -Wall 
-W  conftest.c >&5
conftest.c:97: error: conflicting types for 'libiconv'
/usr/local/include/iconv.h:83: error: previous declaration of 'libiconv' was her
e
conftest.c:97: error: conflicting types for 'libiconv'
/usr/local/include/iconv.h:83: error: previous declaration of 'libiconv' was her
e
configure.sh:12538: $? = 1

Then:

configure.sh:14808: checking for iconv_open
configure.sh:14864: /usr/sfw/bin/gcc -std=gnu99 -o conftest -g -O2 -DHAVE_CONFIG
_H -Wall -W   conftest.c -lsec -lsocket -lnsl  >&5
configure.sh:14870: $? = 0
configure.sh:14888: result: yes

Which results in:
ac_cv_func_iconv_open=yes
ac_cv_header_iconv_h=yes
ac_cv_search_libiconv_open=no
am_cv_proto_iconv='extern size_t iconv (iconv_t cd, const char * *inbuf, size_t 
*inbytesleft, char * *outbuf, size_t *outbytesleft);'
am_cv_proto_iconv_arg1=const

and of course:

#define HAVE_ICONV_OPEN 1

As you can see, you are right in that iconv_open is being built successfully.  It appears that the libiconv_open test fails, and the iconv_open test succeeds.

I think I've reached the limits of my debugging efforts.  Any ideas?
Comment 4 Jörn Clausen 2008-11-03 04:54:29 UTC
I just stumbled over the same problem. I think this is what happens:

The code that uses iconv is enclosed in

#ifdef ICONV_CONST

So it is sufficient that the test for the iconv *type* succeeds, the usability of the library itself does not matter.

The test "checking for library containing libiconv_open" fails, as Solaris' libiconv is not suitable.

But the check "checking for iconv declaration" succeeds, if your compiler is a gcc. It just so manages to compile the test using Sun's libiconv. It fails, if you are using the Sun Studio compiler, which is much more picky and detects a different prototype for the tested function. So with gcc, ICONV_CONST is defined and the ifdef'ed code is used, with Sun's cc, ICONV_CONST is undefined and libiconv is never touched again.

I think the solution would be to use a macro in the code that tested for the usability of libiconv, not the type of the function iconv.
Comment 5 Wayne Davison 2008-11-03 20:03:22 UTC
See the code in rsync.h that enables or disables the ICONV_CONV define depending on certain criteria.  That code is just boiling down all the different checks to a single define that the rest of the code can use to test everything.