From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Mon, 11 Mar 2019 09:02:35 +0100 Subject: [Buildroot] [PATCH v3 0/2] Add gettext-tiny package In-Reply-To: <20190310230532.4dhczaa4sygw75ie@vkochan-ThinkPad-T470p> References: <20190212215520.7422-1-vadim4j@gmail.com> <20190309233742.3095c546@windsurf> <20190310002005.jglt6ptlgctyz6eb@vkochan-ThinkPad-T470p> <20190310101126.3d738624@windsurf> <20190310101852.GB25009@scaer> <20190310230532.4dhczaa4sygw75ie@vkochan-ThinkPad-T470p> Message-ID: <20190311090235.4e64625b@windsurf> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hello, On Mon, 11 Mar 2019 01:05:32 +0200 Vadim Kochan wrote: > But, it looks like that there should be no problem if NLS is disabled > (host-gettext is provided by gettext-tiny) and gettext (target) > (provided by gettext-gnu) are enabled in the same time (of course 1 > small fix is required in latest gettext-tiny series v3): > > in file package/gettext/Config.in > > > config BR2_PACKAGE_GETTEXT > > bool "gettext" > > select BR2_PACKAGE_HAS_GETTEXT > *remove -> depends on BR2_SYSTEM_ENABLE_NLS > > remove dependens on NLS to select gettext-gnu for the target. > > So, both host-gettext-tiny and gettext-gnu should coexist as they > provides different instances, right ? > > If this is ok, then of course ecryptfs-utils needs support the gettext-less > version, but it might be done later out of this scope ? I don't really like to do this. It's a lot better if we can avoid gettext-gnu entirely if NLS is disabled. So I'd prefer if we could stick to one of the two options I proposed in my reply to your v3: Option 1: we fix ecryptfs-utils to not unconditionally use gettext. Option 2: we improve gettext-tiny so that it provides a fake gettext implementation, and we allow gettext-tiny as a gettext implementation for the target. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com