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
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
