rsync - Jun 2008 - DO NOT REPLY [Bug 5532] New: rsync / autoconf fails to detect libiconv on Solaris 10

https://bugzilla.samba.org/show_bug.cgi?id=5532

           Summary: rsync / autoconf fails to detect libiconv on Solaris 10
           Product: rsync
           Version: 3.0.2
          Platform: Sparc
        OS/Version: Solaris
            Status: NEW
          Severity: minor
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: Greg.Robinson@dsto.defence.gov.au
         QAContact: rsync-qa@samba.org


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


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5532





------- Comment #1 from wayned@samba.org  2008-06-10 09:43 CST -------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5532





------- Comment #2 from podlipnik@mps.mpg.de  2008-07-08 07:11 CST -------
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


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5532





------- Comment #3 from Greg.Robinson@dsto.defence.gov.au  2008-07-08 19:59 CST
-------
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?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5532


joern.clausen@uni-bielefeld.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joern.clausen@uni-
                   |                            |bielefeld.de




------- Comment #4 from joern.clausen@uni-bielefeld.de  2008-11-03 04:54 CST
-------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=5532





------- Comment #5 from wayned@samba.org  2008-11-03 20:03 CST -------
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.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.