Re: [PATCH] configure.ac: link with -liconv for locale_charset()
Hello,
this changes effectively the meaning of CHARSET_LIB to always/unconditionally contain the library with the charset_locale () function. The snippet at the end of the email updates the description in /Makefile .
However, I checked now how gnulib deals with locale_charset (). Contary to my expectation, where gnulib builds only functions if they are not found in libraries on the target system, gnulib module localcharset builds unconditionally from source the function locale_charset (). I guess they do this in a portable way, but still.
My preference is to agree on universal approach for finding this
function, something like:
OK, if found in libiconv, else
OK, if found in libcharset, else
OK, here are the sources, build the function from them, and don't
look for it in (shared) libaries
I asked at bug-gnulib@ why they build locale_charset() before checking for it in libiconv / libcharset. My posting shall appear at http://lists.gnu.org/archive/html/bug-gnulib/2014-03/index.html . Let's see what the answer will be.
I don't know if in the git codebase generally is refused to use gnulib code, but if you agree on the above procedure with 3xOK, then locale_charset() will be available even on systems, that don't have this function in libcharset or libiconv.... Maybe /compat/poll/poll.[ch] in git-core from gnulib had similar history.
Kind regards
Дилян
On 11.03.2014 21:35, Junio C Hamano wrote:
Show 38 quoted lines
> Dmitry Marakasov <amdmi3@amdmi3.ru> writes:
>
>> On e.g. FreeBSD 10.x, the following situation is common:
>> - there's iconv implementation in libc, which has no locale_charset()
>> function
>> - there's GNU libiconv installed from Ports Collection
>>
>> Git build process
>> - detects that iconv is in libc and thus -liconv is not needed for it
>> - detects locale_charset in -liconv, but for some reason doesn't add it
>> to CHARSET_LIB (as it would do with -lcharset if locale_charset() was
>> found there instead of -liconv)
>> - git doesn't build due to unresolved external locale_charset()
>>
>> Fix this by adding -liconv to CHARSET_LIB if locale_charset() is
>> detected in this library.
>>
>> Signed-off-by: Dmitry Marakasov <amdmi3@amdmi3.ru>
>> ---
>
> Looks sensible; Dilyan, any comments?
>
>> configure.ac | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git configure.ac configure.ac
>> index 2f43393..3f5c644 100644
>> --- configure.ac
>> +++ configure.ac
>> @@ -890,7 +890,7 @@ GIT_CONF_SUBST([HAVE_STRINGS_H])
>> # and libcharset does
>> CHARSET_LIB=
>> AC_CHECK_LIB([iconv], [locale_charset],
>> - [],
>> + [CHARSET_LIB=-liconv],
>> [AC_CHECK_LIB([charset], [locale_charset],
>> [CHARSET_LIB=-lcharset])])
>> GIT_CONF_SUBST([CHARSET_LIB])
Show changes to Makefile +2 −2
diff --git a/Makefile b/Makefile
index dddaf4f..dce4694 100644
--- a/Makefile
+++ b/Makefile
@@ -59,9 +59,9 @@ all::
# FreeBSD can use either, but MinGW and some others need to use
# libcharset.h's locale_charset() instead.
#
-# Define CHARSET_LIB to you need to link with library other than -liconv to
+# Define CHARSET_LIB to the library you need to link with in order to
# use locale_charset() function. On some platforms this needs to set to
-# -lcharset
+# -lcharset, on others to -liconv .
#
# Define LIBC_CONTAINS_LIBINTL if your gettext implementation doesn't
# need -lintl when linking.
Dmitry Marakasov