[Buildroot] [PATCH v2 1/1] git: Fix libintl linking if there is no full gettext support

[Buildroot] [PATCH v2 1/1] git: Fix libintl linking if there is no full gettext support

[Vadim Kochan]

From: Vadim Kochan <vadim.kochan@petcube.com>

Git could not resolve libntl_xxx symbols if toolchain does no provide
full gettext support but the gettext package is selected.

Steps to reproduce:
    1) make menuconfig
    2) Toolchain -> Select WCHAR
    3) System -> select NLS
    4) Target packages -> Development -> select git

In case of ulibc/musl toolchain there is no full getttext support, but
they still provides libintl stub which makes git think there is full
gettext support hence -lintl is not passed to the linker.

Added workaround which checks if NLS is enabled, if yes then -lintl will
be added to EXTLIBS variable within config.mak file.

Signed-off-by: Vadim Kochan <vadim.kochan@petcube.com>
---
v2:
    - added steps to reproduce in commit message
    - use $(TARGET_NLS_LIBS) to specify -lintl

 package/git/git.mk | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/package/git/git.mk b/package/git/git.mk
index ac7b8f2e8c..fb5889dec7 100644
--- a/package/git/git.mk
+++ b/package/git/git.mk
@@ -63,8 +63,16 @@ endif
 
 ifeq ($(BR2_SYSTEM_ENABLE_NLS),)
 GIT_MAKE_OPTS += NO_GETTEXT=1
+else
+GIT_EXTLIBS += $(TARGET_NLS_LIBS)
 endif
 
+define GIT_GEN_EXT_CONFIG_CMDS
+	echo "EXTLIBS = $(GIT_EXTLIBS)" >> $(@D)/config.mak
+endef
+
+GIT_POST_CONFIGURE_HOOKS += GIT_GEN_EXT_CONFIG_CMDS
+
 GIT_INSTALL_TARGET_OPTS = $(GIT_MAKE_OPTS) DESTDIR=$(TARGET_DIR) install
 
 # assume yes for these tests, configure will bail out otherwise
-- 
2.14.1

[Buildroot] [PATCH v2 1/1] git: Fix libintl linking if there is no full gettext support

[Thomas Petazzoni]

Hello,

On Sat, 25 Aug 2018 16:10:27 +0300, Vadim Kochan wrote:
> From: Vadim Kochan <vadim.kochan@petcube.com>

Thanks for this new iteration.

> Git could not resolve libntl_xxx symbols if toolchain does no provide
> full gettext support but the gettext package is selected.
> 
> Steps to reproduce:
>     1) make menuconfig
>     2) Toolchain -> Select WCHAR
>     3) System -> select NLS
>     4) Target packages -> Development -> select git

Instead of this, it is often simpler to include a minimal defconfig
that exhibits the problem. I.e, when you have your .config that shows
the problem, run "make savedefconfig", and look at the generated
"defconfig" file. It shows only the values that are different from the
default ones, so for an example like what you gave above, it would be
just three lines of configuration.

> In case of ulibc/musl toolchain there is no full getttext support, but
> they still provides libintl stub which makes git think there is full
> gettext support hence -lintl is not passed to the linker.

Are you sure this is what is happening ? The stub in uclibc and musl
provide all the gettext functions, that's the whole point of the stub.

However, when you have the full gettext support enabled, the libintl.h
header installed is the one from the full gettext, and it redefines the
gettext functions with a different name, and that different name is
only provided by the full-blown gettext libintl library.

Could you double check this ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2 1/1] git: Fix libintl linking if there is no full gettext support

[Vadim Kochan]

On Sat, Aug 25, 2018 at 8:40 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Sat, 25 Aug 2018 16:10:27 +0300, Vadim Kochan wrote:
> > From: Vadim Kochan <vadim.kochan@petcube.com>
>
> Thanks for this new iteration.
>
> > Git could not resolve libntl_xxx symbols if toolchain does no provide
> > full gettext support but the gettext package is selected.
> >
> > Steps to reproduce:
> >     1) make menuconfig
> >     2) Toolchain -> Sele> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.comct WCHAR
> >     3) System -> select NLS
> >     4) Target packages -> Development -> select git
>
> Instead of this, it is often simpler to include a minimal defconfig
> that exhibits the problem. I.e, when you have your .config that shows
> the problem, run "make savedefconfig", and look at the generated
> "defconfig" file. It shows only the values that are different from the
> default ones, so for an example like what you gave above, it would be
> just three lines of configuration.
>
> > In case of ulibc/musl toolchain there is no full getttext support, but
> > they still provides libintl stub which makes git think there is full
> > gettext support hence -lintl is not passed to the linker.
>
> Are you sure this is what is happening ? The stub in uclibc and musl
> provide all the gettext functions, that's the whole point of the stub.
>
> However, when you have the full gettext support enabled, the libintl.h
> header installed is the one from the full gettext, and it redefines the
> gettext functions with a different name, and that different name is
> only provided by the full-blown gettext libintl library.
>
> Could you double check this ?
>
As I understood, in case of non-glibc toolchain the gettext macroses calls
libintl functions with libintl_ prefix (_INTL_REDIRECT_MACROS in
gettext sources).
And because there is no such in the uclibc/musl, the git can't resolve them
because the '-lintl' is not passed to be linked with shared library
(gettext version).

Regards,

[Buildroot] [PATCH v2 1/1] git: Fix libintl linking if there is no full gettext support

[Vadim Kochan]

Hi Thomas,

On Sat, Aug 25, 2018 at 11:15 PM Vadim Kochan <vadim4j@gmail.com> wrote:
>
> On Sat, Aug 25, 2018 at 8:40 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > On Sat, 25 Aug 2018 16:10:27 +0300, Vadim Kochan wrote:
> > > From: Vadim Kochan <vadim.kochan@petcube.com>
> >
> > Thanks for this new iteration.
> >
> > > Git could not resolve libntl_xxx symbols if toolchain does no provide
> > > full gettext support but the gettext package is selected.
> > >
> > > Steps to reproduce:
> > >     1) make menuconfig
> > >     2) Toolchain -> Sele> Best regards,
> >
> > Thomas
> > --
> > Thomas Petazzoni, CTO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com> Best regards,
> >
> > Thomas
> > --
> > Thomas Petazzoni, CTO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.comct WCHAR
> > >     3) System -> select NLS
> > >     4) Target packages -> Development -> select git
> >
> > Instead of this, it is often simpler to include a minimal defconfig
> > that exhibits the problem. I.e, when you have your .config that shows
> > the problem, run "make savedefconfig", and look at the generated
> > "defconfig" file. It shows only the values that are different from the
> > default ones, so for an example like what you gave above, it would be
> > just three lines of configuration.
> >
> > > In case of ulibc/musl toolchain there is no full getttext support, but
> > > they still provides libintl stub which makes git think there is full
> > > gettext support hence -lintl is not passed to the linker.
> >
> > Are you sure this is what is happening ? The stub in uclibc and musl
> > provide all the gettext functions, that's the whole point of the stub.
> >
> > However, when you have the full gettext support enabled, the libintl.h
> > header installed is the one from the full gettext, and it redefines the
> > gettext functions with a different name, and that different name is
> > only provided by the full-blown gettext libintl library.
> >
> > Could you double check this ?
> >
> As I understood, in case of non-glibc toolchain the gettext macroses calls
> libintl functions with libintl_ prefix (_INTL_REDIRECT_MACROS in
> gettext sources).
> And because there is no such in the uclibc/musl, the git can't resolve them
> because the '-lintl' is not passed to be linked with shared library
> (gettext version).
>
> Regards,

Thats what I checked in gettext sources, so it looks like with
non-glibc toolchain
gettext defines exports and uses libintl_ prefix with standart gettext
API functions (like
libintl_ngettext, etc), so thats why linker can't resolve them while
git linking without -lintl
option. I am not sure I can provide more info :)

Regards,

[Buildroot] [PATCH v2 1/1] git: Fix libintl linking if there is no full gettext support

[Vadim Kochan]

Hi Thomas,

I 'd like to know if you still need more info/changes regarding this patch ?

Regards,
Vadim Kochan