threads / discuss / 29590

1.7.9, libcharset missing from EXTLIBS

Subject: 1.7.9, libcharset missing from EXTLIBS

## tl;dr

13 messages between Feb 10, 2012 and Feb 12, 2012.

replies: 12people: 5as markdown or json

Дилян Палаузов· Feb 10, 2012, 01:29 UTC · lore
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
Със здраве
   Дилян
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
Junio C Hamano· Feb 10, 2012, 02:13 UTC · re: Дилян Палаузов · lore

Re: 1.7.9, libcharset missing from EXTLIBS

Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:
Show 15 quoted lines
> 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.

Ævar Arnfjörð Bjarmason· Feb 10, 2012, 10:06 UTC · re: Junio C Hamano · lore

Re: 1.7.9, libcharset missing from EXTLIBS

2012/2/10 Junio C Hamano <gitster@pobox.com>:
Show 26 quoted lines
> Дилян Палаузов  <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.

Дилян Палаузов· Feb 10, 2012, 10:21 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: 1.7.9, libcharset missing from EXTLIBS

Hello,
Show 5 quoted lines
>> 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:
Show 37 quoted lines
> 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.
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
Junio C Hamano· Feb 10, 2012, 18:35 UTC · re: Дилян Палаузов · lore

Re: 1.7.9, libcharset missing from EXTLIBS

Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
Show 7 quoted lines
>>> 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.

Dilyan Palauzov· Feb 10, 2012, 19:52 UTC · re: Junio C Hamano · lore

Re: 1.7.9, libcharset missing from EXTLIBS

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
Show 31 quoted lines
> 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> -----
Erik Faye-Lund· Feb 10, 2012, 20:10 UTC · re: Dilyan Palauzov · lore

Re: 1.7.9, libcharset missing from EXTLIBS

2012/2/10 Dilyan Palauzov <Dilyan.Palauzov@aegee.org>:
Show 13 quoted lines
> 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.
Junio C Hamano· Feb 10, 2012, 20:25 UTC · re: Junio C Hamano · lore

Re: 1.7.9, libcharset missing from EXTLIBS

Junio C Hamano <gitster@pobox.com> writes:
Show 14 quoted lines
> Дилян Палаузов <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.
Дилян Палаузов· Feb 12, 2012, 00:55 UTC · re: Junio C Hamano · lore

Re: 1.7.9, libcharset missing from EXTLIBS

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.
>


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
Junio C Hamano· Feb 12, 2012, 10:30 UTC · re: Дилян Палаузов · lore

Re: 1.7.9, libcharset missing from EXTLIBS

Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:
Show 16 quoted lines
> 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.

Дилян Палаузов· Feb 12, 2012, 16:23 UTC · re: Junio C Hamano · lore

[PATCH] Re: 1.7.9, libcharset missing from EXTLIBS

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.


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
Jakub Narebski· Feb 10, 2012, 13:15 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: 1.7.9, libcharset missing from EXTLIBS

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 2012/2/10 Junio C Hamano <gitster@pobox.com>:
>> Дилян Палаузов  <dilyan.palauzov@aegee.org> writes:
Show 13 quoted lines
>>> 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
[....]
Show 9 quoted lines
> 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

← back to recent threads