yes, the remote hostname shows up fine in the testfile when I perform
ssh -i /path/to/my/dsa-key remoteuser@remotehost hostname > test.dat

More info: I reversed the client and the server for just an extra test:
I login to the remote machine using ssh, and I issue an actual rsync command from that remote machine to my local solaris10 machine. This works fine!
The remote rsync info: /usr/local/bin/rsync is 679279 bytes, it runs on solaris 5.8, UltraSparc-IIi-engine, it's ELF-32 bit MSB executable, sparc version 1, dynamically linked, not stripped.
I don't know how it was installed, but it is version 3.0.6 which was recently installed on my request.
It has other ldd info of course:
libsec.so.1 => /usr/lib/libsec.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,UltraSPARC-IIi-Engine/lib/libc_psr.so.1
The remote machine has a tiny LD_LIBRARY_PATH (when I login as the same user who can execute rsync successfully):
/usr/openwin/lib:/usr/local/lib
There is only an ld.config.old in the remote /var/ld directory, nothing else!
Thus it looks like crle or LD_LIBRARY_PATH is not the culprit!?

On my local solaris10 machine, the file is 425496 bytes, the ldd info is
libpopt.so.0 => /usr/lib/libpopt.so.0
libsec.so.1 => /usr/lib/libsec.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libavl.so.1 => /usr/lib/libavl.so.1
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libm.so.2 => /usr/lib/libm.so.2
/platform/sun4u/lib/libc_psr.so.1
/platform/sun4u/lib/libmd_psr.so.1
All of those libraries are present.

Is it a problem if locally rsync runs on solaris10 and remotely it runs on solaris8?

Of course rsync should work regardless of the OS releases.
You might want to install and use the rsync binaries available in the Software Companion CD instead of these problematic ones.

I removed the 3.0.6 package, and then my path happened to point to a 3.0.0 version installed somewhere on our network.
It has the same problem!
Unfortunately the package on the companion disk is too old (2.6.3.1) for the project requirements, but anyway I start to believe the error is outside of rsync?
Can I post the output of ./configure and 'make' here?

If the problem is on the remote rsync as I guess, there is no much point expecting another local version to fix it.

If you plan to recompile rsync, you might try to use the "--disable-iconv" configure option.

no, I did not mean that remote rsync has a problem (on the contrary, from remote side it works)
but something on the local system in other settings, e.g. ssh, or some path setting or conflict or...
I will re-try disable-iconv once more ...

Rsync isn't a standalone program but it needs to be running on both sides of the network link.

According to your description, it cannot be asserted the local rsync is the one having issues.
I'm suspecting the "ld.so.1: rsync: fatal: libiconv.so.2: open failed: No such file or directory" message is coming from the other host.

The fact it runs properly when launched there from the shell doesn't means there is no problem when launching it through rsync/ssh.

I use this simple work around on a SunOS 5 machine:

.bashrc
$HOME/bin/rsync-3.0.7/ <- This folder contain rsync binary

$HOME/bin/rsync
NOTE:
* I know! This is a very dirty work-around... but it works launching it through rsync/ssh!
* My login shell is bash

thanks, I will try this asap!

if you can find the library file "ld.so.1" under /lib folder, then do the following:

cd /lib
ln -sf ld.so.1 libiconv.so.2

This thread is like 4 years old.

no, TroN, more like 2 and a half years actually ;-).
Thanks for the tip, ashrafkhalid !