Skip to contentSkip to conversation

boost: correctly disable icu in locale if needed

PATCH New Fabrice Fontaine 3 participants 10 messages Jul 13, 2018 – Apr 8, 2019

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

boost doesn't take into account --without-icu flag and links libboost_locale with icu if it founds it in staging directory

So use boost.locale.icu to fix this issue

---
 package/boost/boost.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/boost/boost.mk +6 -0
index b2605a70b7..242b60a460 100644
@@ -116,6 +116,12 @@ ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
 BOOST_OPTS += boost.locale.posix=off
 endif
 
+ifeq ($(BR2_PACKAGE_ICU),y)
+BOOST_OPTS += boost.locale.icu=on
+else
+BOOST_OPTS += boost.locale.icu=off
+endif
+
 BOOST_DEPENDENCIES += $(if $(BR2_ENABLE_LOCALE),,libiconv)
 endif
 
Signature · 1 line
2.14.1
#1 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Hello Fabrice,

Quoted 15 lines · Fabrice Fontaine

boost doesn't take into account --without-icu flag and links libboost_locale with icu if it founds it in staging directory

So use boost.locale.icu to fix this issue

---
 package/boost/boost.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/boost/boost.mk +0 -0
index b2605a70b7..242b60a460 100644

package/boost/boost.mk ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y) · line 123

Quoted 8 lines
package/boost/boost.mk +5 -0
@@ -116,6 +116,12 @@ ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
 BOOST_OPTS += boost.locale.posix=off
 endif
 
+ifeq ($(BR2_PACKAGE_ICU),y)
+BOOST_OPTS += boost.locale.icu=on
+else
+BOOST_OPTS += boost.locale.icu=off
+endif

I'm not sure to fully understand what's going on here.

First, if --without-icu has no effect, why isn't your patch removing it ?

Second, why are you introducing another BR2_PACKAGE_ICU conditional, even if there's already one ?

Third, what is the problem with libboost_locale linking with icu if found in the staging directory ?

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#2 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Dear Thomas,

2018-07-14 22:41 GMT+02:00 Thomas Petazzoni <[email protected]>:

Quoted 29 lines

Hello Fabrice,

Quoted 15 lines · Fabrice Fontaine

boost doesn't take into account --without-icu flag and links libboost_locale with icu if it founds it in staging directory

So use boost.locale.icu to fix this issue

---
 package/boost/boost.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/boost/boost.mk +0 -0
index b2605a70b7..242b60a460 100644

package/boost/boost.mk ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y) · line 123

Quoted 8 lines
package/boost/boost.mk +5 -0
@@ -116,6 +116,12 @@ ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
 BOOST_OPTS += boost.locale.posix=off
 endif
 
+ifeq ($(BR2_PACKAGE_ICU),y)
+BOOST_OPTS += boost.locale.icu=on
+else
+BOOST_OPTS += boost.locale.icu=off
+endif

I'm not sure to fully understand what's going on here.

Quoted 3 lines

First, if --without-icu has no effect, why isn't your patch removing it ?

I don't fully understand yet what --without-icu does in the other boost libraries so I didn't want to remove it.
From my current understanding, icu should also (at least) be used by regex.

Quoted 4 lines

Second, why are you introducing another BR2_PACKAGE_ICU conditional, even if there's already one ?

Because there was already a BR2_PACKAGE_BOOST_LOCALE conditional and it seems strange to set boost.locale.icu if locale is not enabled. But I can move it if you think it's better.

Quoted 4 lines

Third, what is the problem with libboost_locale linking with icu if found in the staging directory ?

Because, if it links with icu, boost will also build chrono and thread. To avoid always selecting these two libraries, I sent a patch to select them only if BR2_PACKAGE_ICU is set (see http://patchwork.ozlabs.org/patch/943753).
My patch won't always work if boost links with icu when BR2_PACKAGE_ICU is not set (for example if the user changes his configuration between two builds). Perhaps, I should sent a patch serie with these two patches to better reflect the dependencies between them?

Quoted 9 lines

Thanks!

Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering
https://bootlin.com

Best Regards,

Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180714/1f579ddb/attachment.html>

#3 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Hello,

Quoted 6 lines · Fabrice Fontaine
Quoted 3 lines

First, if --without-icu has no effect, why isn't your patch removing it ?

I don't fully understand yet what --without-icu does in the other boost libraries so I didn't want to remove it.
From my current understanding, icu should also (at least) be used by regex.

--without-icu apparently has the effect that ICU_PATH is not defined, which has an impact in libs/locale/build/Jamfile.v2, but the syntax of those .v2 files is really weird, so I don't get what's happening afterwards.

Quoted 6 lines
Quoted 3 lines

Second, why are you introducing another BR2_PACKAGE_ICU conditional, even if there's already one ?

Because there was already a BR2_PACKAGE_BOOST_LOCALE conditional and it seems strange to set boost.locale.icu if locale is not enabled. But I can move it if you think it's better.

I think it would be good to understand the interaction with --without-icu to have a clean solution.

Quoted 6 lines
Quoted 3 lines

Third, what is the problem with libboost_locale linking with icu if found in the staging directory ?

Because, if it links with icu, boost will also build chrono and thread. To avoid always selecting these two libraries, I sent a patch to select them only if BR2_PACKAGE_ICU is set (see http://patchwork.ozlabs.org/patch/943753).

Indeed, boost_locale will build boost_thread if ICU is enabled:

        if $(found-icu)
        {
            ICU_SOURCES = 
                boundary
                codecvt
                collator
                conversion
                date_time
                formatter
                icu_backend
                numeric
                time_zone
                ;
            
            result += <source>icu/$(ICU_SOURCES).cpp 
                      <library>../../thread/build//boost_thread 
                      ;
        }

However, I don't see this happening for chrono.

Quoted 4 lines

My patch won't always work if boost links with icu when BR2_PACKAGE_ICU is not set (for example if the user changes his configuration between two builds). Perhaps, I should sent a patch serie with these two patches to better reflect the dependencies between them?

If patches have dependencies/interactions, then yes sending them as a series makes it clear they are related.

However, I still don't see the relation here. We indeed recommend in Buildroot to explicitly enable/disable features using configuration options when possible, mainly to avoid target packages incorrectly detecting some host library and trying to use it. So I'm still confused by what this patch is *fixing*. That it makes things more correct is OK, but that it is fixing something, I'm not sure.

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
#4 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

In reply to Fabrice Fontaine

Hello Fabrice,

Quoted 9 lines · On Fri, 13 Jul 2018 19:42:47 +0200 Fabrice Fontaine…

boost doesn't take into account --without-icu flag and links libboost_locale with icu if it founds it in staging directory

So use boost.locale.icu to fix this issue

---
 package/boost/boost.mk | 6 ++++++
 1 file changed, 6 insertions(+)

This patch is still pending in patchwork. Is it still needed ? You send a number of Boost fixes since then, and the last Boost build errors I can see at http://autobuild.buildroot.net/?reason=boost% are:

- Download failure due to DNS resolution problem (late March)

- Internal compiler error on Xtensa, mips64, ARC (dating back from January/February)

Could you check whether your patch would still be needed or not ?

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
#5 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Hello Thomas,

Le dim. 7 avr. 2019 ? 22:25, Thomas Petazzoni
<[email protected]> a ?crit :

Quoted 20 lines

Hello Fabrice,

Quoted 9 lines · On Fri, 13 Jul 2018 19:42:47 +0200 Fabrice Fontaine…

boost doesn't take into account --without-icu flag and links libboost_locale with icu if it founds it in staging directory

So use boost.locale.icu to fix this issue

---
 package/boost/boost.mk | 6 ++++++
 1 file changed, 6 insertions(+)

This patch is still pending in patchwork. Is it still needed ? You send a number of Boost fixes since then, and the last Boost build errors I can see at http://autobuild.buildroot.net/?reason=boost% are:

Quoted 6 lines

- Download failure due to DNS resolution problem (late March)

- Internal compiler error on Xtensa, mips64, ARC (dating back from January/February)

Could you check whether your patch would still be needed or not ?

We can drop it, I'll set it as "Non applicable" in patchwork.

Quoted 8 lines

Thanks!

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

Best Regards,

Fabrice

#6 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

In reply to Thomas Petazzoni
Quoted 7 lines · Thomas Petazzoni

the last Boost build errors I
can see at http://autobuild.buildroot.net/?reason=boost% are:

- Download failure due to DNS resolution problem (late March)

- Internal compiler error on Xtensa, mips64, ARC (dating back from January/February)

I didn't see that. Will take a look at the ICE on xtensa.

Signature · 2 lines
Thanks.
-- Max
#7 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Quoted 11 lines · Max Filippov
Quoted 7 lines · Thomas Petazzoni

the last Boost build errors I
can see at http://autobuild.buildroot.net/?reason=boost% are:

- Download failure due to DNS resolution problem (late March)

- Internal compiler error on Xtensa, mips64, ARC (dating back from January/February)

I didn't see that. Will take a look at the ICE on xtensa.

Hmmm... Does not reproduce here, the build is successful. Puzzled.

Signature · 2 lines
Thanks.
-- Max
#8 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Hello Max,

Quoted 3 lines · On Sun, 7 Apr 2019 14:09:18 -0700 Max Filippov <[email protected]> wrote:
Quoted 1 line

I didn't see that. Will take a look at the ICE on xtensa.

Hmmm... Does not reproduce here, the build is successful. Puzzled.

Of all the failures in:

http://autobuild.buildroot.net/?reason=boost%&arch=xtensa

the internal compiler error happened only once. Did you try rebuilding with that exact configuration and Git commit ?

If you indeed reproduced with the same config and Git commit, then it can be:

1. Influence from the environment (i.e the build machine is different)
2. The build machine is flaky and causes random failures

If needed, we can always ask Richard Braun to try to reproduce the same build on his machine, in order to discriminate between (1) and (2).

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
#9 lore raw

PATCH 1/1 boost: correctly disable icu in locale if needed

Quoted 5 lines · Thomas Petazzoni
Quoted 2 lines · On Sun, 7 Apr 2019 14:09:18 -0700 Max Filippov <[email protected]> wrote:
Quoted 1 line

I didn't see that. Will take a look at the ICE on xtensa.

Quoted 8 lines
Quoted 1 line

Hmmm... Does not reproduce here, the build is successful. Puzzled.

Of all the failures in:

http://autobuild.buildroot.net/?reason=boost%&arch=xtensa

the internal compiler error happened only once. Did you try rebuilding with that exact configuration and Git commit ?

Yes, I tried exact configuration and exact git commit.

Quoted 8 lines

If you indeed reproduced with the same config and Git commit, then it can be:

1. Influence from the environment (i.e the build machine is different)
2. The build machine is flaky and causes random failures

If needed, we can always ask Richard Braun to try to reproduce the same build on his machine, in order to discriminate between (1) and (2).

Yeah, I've also noticed that other ICEs were reported by the same build machine.

Signature · 2 lines
Thanks.
-- Max