| -----Ursprüngliche Nachricht-----
| Von: news [mailto:email@example.com] Im Auftrag von Gunter Ohrner
| Gesendet: Donnerstag, 5. Januar 2006 20:02
| An: firstname.lastname@example.org
| Betreff: RE: "Can't recode string" again...
| Yes and no, I'm using the stock Debian package for subversion 1.1.4 on the
| server and a rebuild Debian package for 1.2.3 containing the
| meta-data-branch-patch on the client.
I'm not familiar with Debian, but perhaps somebody else on this list is
and knows how to figure out how the package was built?
| > Can you check the output when running configure? -- I'm seeing:
| > checking iconv.h usability... yes
| It this the output of Subversion's configure, or of Apache's configure?
| I ran both configure of svn 1.2.3 and 1.1.4 and none of these shows any line
| containing the string "iconv", neither that it succeeded nor that it fails.
| Verifying this, grep doesn't find the string "iconv" in configure at all:
| $ grep -i iconv configure
It's in the output captured from Subversion's configure, but (taking a closer
look at the context :-) ) the iconv strings I mentioned appear during APRUTIL's
| Yes, but just as you did I expected the recoding to take place on the client
| side, where it can be controlled using the LC_* / LANG environment
| The server answering "Can't recode string" to the client's request looks
| suspicious to me, this shouldn't happen at all from how I understood svn's
| way to deal with strings...
I don't think this is "server" related the way you see it. I'd assume you'll get this
message when you run any of the svn* utilities server-side? You can check this
running svnlook on the repository. I'm sure it will complain on the first filename
with an umlaut it comes across...
Did you try running ldd on any one of the clients, or libraries, or svnserve itself?
In ldd's output, iconv should show up if it's part of their dependencies...
$ ldd /usr/local/bin/svnserve
-laprutil-0.9 => /usr/local/lib/libaprutil-0.so.9
-lpthread.20 => /usr/local/lib/libpthread.so.20
-ldb4-4.2.2 => /usr/local/lib/libdb4-4.2.so.2
-lexpat.1 => /usr/local/lib/libexpat.so.1
-liconv.4 => /usr/local/lib/libiconv.so.4
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
-lcrypt.0 => /usr/lib/libcrypt.so.0
-lresolv.1 => /usr/lib/libresolv.so.1
-lapr-0.9 => /usr/local/lib/libapr-0.so.9
-lintl.0 => /usr/lib/libintl.so.0
-lsvn_subr-1.0 => /usr/local/lib/libsvn_subr-1.so.0
-lsvn_delta-1.0 => /usr/local/lib/libsvn_delta-1.so.0
-lsvn_fs_fs-1.0 => /usr/local/lib/libsvn_fs_fs-1.so.0
-lsvn_fs_base-1.0 => /usr/local/lib/libsvn_fs_base-1.so.0
-lsvn_fs-1.0 => /usr/local/lib/libsvn_fs-1.so.0
-lsvn_repos-1.0 => /usr/local/lib/libsvn_repos-1.so.0
-lsvn_ra_svn-1.0 => /usr/local/lib/libsvn_ra_svn-1.so.0
-lc.12 => /usr/lib/libc.so.12
In fact, "-liconv.4 => /usr/local/lib/libiconv.so.4" will be listed by
ldd for every client (svn, svnlook, ...)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jan 6 09:46:33 2006