| -----Ursprüngliche Nachricht-----
| Von: news [mailto:news@sea.gmane.org] Im Auftrag von Gunter Ohrner
| Gesendet: Donnerstag, 5. Januar 2006 10:41
| An: users@subversion.tigris.org
| Betreff: RE: "Can't recode string" again...
|
| However I tried to find information on svn and libiconv and could not find
| very much... libiconv is not even listed in the requriements section of the
| INSTALL file and there exists no configure-switch to tell the build process
| to look for it. (I checked both svn 1.1.4 which I'm using on the server and
| svn 1.2.3 which I'm using on the client.)
That's correct. Configure should be able to figure that out automagically.
So unless your system lacks iconv or configure cannot find it in "standard places",
there'll simply be no iconv and hence no recoding.
Did you build your client/server yourself? Can you check the output when running
configure? -- I'm seeing:
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
setting LIBS to "-liconv"
adding "-liconv" to APRUTIL_LIBS
adding "-liconv" to APRUTIL_EXPORT_LIBS
nulling LIBS
checking for type of inbuf parameter to iconv... const char **
|
| [...]
| So, will I need to rebuild Apache2 / libapr? What did you change exactly to
| get working binaries / libraries?
That depends on the above... First check if configure can find the iconv
header files/libraries. If it can't find them, they're either not there or not
stored where configure's looking for them, so there are two possible
solutions:
(1) not installed: Install iconv and rebuild SVN (but check whether
configure found it).
(2) installed, but invisible to configure: Look where the header file
(iconv.h) and the library (libiconv.a) really are. Try telling configure about
that, e.g. by setting
export CPPFLAGS=-Iyour_path_to_iconv.h_here
export LDFLAGS=-Lyour_path_to_libiconv.a_here
before running configure.
|
| One thing I *still* do not understand is why the server tries to to any
| recodes at all, every doc I find just talks about the server working with
| UTF8 only, so why is there any need to recode between charsets on the
| server side?
Mmhhh... What exactly do you mean by "server" here? The way I understand
the mechanics is: The repository(!) stores strings (filenames in particular) in UTF-8.
But any client -- including the various svn* commands, but also e.g. TortoiseSVN on
Windoze -- will normally output things like filenames and/or log messages.
To be able to display these correctly, any client will have to convert from UTF-8
to the encoding employed by system the client runs on. Vice versa, when you add
new files with umlauts in their names to the repository for instance, that client-side encoding will have to be turned into UTF-8 again. So unless the client system
doesn't use pure ASCII (which your/our umlauts aren't) iconv will be required
to handle the recoding in either direction, and you'll be in trouble if you don't
have it. So it's not a matter who exactly does the recoding, but rather that
generally recoding has to take place for strings on their way into/from the repository.
Anybody please correct me if my explanation provides a false picture of things...
-Manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 5 14:34:34 2006