Opened 9 years ago

Last modified 6 years ago

#9685 assigned Feature Requests

Boost.Locale does not link against static ICU on Windows

Reported by: stathis@… Owned by: Artyom Beilis
Milestone: To Be Determined Component: locale
Version: Boost 1.55.0 Severity: Cosmetic
Keywords: Cc:

Description

There seems to be no support for linking against the static ICU libraries (sicuXX.lib) on Windows. Is there any plans to add it (?), or is there an inherent problem?

I would be willing to write that support if there is a bit of guidance on how to go about it in the Jamfile.

Change History (9)

comment:1 by anonymous, 7 years ago

Is there any chance this may be implemented? It would be very helpful if Boost could be build against a static ICU. Any chance of the Boost.Locale maintainer providing a response to this?

comment:2 by anonymous, 7 years ago

Hello, I've also encountered this bug with Boost 1.59.0.

comment:3 by federico-strati@…, 7 years ago

I'd like to subscribe to such a ticket, it would be very helpful if Boost could be built against a static ICU. I guess changes will involve also boost regex and not only boost locale.

Federico Strati <federico-strati@…>

comment:4 by anonymous, 7 years ago

Please please support this, we cannot use Boost.Locale until static linking support is added.

comment:5 by Artyom Beilis, 7 years ago

Severity: Not ApplicableCosmetic
Status: newassigned

From what I remember linking against static ICU was very problematic - up to level of linking but not getting any data or so. Also last time I had checked there was no option of building ICU on windows statically without cygwin.

I don't see any reason why not to link dynamically with ICU (but that is a different story...)

I don't recommend using ICU using static linking in general and if you want all your app to be liked statically just don't use ICU backend.

I accepted this ticked but I don't know when I'll get to it. If you want try to create high quality Boost.Build patch to support it so I can get it into the tree as is.

comment:6 by stathis@…, 7 years ago

I filled this years ago and since then I have (from time to time) been investigating on how to fix it. I even had to dig through the Boost Jam undocumented features ...

For anyone interested I have precompiled Boost with static ICU linkage (static runtime, that is /MT) and it is available here: http://www.npcglib.org/~stathis/blog/precompiled-boost/

In the page I provide a patch to the Jamfiles of Boost.Locale and Boost.Regex and my boost build script, as well as instructions on how to build the libs again for anyone wanting to do so.

I built the libs for most MSVC compilers (MSVC2008-2015), as to this date there is no workaround for this problem. I don't consider this a "Cosmetic" problem of the Boost libraries. Furthermore, is this "limitation" mentioned anywhere? The user is left to believe he built a static Boost library, but when linking his code against upstream libs, he gets a dependency to the ICU dlls.

I have a patch in my page and anyone wishing to fix it upstream feel free to have a look, however note that I also patch ICU to link against static runtime which I use (so everything is compatible). This is not the default for ICU (/MD is).

I will keep building my own Boost and I guess the maintainer can decide if this is worth fixing or not.

comment:7 by Artyom Beilis, 7 years ago

Note linking ICU against static runtime is very bad way to do things.

Also you can see how many options you have: icu-dynamic (default), icu-static with dynamic runtime, icu-static with static runtime.

I suggest provide relevant patches - that does not ruin anything existing I'll try to do it. Currently Boost.Build does not really cooperate well with such a changes.

If you manage to provide a good patch and instructions how to build ICU statically (that I couldn't find on ICU web site) I'll integrate it.

Bottom line. Distributing dll isn't the end of the world I can't understand why not to use them.

Actually linking all statically is considered "wrong way" to do things.

comment:8 by stathis@…, 7 years ago

Could you please explain why using static runtime is "very bad way to do things" ? what are the pros and cons. static linking works well if one is systematic and doesn't mix runtimes up.

I have been precompiling ICU for a few years too with static runtimes, look here: http://www.npcglib.org/~stathis/blog/precompiled-icu/

there is instructions, patches, libraries, etc. It is just a simple command line to build ICU statically. If you want it, I will fetch it here.

Regarding ICU static with dynamic (/MD) vs static (/MT) runtime, it is easy to build either. /MD is the default ICU way and my script + patch builds with /MT, which is not the standard way.

I know it's very difficult for you to include the changes, given they are windows-specific and the dependencies are custom build. This can't go upstream, at least for now.

I agree with you dlls aren't bad at all, but static binaries are also widely used and they work very well. No need for deployment and installers. I have no intention of starting a discussion about the correctness of static linking; unless there is a strong point that should be made, please tell me.

I look at it differently: since there is a real use case and it is technically feasible, I tried to provide it (actually I did it for myself and since it's so tedious, I decided to share it with the world).

I think if you decide not to work on this (since I guess you're volunteering your time) given the abovementioned caveats, the best would be to clarify that linking against ICU always links in the dynamic ICU and not the static in the Boost docs. In contrast, if you want any other details to rectify this, feel free to let me know, I will help.

comment:9 by Rado, 6 years ago

Sorry, to intervene, but I recommend at least this requirement to be visible on the Boost.Locale documentation. In any case, +1 for the static runtime.

Note: See TracTickets for help on using tickets.