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
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.
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
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?
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.
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.