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).
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.
Yes, but I've just checked fedora again - they do build against
popt, but all they pass to CXX is their generic optflags (i.e. not
set within the specfile for this package) and
-D_FILE_OFFSET_BITS=64.
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?
Yes, I installed icu4c-61_1 at 23:26 and got the failure some time
later. With gptfdisk-1.0.3-convenience-1.patch.
I'm using icu4c-60_2, but it's been working for me since 2015.
Retrying:
ken@plexi /tmp $tar -xf /sources/gptfdisk-1.0.3.tar.gz
ken@plexi /tmp $cd gptfdisk-1.0.3/
ken@plexi /tmp/gptfdisk-1.0.3 $cat /sources/gptfdisk-1.0.3-convenience-1.patch
| patch -p1
patching file Makefile
ken@plexi /tmp/gptfdisk-1.0.3 $make ICU=1 POPT=1
g++ -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o crc32.o crc32.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o support.o support.cc
support.cc: In function ‘uint64_t GetNumber(uint64_t, uint64_t, uint64_t, const
string&)’:
support.cc:80:46: warning: format ‘%lld’ expects argument of type ‘long long
int*’, but argument 3 has type ‘uint64_t* {aka long unsigned int*}’ [-Wformat=]
num = sscanf(line, "%lld", &response);
~~~~~~~~~^
g++ -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o guid.o guid.cc
g++ -Wall -D_FILE_OFFSET_BITS=64 -DUSE_UTF16 -c -o gptpart.o gptpart.cc
In file included from gptpart.h:22:0,
from gptpart.cc:27:
parttypes.h:59:4: error: ‘UnicodeString’ does not name a type; did you mean
‘ReadString’?
UnicodeString UTypeName(void) const;
^~~~~~~~~~~~~
ReadString
(etc).
This is a new build, using LFS from 16th April (r11402) except with
linux-4.16.2, and BLFS r20092 from 17th April.
Hmm, OK. I'll try build in a fresh build tomorrow. Neither icu or
popt need any dependencies.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
