Max Bowsher wrote:
> Cory Omand wrote:
>> The problem is really with apr-util. Solaris has iconv_open in libc, so
>> even when you specify --with-iconv=/somewhere/else, libc satisfies the
>> linking requirements for iconv, and GNU iconv is removed. This causes
>> APR_LOCALE_CHARSET to not function as advertised when called in
>> libsvn_subr/utf.c. I don't yet know (a) how to get Solaris iconv to
>> function properly here, or (b) how to force apr-util to use GNU iconv
>> when libc contains similarly named iconv functions.
>
> I guess something is going wrong with the build, possibly with
> ordering of #includes?
> When built as a standalone library (non-libc), GNU libiconv exports
> 'libiconv_open', etc., and not 'iconv_open', and #defines the iconv
> names.
That's what I suspect as well, but I don't know how to fix it just yet.
What appears to happen is this: I set a -L and -R path to the location
of GNU iconv in LDFLAGS, and -I in CFLAGS, but then libtool in it's
infinite wisdom decides that the autoconf test for iconv (which uses
iconv_open) does not require -liconv to link, so it removes the -L, -R,
and -I flags I set. This happens as part of the m4 build macros for
apr-util, namely the APR_REMOVEFROM macro.
For kicks, I defeated autoconf by removing these sections from
apu-iconf.m4. The problem still appears to be that apr-util's xlate.c
uses 'iconv_open', not libiconv_open. My last round of hacking did not
turn up any viable solution, and then other concerns (aka paid work)
caused me to put looking for a fix on hold. I have access to lots of
Solaris boxes with SunONE compiler suite installed, so if anyone has
suggestions on how to fix this, let me know and I'll give it a shot!
Regards,
Cory.
--
Cory Omand <comand@blastwave.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 13 03:41:05 2005