git: Fix libintl linking if there is no full gettext support

PATCH New Vadim Kochan 2 participants 5 messages Aug 25, 2018 – Aug 29, 2018

lore

Share & tools

lore

Vadim Kochan

author

2018-08-25 13:10 UTC #0 lore raw

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

From: Vadim Kochan <[email protected]>

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 <[email protected]>

---
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(+)

package/git/git.mk +8 -0

index ac7b8f2e8c..fb5889dec7 100644
@@ -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

Signature · 1 line

2.14.1

Thomas Petazzoni

2018-08-25 17:40 UTC #1 lore raw

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

Hello,

Quoted 1 line · Vadim Kochan

From: Vadim Kochan <[email protected]>

Thanks for this new iteration.

Quoted 8 lines

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.

Quoted 3 lines

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

Signature · 3 lines

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

Vadim Kochan

author

2018-08-25 20:15 UTC #2 lore raw

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

Quoted 43 lines · Thomas Petazzoni

Hello,
Quoted 1 line · Vadim Kochan
From: Vadim Kochan <[email protected]>
Thanks for this new iteration.
Quoted 6 lines
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
Quoted 2 lines
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.
Quoted 3 lines
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.

Quoted 7 lines

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,

Vadim Kochan

author

2018-08-27 05:28 UTC #3 lore raw

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

Hi Thomas,

Quoted 53 lines · Vadim Kochan

Quoted 43 lines · Thomas Petazzoni
Hello,
Quoted 1 line · Vadim Kochan
From: Vadim Kochan <[email protected]>
Thanks for this new iteration.
Quoted 6 lines
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
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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 ?

Quoted 8 lines

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,

Vadim Kochan

author

2018-08-29 14:53 UTC #4 lore raw

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

Hi Thomas,

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

Regards,
Vadim Kochan