On 20/04/2018 16:40, Bruce Dubbs wrote: > On 04/20/2018 02:28 AM, Pierre Labastie wrote: >> On 20/04/2018 08:24, Bruce Dubbs wrote: >>> On 04/19/2018 03:38 PM, Ken Moffat wrote: >>>> On Wed, Apr 18, 2018 at 09:08:34PM -0500, Bruce Dubbs wrote: >>>>> On 04/18/2018 07:25 PM, Ken Moffat wrote: >>>>>> I don't build gptfdisk on some of my machines, so I didn't notice >>>>>> this until now. Building gptfdisk with 'make ICU=1 POPT=1' fails: >>>>>> >>>>>> g++ -O2 -march=native -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o >>>>>> mbr.o mbr.cc >>>> [...] >>>>>> gptpart.h:84:26: error: 'UnicodeString' does not name a type; did you >>>>>> mean >>>>>> 'ReadString'? >>>>>> void SetName(const UnicodeString & theName); >>>>>> ^~~~~~~~~~~~~ >>>>>> ReadString >>>>>> make: *** [<builtin>: mbr.o] Error 1 >>>>>> >>>>>> If I don't pass ICU=1 it builds. >>>>>> >>>>>> Looking at fedora, arch, gentoo, debian (at least fedora and debian >>>>>> seem to call it gdisk) I see nothing like the patch we are carrying, >>>>>> they just build it as upstream designed (although there seem to be >>>>>> fixes for ncursesw5 in gentoo and debian). >>>>>> >> >> From the README file for gptfdisk: >> " The ICU library (http://site.icu-project.org), which provides support for >> Unicode partition names, is optional on all platforms except Windows, on >> which it's not supported. Using this library was required to get proper >> UTF-16 partition name support in GPT fdisk versions prior to 0.8.9, but >> as of that version it should not longer be required." >> >> >>>>> I wrote that patch for convenience. It makes the build simpler. >>>>> 'make ICU=1 POPT=1' works fine for me. >> >> Not for me (fresh LFS build, icu_61.1): I get the same error as Ken. >> Actually, the gptfdisk sources now provide unicode conversion (if USE_UTF16 >> is >> *not* defined), and does not use icu anymore. >> >> I'll regenerate a patch and change the book instructions. > > I still can't duplicate the failure. The question is why we get different > results. Within the gptfdisk expanded tarball, > > g++ -O2 -march=native -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o mbr.o > mbr.cc > > fails for you. It does not fail for me. > > mbr.cc includes mbr.h which includes gptpart.h which includes parttypes.h. > > The definition of USE_UTF16 is used in two files, gptpart.h and parttypes.h. > > parttypes.h has: > > #ifdef USE_UTF16 > #include <unicode/ustream.h> > #else > #define UnicodeString string > #endif > > So <unicode/ustream.h> should define UnicodeString if USE_UTF16 is defined. > > Actually diving down some more <unicode/ustream.h> includes unicode/unistr.h > > This last header file defines a class: > > class U_COMMON_API UnicodeString : public Replaceable {...} > > which is used throughout the unicode header files. > > I tried: > > g++ -O2 -march=native -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -E -o mbr.i > mbr.cc > > When I do that, I get a very large file: 33581 lines, but at lines > 33066-33068 I have: > > void SetName(const string & theName); > > void SetName(const UnicodeString & theName); > > and that builds for me with g++ -S -o mbr.s mbr.i > > the output is assembly without any references to 'Unicode' > > http://anduin.linuxfromscratch.org/~bdubbs/files/mbr.i > > ------- > > So where are we different? About the only thing I can think of is that we > have different files in /usr/include/unicode. I installed them from icu. > > Sun Feb 18 11:55:34 CST 2018 /usr/src/icu/icu4c-60_2-src.tgz >
Hmm, have you tried icu-61.1? I think the problem is that now icu types need a namespace qualifier. We have had an issue for that in libreoffice too. But since icu is not needed for gptfdisk (since version 0.8.3), I think removing the switch is a better solution than passing CPPFLAGS='-DU_USE_ICU_NAMESPACE=1' Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
