1.7.9, libcharset missing from EXTLIBS
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:[email protected]
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:[email protected]
version:2.1
end:vcard
Quoted 11 lines · Дилян Палаузов
Hello,
git 1.7.9 makes use of libcharset and /Makefile contains:
ifdef
HAVE_LIBCHARSET_HBASIC_CFLAGS += -DHAVE_LIBCHARSET_Hendif
...
and the problem is, that libcharset is not used when linking. To solve this, please replace the above extract from /Makefile with
Quoted 4 lines
ifdef
HAVE_LIBCHARSET_HBASIC_CFLAGS += -DHAVE_LIBCHARSET_H EXTLIBS += -lcharsetendif
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.
2012/2/10 Junio C Hamano <[email protected]>:
Quoted 18 lines
Quoted 11 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 withQuoted 4 lines
ifdef
HAVE_LIBCHARSET_H
BASIC_CFLAGS+= -DHAVE_LIBCHARSET_H
EXTLIBS += -lcharset
endif
Quoted 8 lines
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 makeHAVE_LIBCHARSET_Himply 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.
Hello,
Quoted 5 lines
Quoted 2 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.
Quoted 3 lines
Quoted 3 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 makeHAVE_LIBCHARSET_Himply 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.
Със здраве
Дилян
Quoted 31 lines · Ævar Arnfjörð Bjarmason
2012/2/10 Junio C Hamano<[email protected]>:
Quoted 18 lines
Quoted 11 lines · Дилян Палаузов
Hello,
git 1.7.9 makes use of libcharset and /Makefile contains:
ifdef
HAVE_LIBCHARSET_HBASIC_CFLAGS += -DHAVE_LIBCHARSET_Hendif
...
and the problem is, that libcharset is not used when linking. To solve this, please replace the above extract from /Makefile withQuoted 4 lines
ifdef
HAVE_LIBCHARSET_HBASIC_CFLAGS += -DHAVE_LIBCHARSET_H EXTLIBS += -lcharsetendif
Quoted 8 lines
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 makeHAVE_LIBCHARSET_Himply use of -lcharset.I've had some similar (privately sent) bug reports about the i18n stuff from someone who built his own Linux distro.
Quoted 6 lines
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:[email protected]
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:[email protected]
version:2.1
end:vcard
Quoted 7 lines · Дилян Палаузов
Quoted 3 lines
Quoted 3 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 makeHAVE_LIBCHARSET_Himply 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.
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 Дилян Палаузов <[email protected]> ---------
Date: Fri, 10 Feb 2012 02:29:24 +0100
From: Дилян Палаузов <[email protected]>
Subject: 1.7.9, libcharset missing from EXTLIBS
To: [email protected]
Quoted 22 lines
Hello,
git 1.7.9 makes use of libcharset and /Makefile contains:
ifdef
HAVE_LIBCHARSET_HBASIC_CFLAGS += -DHAVE_LIBCHARSET_Hendif
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 1and the problem is, that libcharset is not used when linking. To solve this, please replace the above extract from /Makefile with
Quoted 7 lines
ifdef
HAVE_LIBCHARSET_HBASIC_CFLAGS += -DHAVE_LIBCHARSET_H EXTLIBS += -lcharsetendif
Със здраве
Дилян
----- End message from Дилян Палаузов <[email protected]> -----
2012/2/10 Dilyan Palauzov <[email protected]>:
Quoted 5 lines
Hello,
on my system
locale_charsetis included in libiconv as local symbol and thus linking with -liconv is not sufficient.
Quoted 8 lines
nm
/usr/lib64/libiconv.so.2.5.1| grep locale
0000000000012694 tlocale_charsetwhereas in libcharset the symbol is global:
nm
/usr/lib64/libcharset.so.1|grep locale
0000000000000c50 Tlocale_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.
Quoted 6 lines · Junio C Hamano
Quoted 4 lines · Дилян Палаузов
Quoted 3 lines
Quoted 3 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 makeHAVE_LIBCHARSET_Himply use of -lcharset.
Quoted 8 lines
Quoted 3 lines
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 haslocale_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
endifor
# 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.
Quoted 16 lines · Ævar Arnfjörð Bjarmason
2012/2/10 Junio C Hamano <[email protected]>:
Quoted 15 lines
Quoted 13 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 withifdef
HAVE_LIBCHARSET_H
BASIC_CFLAGS+= -DHAVE_LIBCHARSET_H
EXTLIBS += -lcharset
endif
[....]
Quoted 9 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.
Signature · 1 line
Jakub Narębski
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.
Със здраве
Дилян
config.mak.in 2012-02-12 00:52:41.457968080 +0000 renamed from config.mak.in 2012-01-27 20:51:04.000000000 +0000 +1 -0
@@ -74,3 +74,4 @@ NO_PTHREADS=@NO_PTHREADS@ PTHREAD_CFLAGS=@PTHREAD_CFLAGS@ PTHREAD_LIBS=@PTHREAD_LIBS@ +LINK_CHARSET=@LINK_CHARSET@
configure.ac 2012-02-12 00:44:29.222967868 +0000 renamed from configure.ac 2012-01-27 20:51:04.000000000 +0000 +12 -0
@@ -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,
Makefile 2012-02-12 00:35:23.982967555 +0000 renamed from Makefile 2012-01-27 20:51:04.000000000 +0000 +3 -0
@@ -1692,6 +1692,9 @@ ifdef HAVE_LIBCHARSET_H BASIC_CFLAGS += -DHAVE_LIBCHARSET_H +ifdef LINK_CHARSET + EXTLIBS += -lcharset +endif endif ifdef HAVE_DEV_TTY
Quoted 38 lines · Junio C Hamano
Quoted 6 lines · Junio C Hamano
Quoted 4 lines · Дилян Палаузов
Quoted 3 lines
Quoted 3 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 makeHAVE_LIBCHARSET_Himply use of -lcharset.Quoted 8 lines
Quoted 3 lines
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_Himply -lcharset.We would instead need:
ifeq ($(uname_S),MyHomeBrewLinux) HAVE_LIBCHARSET_H = YesPlease EXTLIBS += -lcharset endifor
# Define
NEEDS_CHARSETLIBif you useHAVE_LIBCHARSET_Hand
# need to link with -lcharset
NEEDS_CHARSETLIB=ifeq ($(uname_S),MyHomeBrewLinux)
HAVE_LIBCHARSET_H= YesPlease
NEEDS_CHARSETLIB= YesPlease
endif
Quoted 6 lines
ifdef
NEEDS_CHARSETLIB
EXTLIBS += -lcharset
endifor 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:[email protected]
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:[email protected]
version:2.1
end:vcard
Quoted 12 lines · Дилян Палаузов
diff -u git-1.7.9.orig/config.mak.in git-1.7.9/config.mak.in
config.mak.in 2012-02-12 00:52:41.457968080 +0000 renamed from config.mak.in 2012-01-27 20:51:04.000000000 +0000 +1
-0@@ -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
configure.ac 2012-02-12 00:44:29.222967868 +0000 line 839
Quoted 4 lines
configure.ac 2012-02-12 00:44:29.222967868 +0000 renamed from configure.ac 2012-01-27 20:51:04.000000000 +0000 +1
-0@@ -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.
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.
--- Makefile | 6 ++++++ config.mak.in | 1 + configure.ac | 10 ++++++++++ 3 files changed, 17 insertions(+), 0 deletions(-)
Makefile +3 -0
@@ -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
config.mak.in +1 -0
@@ -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@
configure.ac +10 -0
@@ -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,
Signature · 1 line
1.7.9
Quoted 31 lines · Junio C Hamano
Quoted 12 lines · Дилян Палаузов
diff -u git-1.7.9.orig/config.mak.in git-1.7.9/config.mak.in
config.mak.in 2012-02-12 00:52:41.457968080 +0000 renamed from config.mak.in 2012-01-27 20:51:04.000000000 +0000 +1
-0@@ -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
configure.ac 2012-02-12 00:44:29.222967868 +0000 line 839
Quoted 4 lines
configure.ac 2012-02-12 00:44:29.222967868 +0000 renamed from configure.ac 2012-01-27 20:51:04.000000000 +0000 +1
-0@@ -836,6 +836,18 @@ [HAVE_LIBCHARSET_H=YesPlease], [HAVE_LIBCHARSET_H=]) AC_SUBST(HAVE_LIBCHARSET_H) +# Define LINK_LIBCHARSET if libiconv does not export theBecause 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_LIBCHARSETdoes not sit very well with the way how existingMakefilevariables are named. Perhaps make the new variable contain the necessary string ("-lcharset" in your case), and name itCHARSET_LIBor something? By doing so, when we find a platform that has the necessarylocale_charset()not in libcharset.{a,so} but somewhere else, e.g. libxyzzy.a, we can accomodate it with "CHARSET_LIB= -lxyzzy".
Quoted 2 lines
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:[email protected]
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:[email protected]
version:2.1
end:vcard
2012/2/12 Дилян Палаузов <[email protected]>:
This looks good to me, could you please re-submit it as described in Documentation/SubmittingPatches? I.e. with a signed-off-by etc.