Full_Name: Gordon Moore Version: 1.2.10 OS: UNIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.245.239.226) We have just installed the new version and are having some difficulty in getting the translation functions to work. We get errors like: unresolved: ldap_t61_to_8859 I know I have to compile the ldap and lber libraries with an extra switch but I cannot figure out where to insert it? Any guidance would be appreciated. Gord
moorego@em.agr.ca wrote: > unresolved: > ldap_t61_to_8859 > > I know I have to compile the ldap and lber libraries with an extra switch > but I cannot figure out where to insert it? > Any guidance would be appreciated. You have to define STR_TRANSLATION to anything and define LDAP_CHARSET_8859 to 88591 or something similar. Or define LDAP_DEFAULT_CHARSET (but I think is broken). However, you cannot do it from configure, your have to do it by hand. Read libraries/libldap/charset.c. Anyway, consider STR_TRANSLATION as a deprecated feature is is being removed from the next OpenLDAP version. The concept is broken, charset translation cannot be done at that level. Some attribute types contain blob values that must not be messed with. Using ldap_get_values_len to detect that is fragile (you can use that API function to get string values, IIRC some Perl modules use it always). Charset translation can only be done by looking at the schema and then doing translation for only those values where it makes sense. So either the library has schema knowledge or the application gets it, either wired in or found at runtime. The library does not have schema knowledge, so that leaves it to the application... Besides, STR_TRANSLATION assumes that you have your data in T.61 and makes them useable from the (UNIX) command line and simple clients. Most LDAP clients out there expect data to be in UTF-8. So you should be planning transitioning to UTF-8 instead. Netscape will be happy, Outlook will be happy, Java will be happy, you can more or less handle it from Perl, etc. That leaves your C/C++ programs. Since you are from Canada, I presume you are interested in ISO-8859-1. Translation from/to UTF-8 is trivial, you don't need tables. STR_TRANSLATION is a dead end. Plan to do without it. Julio
Please note that STR_TRANSLATION routines are experimental and will not be supported in future releases as proper translation such requires knowledge of schema which the BER library doesn't have. Kurt At 06:15 PM 6/20/00 GMT, j_sanchez@stl.es wrote: > > >moorego@em.agr.ca wrote: >> unresolved: >> ldap_t61_to_8859 >> >> I know I have to compile the ldap and lber libraries with an extra switch >> but I cannot figure out where to insert it? >> Any guidance would be appreciated. > >You have to define STR_TRANSLATION to anything and define LDAP_CHARSET_8859 >to 88591 or something similar. Or define LDAP_DEFAULT_CHARSET (but I think >is broken). > >However, you cannot do it from configure, your have to do it by hand. >Read libraries/libldap/charset.c. > >Anyway, consider STR_TRANSLATION as a deprecated feature is is being >removed from the next OpenLDAP version. > >The concept is broken, charset translation cannot be done at that level. >Some attribute types contain blob values that must not be messed with. >Using ldap_get_values_len to detect that is fragile (you can use that >API function to get string values, IIRC some Perl modules use it >always). > >Charset translation can only be done by looking at the schema and then >doing translation for only those values where it makes sense. So >either the library has schema knowledge or the application gets >it, either wired in or found at runtime. The library does not have >schema knowledge, so that leaves it to the application... > >Besides, STR_TRANSLATION assumes that you have your data in T.61 and >makes them useable from the (UNIX) command line and simple >clients. Most LDAP clients out there expect data to be in UTF-8. >So you should be planning transitioning to UTF-8 instead. Netscape >will be happy, Outlook will be happy, Java will be happy, you can >more or less handle it from Perl, etc. That leaves your C/C++ programs. >Since you are from Canada, I presume you are interested in ISO-8859-1. >Translation from/to UTF-8 is trivial, you don't need tables. > >STR_TRANSLATION is a dead end. Plan to do without it. > >Julio > >
changed state Open to Closed