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 crc32.o
crc32.cc
g++ -O2 -march=native -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o mbr.o
mbr.cc
In file included from gptpart.h:22:0,
from mbr.h:8,
from mbr.cc:21:
parttypes.h:59:4: error: 'UnicodeString' does not name a type; did you mean
'ReadString'?
UnicodeString UTypeName(void) const;
^~~~~~~~~~~~~
ReadString
In file included from mbr.h:8:0,
from mbr.cc:21:
gptpart.h:62:7: error: 'UnicodeString' does not name a type; did you mean
'ReadString'?
UnicodeString GetUTypeName(void);
^~~~~~~~~~~~~
ReadString
gptpart.h:69:7: error: 'UnicodeString' does not name a type; did you mean
'ReadString'?
UnicodeString GetDescription(void);
^~~~~~~~~~~~~
ReadString
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).
I don't have any unicode partition names and I guess I don't need
either icu or popt, so I'll just mention this here and simplify my
build by not passing ICU=1.
I wrote that patch for convenience. It makes the build simpler.
'make ICU=1 POPT=1' works fine for me.
ICU=1 is used to put -DUSE_UTF16 in the g++ command line. For
parttypes.h, that define causes parttypes.h to include
<unicode/ustream.h>. Are you sure you have icu installed? Did you use
the patch?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
