1.7.9, libcharset missing from EXTLIBS

1.7.9, libcharset missing from EXTLIBS

[Дилян Палаузов]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Hello,

git 1.7.9 makes use of libcharset and /Makefile contains:

ifdef HAVE_LIBCHARSET_H
         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
endif

when building git-daemon., the compiler reports
make V=1
cc  -I. -DUSE_LIBPCRE -pthread -DHAVE_PATHS_H -DHAVE_LIBCHARSET_H 
-DHAVE_DEV_TTY -DSHA1_HEADER='<openssl/sha.h>'  -DNO_STRLCPY -o 
git-daemon -L/usr/lib64 -L/lib64  daemon.o libgit.a xdiff/lib.a  -lpcre 
-lz  -liconv  -lcrypto -pthread
/tmp/ccvPEthi.ltrans0.ltrans.o: In function `main':
ccvPEthi.ltrans0.o:(.text.startup+0x59): undefined reference to 
`locale_charset'
collect2: ld returned 1 exit status
make: *** [git-daemon] Error 1


and the problem is, that libcharset is not used when linking.  To solve 
this, please replace the above extract from /Makefile with

ifdef HAVE_LIBCHARSET_H
         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
	EXTLIBS += -lcharset
endif

Със здраве
   Дилян

[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]

begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
	=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard

Re: 1.7.9, libcharset missing from EXTLIBS

[Junio C Hamano]

Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:

> Hello,
>
> git 1.7.9 makes use of libcharset and /Makefile contains:
>
> ifdef HAVE_LIBCHARSET_H
>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> endif
> ...
> and the problem is, that libcharset is not used when linking.  To
> solve this, please replace the above extract from /Makefile with
>
> ifdef HAVE_LIBCHARSET_H
>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> 	EXTLIBS += -lcharset
> endif

Thanks.

What platform is this?  Is there a guarantee that any and all system that
use "#include <libcharset.h>" has to link with "-lcharset"?

What I am wondering is there are systems that need to include the header,
but locale_charset() does not live in /lib/libcharset.a, in which case we
cannot make HAVE_LIBCHARSET_H imply use of -lcharset.

Re: 1.7.9, libcharset missing from EXTLIBS

[Ævar Arnfjörð Bjarmason]

2012/2/10 Junio C Hamano <gitster@pobox.com>:
> Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:
>
>> Hello,
>>
>> git 1.7.9 makes use of libcharset and /Makefile contains:
>>
>> ifdef HAVE_LIBCHARSET_H
>>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>> endif
>> ...
>> and the problem is, that libcharset is not used when linking.  To
>> solve this, please replace the above extract from /Makefile with
>>
>> ifdef HAVE_LIBCHARSET_H
>>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>       EXTLIBS += -lcharset
>> endif
>
> Thanks.
>
> What platform is this?  Is there a guarantee that any and all system that
> use "#include <libcharset.h>" has to link with "-lcharset"?
>
> What I am wondering is there are systems that need to include the header,
> but locale_charset() does not live in /lib/libcharset.a, in which case we
> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.

I've had some similar (privately sent) bug reports about the i18n
stuff from someone who built his own Linux distro.

Basically we make assumptions that certain stuff will be in the C
library on certain platforms, certain headers go with certain
libraries etc.

Evidently none of this can really be relied upon and we'd have to
probe for each one if we wanted to make it reliable.

Re: 1.7.9, libcharset missing from EXTLIBS

[Дилян Палаузов]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

Hello,

>> What platform is this?  Is there a guarantee that any and all system that
>> use "#include<libcharset.h>" has to link with "-lcharset"?
>
> I've had some similar (privately sent) bug reports about the i18n
> stuff from someone who built his own Linux distro.

I run Linux from scratch.

>> What I am wondering is there are systems that need to include the header,
>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.

I do not understand this.  If you want to use a function from 
libcharset, you have to use both #include <libcharset.h> and -lcharset.

Със здраве
   Дилян

On 10.02.2012 11:06, Ævar Arnfjörð Bjarmason wrote:
> 2012/2/10 Junio C Hamano<gitster@pobox.com>:
>> Дилян Палаузов<dilyan.palauzov@aegee.org>  writes:
>>
>>> Hello,
>>>
>>> git 1.7.9 makes use of libcharset and /Makefile contains:
>>>
>>> ifdef HAVE_LIBCHARSET_H
>>>          BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>> endif
>>> ...
>>> and the problem is, that libcharset is not used when linking.  To
>>> solve this, please replace the above extract from /Makefile with
>>>
>>> ifdef HAVE_LIBCHARSET_H
>>>          BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>>        EXTLIBS += -lcharset
>>> endif
>>
>> Thanks.
>>
>> What platform is this?  Is there a guarantee that any and all system that
>> use "#include<libcharset.h>" has to link with "-lcharset"?
>>
>> What I am wondering is there are systems that need to include the header,
>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>
> I've had some similar (privately sent) bug reports about the i18n
> stuff from someone who built his own Linux distro.
>
> Basically we make assumptions that certain stuff will be in the C
> library on certain platforms, certain headers go with certain
> libraries etc.
>
> Evidently none of this can really be relied upon and we'd have to
> probe for each one if we wanted to make it reliable.

[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]

begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
	=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard

Re: 1.7.9, libcharset missing from EXTLIBS

[Jakub Narebski]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 2012/2/10 Junio C Hamano <gitster@pobox.com>:
>> Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:

>>> git 1.7.9 makes use of libcharset and /Makefile contains:
> >>
>>> ifdef HAVE_LIBCHARSET_H
>>>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>> endif
>>> ...
>>> and the problem is, that libcharset is not used when linking.  To
>>> solve this, please replace the above extract from /Makefile with
>>>
>>> ifdef HAVE_LIBCHARSET_H
>>>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>>         EXTLIBS += -lcharset
>>> endif
[....]
> I've had some similar (privately sent) bug reports about the i18n
> stuff from someone who built his own Linux distro.
> 
> Basically we make assumptions that certain stuff will be in the C
> library on certain platforms, certain headers go with certain
> libraries etc.
> 
> Evidently none of this can really be relied upon and we'd have to
> probe for each one if we wanted to make it reliable.

Well, there is always *optional* configure.ac to do detection;
"make configure; ./configure <options>" will generate config.mak.autogen
with appropriate options -- we can add autodetection if -lcharset
must be added.

-- 
Jakub Narębski

Re: 1.7.9, libcharset missing from EXTLIBS

[Junio C Hamano]

Дилян Палаузов <dilyan.palauzov@aegee.org> writes:

>>> What I am wondering is there are systems that need to include the header,
>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>
> I do not understand this.  If you want to use a function from
> libcharset, you have to use both #include <libcharset.h> and
> -lcharset.

You are mistaken.

The only constraint is that you have to "#include <libcharset.h>" and need
to link with the library that has locale_charset() defined.  Does everybody
has that function in -lcharset, or a system you do not know have it in some
other library?

For example, Msysgit part defines HAVE_LIBCHARSET_H but it apparently does
not need -lcharset. It could be that the port is incomplete, but another
possibility is that perhaps the function is in part of libc and does not
even need -lcharset passed to the linker.

If you look at our Makefile, you see "On this platform foo() can be
obtained by linking with -lfoo, but on this other platform you need to
link with -lbar" gotchas around some libraries (e.g. ssl/crypto), and I am
wondering if this function has a similar issue.

Re: 1.7.9, libcharset missing from EXTLIBS

[Dilyan Palauzov]

Hello,

on my system locale_charset is included in libiconv as local symbol  
and thus linking with -liconv is not sufficient.

   nm /usr/lib64/libiconv.so.2.5.1 | grep locale
   0000000000012694 t locale_charset

whereas in libcharset the symbol is global:

   nm /usr/lib64/libcharset.so.1 |grep locale
   0000000000000c50 T locale_charset

looking at libiconv-1.4/lib/Makefile.in there is written

SOURCES = $(srcdir)/iconv.c $(srcdir)/../libcharset/lib/localcharset.c  
$(srcdir)/relocatable.c

OBJECTS = iconv.lo localcharset.lo relocatable.lo  
$(OBJECTS_EXP_@WOE32DLL@) $(OBJECTS_RES_@WOE32@)

libiconv.la : $(OBJECTS)
         $(LIBTOOL_LINK) $(CC) $(LDFLAGS) $(CFLAGS) -o libiconv.la  
-rpath $(libdir) -version-info $(LIBICONV_VERSION_INFO) -no-undefined  
$(OBJECTS)

this means, that libiconv.la includes $(OBJECTS) and thus  
libiconv-1.4/libcharset/lib/localecharset.c .

In libiconv-1.4/libcharset/lib/localecharset.c is written

#ifdef STATIC
STATIC
#endif
const char *
locale_charset (void) { ...}

and the preliminary localcharset.o still has locale_charset as global symbol:

libiconv-1.14/lib/.libs # nm localcharset.o |grep locale
0000000000000000 T locale_charset

Digging further, in libiconv-1.4/include/iconv.h some functions are  
prefixed with LIBICONV_DLL_EXPORTED , which is the same as
#define LIBICONV_DLL_EXPORTED  
__attribute__((__visibility__("default"))) , all the rest including  
locale_charset is compiled with  
__attribute__((__visibility__("hidden"))), and hence locale_charset is  
not exported from libiconv.

Greetings
   Dilian


----- Message from Дилян Палаузов <dilyan.palauzov@aegee.org> ---------
    Date: Fri, 10 Feb 2012 02:29:24 +0100
    From: Дилян Палаузов <dilyan.palauzov@aegee.org>
Subject: 1.7.9, libcharset missing from EXTLIBS
      To: git@vger.kernel.org


> Hello,
>
> git 1.7.9 makes use of libcharset and /Makefile contains:
>
> ifdef HAVE_LIBCHARSET_H
>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> endif
>
> when building git-daemon., the compiler reports
> make V=1
> cc  -I. -DUSE_LIBPCRE -pthread -DHAVE_PATHS_H -DHAVE_LIBCHARSET_H  
> -DHAVE_DEV_TTY -DSHA1_HEADER='<openssl/sha.h>'  -DNO_STRLCPY -o  
> git-daemon -L/usr/lib64 -L/lib64  daemon.o libgit.a xdiff/lib.a   
> -lpcre -lz  -liconv  -lcrypto -pthread
> /tmp/ccvPEthi.ltrans0.ltrans.o: In function `main':
> ccvPEthi.ltrans0.o:(.text.startup+0x59): undefined reference to  
> `locale_charset'
> collect2: ld returned 1 exit status
> make: *** [git-daemon] Error 1
>
>
> and the problem is, that libcharset is not used when linking.  To  
> solve this, please replace the above extract from /Makefile with
>
> ifdef HAVE_LIBCHARSET_H
>         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> 	EXTLIBS += -lcharset
> endif
>
> Със здраве
>   Дилян


----- End message from Дилян Палаузов <dilyan.palauzov@aegee.org> -----

Re: 1.7.9, libcharset missing from EXTLIBS

[Erik Faye-Lund]

2012/2/10 Dilyan Palauzov <Dilyan.Palauzov@aegee.org>:
> Hello,
>
> on my system locale_charset is included in libiconv as local symbol and thus
> linking with -liconv is not sufficient.
>
>  nm /usr/lib64/libiconv.so.2.5.1 | grep locale
>  0000000000012694 t locale_charset
>
> whereas in libcharset the symbol is global:
>
>  nm /usr/lib64/libcharset.so.1 |grep locale
>  0000000000000c50 T locale_charset
>

This is from the import library for libiconv we use for Git for Windows:

$ nm /mingw/lib/libiconv.dll.a | grep locale_charset
00000000 I __imp__locale_charset
00000000 T _locale_charset

Looks pretty defined to me.

Re: 1.7.9, libcharset missing from EXTLIBS

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>
>>>> What I am wondering is there are systems that need to include the header,
>>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>>
>> I do not understand this.  If you want to use a function from
>> libcharset, you have to use both #include <libcharset.h> and
>> -lcharset.
>
> You are mistaken.
>
> The only constraint is that you have to "#include <libcharset.h>" and need
> to link with the library that has locale_charset() defined.

I think the follow-ups in this thread already demonstrated why it is an
insufficient solution to make HAVE_LIBCHARSET_H imply -lcharset.

We would instead need:

	ifeq ($(uname_S),MyHomeBrewLinux)
        	HAVE_LIBCHARSET_H = YesPlease
                EXTLIBS += -lcharset
	endif

or

	# Define NEEDS_CHARSETLIB if you use HAVE_LIBCHARSET_H and
        # need to link with -lcharset
	NEEDS_CHARSETLIB =

	ifeq ($(uname_S),MyHomeBrewLinux)
        	HAVE_LIBCHARSET_H = YesPlease
		NEEDS_CHARSETLIB = YesPlease
	endif

	ifdef NEEDS_CHARSETLIB
        	EXTLIBS += -lcharset
	endif        

or something like that, I guess.

Re: 1.7.9, libcharset missing from EXTLIBS

[Дилян Палаузов]

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]

Hello,

please consider the patch below as fix for the problem.  It checks if 
locale_charset is not in libiconv, but in libcharset and in this case 
appends -lcharset to EXTLIBS.

Със здраве
   Дилян

diff -u git-1.7.9.orig/config.mak.in git-1.7.9/config.mak.in
--- git-1.7.9.orig/config.mak.in        2012-01-27 20:51:04.000000000 +0000
+++ git-1.7.9/config.mak.in     2012-02-12 00:52:41.457968080 +0000
@@ -74,3 +74,4 @@
  NO_PTHREADS=@NO_PTHREADS@
  PTHREAD_CFLAGS=@PTHREAD_CFLAGS@
  PTHREAD_LIBS=@PTHREAD_LIBS@
+LINK_CHARSET=@LINK_CHARSET@
diff -u git-1.7.9.orig/configure.ac git-1.7.9/configure.ac
--- git-1.7.9.orig/configure.ac 2012-01-27 20:51:04.000000000 +0000
+++ git-1.7.9/configure.ac      2012-02-12 00:44:29.222967868 +0000
@@ -836,6 +836,18 @@
  [HAVE_LIBCHARSET_H=YesPlease],
  [HAVE_LIBCHARSET_H=])
  AC_SUBST(HAVE_LIBCHARSET_H)
+# Define LINK_LIBCHARSET if libiconv does not export the locale_charset 
symbol
+# and liblibcharset does
+LINK_CHARSET=
+AC_CHECK_LIB([iconv], [locale_charset],
+       [],
+       [AC_CHECK_LIB([charset], [locale_charset],
+                     [LINK_CHARSET=Yes])
+       ]
+)
+AC_SUBST(LINK_CHARSET)
+
+
  #
  # Define NO_STRCASESTR if you don't have strcasestr.
  GIT_CHECK_FUNC(strcasestr,
diff -u git-1.7.9.orig/Makefile git-1.7.9/Makefile
--- git-1.7.9.orig/Makefile     2012-01-27 20:51:04.000000000 +0000
+++ git-1.7.9/Makefile  2012-02-12 00:35:23.982967555 +0000
@@ -1692,6 +1692,9 @@

  ifdef HAVE_LIBCHARSET_H
         BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
+ifdef LINK_CHARSET
+       EXTLIBS += -lcharset
+endif
  endif

  ifdef HAVE_DEV_TTY

On 10.02.2012 21:25, Junio C Hamano wrote:
> Junio C Hamano<gitster@pobox.com>  writes:
>
>> Дилян Палаузов<dilyan.palauzov@aegee.org>  writes:
>>
>>>>> What I am wondering is there are systems that need to include the header,
>>>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>>>
>>> I do not understand this.  If you want to use a function from
>>> libcharset, you have to use both #include<libcharset.h>  and
>>> -lcharset.
>>
>> You are mistaken.
>>
>> The only constraint is that you have to "#include<libcharset.h>" and need
>> to link with the library that has locale_charset() defined.
>
> I think the follow-ups in this thread already demonstrated why it is an
> insufficient solution to make HAVE_LIBCHARSET_H imply -lcharset.
>
> We would instead need:
>
> 	ifeq ($(uname_S),MyHomeBrewLinux)
>          	HAVE_LIBCHARSET_H = YesPlease
>                  EXTLIBS += -lcharset
> 	endif
>
> or
>
> 	# Define NEEDS_CHARSETLIB if you use HAVE_LIBCHARSET_H and
>          # need to link with -lcharset
> 	NEEDS_CHARSETLIB =
>
> 	ifeq ($(uname_S),MyHomeBrewLinux)
>          	HAVE_LIBCHARSET_H = YesPlease
> 		NEEDS_CHARSETLIB = YesPlease
> 	endif
>
> 	ifdef NEEDS_CHARSETLIB
>          	EXTLIBS += -lcharset
> 	endif
>
> or something like that, I guess.
>

[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]

begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
	=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard

Re: 1.7.9, libcharset missing from EXTLIBS

[Ævar Arnfjörð Bjarmason]

2012/2/12 Дилян Палаузов <dilyan.palauzov@aegee.org>:


This looks good to me, could you please re-submit it as described in
Documentation/SubmittingPatches? I.e. with a signed-off-by etc.

Re: 1.7.9, libcharset missing from EXTLIBS

[Junio C Hamano]

Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:

> diff -u git-1.7.9.orig/config.mak.in git-1.7.9/config.mak.in
> --- git-1.7.9.orig/config.mak.in        2012-01-27 20:51:04.000000000 +0000
> +++ git-1.7.9/config.mak.in     2012-02-12 00:52:41.457968080 +0000
> @@ -74,3 +74,4 @@
>  NO_PTHREADS=@NO_PTHREADS@
>  PTHREAD_CFLAGS=@PTHREAD_CFLAGS@
>  PTHREAD_LIBS=@PTHREAD_LIBS@
> +LINK_CHARSET=@LINK_CHARSET@
> diff -u git-1.7.9.orig/configure.ac git-1.7.9/configure.ac
> --- git-1.7.9.orig/configure.ac 2012-01-27 20:51:04.000000000 +0000
> +++ git-1.7.9/configure.ac      2012-02-12 00:44:29.222967868 +0000
> @@ -836,6 +836,18 @@
>  [HAVE_LIBCHARSET_H=YesPlease],
>  [HAVE_LIBCHARSET_H=])
>  AC_SUBST(HAVE_LIBCHARSET_H)
> +# Define LINK_LIBCHARSET if libiconv does not export the

Because the use of configure is optional in our build infrastructure, I
wouldn't have objected if this comment were missing from configure.ac, but
the new variable *must* be described in Makefile (see the top 250 lines or
so of that file).

I also need to point out that LINK_LIBCHARSET does not sit very well with
the way how existing Makefile variables are named. Perhaps make the new
variable contain the necessary string ("-lcharset" in your case), and name
it CHARSET_LIB or something?  By doing so, when we find a platform that
has the necessary locale_charset() not in libcharset.{a,so} but somewhere
else, e.g. libxyzzy.a, we can accomodate it with "CHARSET_LIB = -lxyzzy".

Thanks.  Also as Ævar pointed out, please do not forget to sign off your
patch.

[PATCH] Re: 1.7.9, libcharset missing from EXTLIBS

[Дилян Палаузов]

[-- Attachment #1: Type: text/plain, Size: 4091 bytes --]

The function locale_charset might appear in libiconv as local symbol.  In
this case linking with -lcharset delivers locale_charset, when the function
is exported from that library.  This patch defines a new Autoconf/make
variable CHARSET_LIB to contain the library exporting locale_charset and
fixes configure.ac to fill CHARSET_LIB with " -lcharset", when
locale_charset is not exported from libiconv, but is exported from
libcharset, and amends EXTLIBS to include CHARSET_LIB when HAVE_LIBCHARSET_H
is defined.

Signed-off-by: Дилян Палаузов <git-dpa@aegee.org>
---
 Makefile      |    6 ++++++
 config.mak.in |    1 +
 configure.ac  |   10 ++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 87fb30a..571d864 100644
--- a/Makefile
+++ b/Makefile
@@ -56,6 +56,11 @@ all::
 # FreeBSD can use either, but MinGW and some others need to use
 # libcharset.h's locale_charset() instead.
 #
+# Define CHARSET_LIB to contain the additional library exporting the symbol
+# locale_charset to link against.  configure.ac checks if locale_charset is
+# exported from libiconv, if not, it checks if locale_charset is
exported from
+# libcharset and defines then CHARSET_LIB to -lcharset .
+#
 # Define LIBC_CONTAINS_LIBINTL if your gettext implementation doesn't
 # need -lintl when linking.
 #
@@ -1698,6 +1703,7 @@ endif

 ifdef HAVE_LIBCHARSET_H
 	BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
+	EXTLIBS +=$(CHARSET_LIB)
 endif

 ifdef HAVE_DEV_TTY
diff --git a/config.mak.in b/config.mak.in
index 10698c8..b2ba710 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -74,3 +74,4 @@ SNPRINTF_RETURNS_BOGUS=@SNPRINTF_RETURNS_BOGUS@
 NO_PTHREADS=@NO_PTHREADS@
 PTHREAD_CFLAGS=@PTHREAD_CFLAGS@
 PTHREAD_LIBS=@PTHREAD_LIBS@
+CHARSET_LIB=@CHARSET_LIB@
diff --git a/configure.ac b/configure.ac
index 630dbdd..1c21a5b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -836,6 +836,16 @@ AC_CHECK_HEADER([libcharset.h],
 [HAVE_LIBCHARSET_H=YesPlease],
 [HAVE_LIBCHARSET_H=])
 AC_SUBST(HAVE_LIBCHARSET_H)
+# Define CHARSET_LIB if libiconv does not export the locale_charset symbol
+# and libcharset does
+CHARSET_LIB=
+AC_CHECK_LIB([iconv], [locale_charset],
+       [],
+       [AC_CHECK_LIB([charset], [locale_charset],
+                     [CHARSET_LIB=" -lcharset"])
+       ]
+)
+AC_SUBST(CHARSET_LIB)
 #
 # Define NO_STRCASESTR if you don't have strcasestr.
 GIT_CHECK_FUNC(strcasestr,
-- 
1.7.9



On 12.02.2012 11:30, Junio C Hamano wrote:
> Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:
> 
>> diff -u git-1.7.9.orig/config.mak.in git-1.7.9/config.mak.in
>> --- git-1.7.9.orig/config.mak.in        2012-01-27 20:51:04.000000000 +0000
>> +++ git-1.7.9/config.mak.in     2012-02-12 00:52:41.457968080 +0000
>> @@ -74,3 +74,4 @@
>>  NO_PTHREADS=@NO_PTHREADS@
>>  PTHREAD_CFLAGS=@PTHREAD_CFLAGS@
>>  PTHREAD_LIBS=@PTHREAD_LIBS@
>> +LINK_CHARSET=@LINK_CHARSET@
>> diff -u git-1.7.9.orig/configure.ac git-1.7.9/configure.ac
>> --- git-1.7.9.orig/configure.ac 2012-01-27 20:51:04.000000000 +0000
>> +++ git-1.7.9/configure.ac      2012-02-12 00:44:29.222967868 +0000
>> @@ -836,6 +836,18 @@
>>  [HAVE_LIBCHARSET_H=YesPlease],
>>  [HAVE_LIBCHARSET_H=])
>>  AC_SUBST(HAVE_LIBCHARSET_H)
>> +# Define LINK_LIBCHARSET if libiconv does not export the
> 
> Because the use of configure is optional in our build infrastructure, I
> wouldn't have objected if this comment were missing from configure.ac, but
> the new variable *must* be described in Makefile (see the top 250 lines or
> so of that file).
> 
> I also need to point out that LINK_LIBCHARSET does not sit very well with
> the way how existing Makefile variables are named. Perhaps make the new
> variable contain the necessary string ("-lcharset" in your case), and name
> it CHARSET_LIB or something?  By doing so, when we find a platform that
> has the necessary locale_charset() not in libcharset.{a,so} but somewhere
> else, e.g. libxyzzy.a, we can accomodate it with "CHARSET_LIB = -lxyzzy".
> 
> Thanks.  Also as Ævar pointed out, please do not forget to sign off your
> patch.

[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]

begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
	=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard