gptfdisk-general — General discussions of GPT fdisk

Re: [Gptfdisk-general] verify disk should warn if gpt table ends before end of disk

[Christoph B. <sou...@ma...>]

Martin Castillo wrote...

> I transitioned to a new, bigger storage medium by simply dd(1)ing it.

To avoid your situation, I'd rather gdisk's partition replication
feature and then either dd the data by partition, or use the applicable
tooling. The latter may be done online and can be a lot faster (almost
empty LVM physical volume), no difference but more robust (mdadm), or a
lot slower (ZFS). This also avoids a lot of trouble if UUIDs exist twice.

Still, I consider your report legitimate as this situation may be caused
be other means.

> When I tried to increase the last partition, it was not possible. No free
> space at the end was shown.
>
> "verify disk" did not mention any problems around that.
> I write this mail because I think it would be useful, if this condition
> would be mentioned.

Indeed.

Today, I came across the same situation, using the sfdisk from the
coreutils, though. The report is in the Debian bug tracker at
https://bugs.debian.org/1096072

> Using the expert command e fixes this. 'v' could recommend that.

Thanks for that one, I feared I had to poke the partition table using
sfdisk scripts.

    Christoph

[Gptfdisk-general] verify disk should warn if gpt table ends before end of disk

[Martin C. <cas...@un...>]

Hi,

I transitioned to a new, bigger storage medium by simply dd(1)ing it.
When I tried to increase the last partition, it was not possible. No 
free space at the end was shown.

"verify disk" did not mention any problems around that.
I write this mail because I think it would be useful, if this condition 
would be mentioned.

Using the expert command e fixes this. 'v' could recommend that.

You can check that with the attached sparse disk image.

Martin Castillo

$ gdisk disk.iso
GPT fdisk (gdisk) version 1.0.10

NOTE: Write test failed with error number 13. It will be impossible to save
changes to this disk's partition table!

Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): x

Expert command (? for help): v

Caution: Partition 3 doesn't end on a 2048-sector boundary. This may
result in problems with some disk encryption tools.

No problems found. 2014 free sectors (1007.0 KiB) available in 1
segments, the largest of which is 2014 (1007.0 KiB) in size.

Expert command (? for help): k
Currently, backup partition table begins at sector 937703055 and ends at
sector 937703086
Enter new starting location (625142415 to 937703055; default is 
937703055; 1 to abort):
Aborting change!

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): v

Caution: Partition 3 doesn't end on a 2048-sector boundary. This may
result in problems with some disk encryption tools.

No problems found. 312562654 free sectors (149.0 GiB) available in 2
segments, the largest of which is 312560640 (149.0 GiB) in size.

Expert command (? for help):

Re: [Gptfdisk-general] misreads NetBSD as FreeBSD

[Rod S. <rod...@ro...>]

On 8/3/23 19:58, David Chmelik wrote:
> On 8/3/23 6:59 AM, Rod Smith wrote:
>> On 8/3/23 04:31, dch...@gm... wrote:
>>> Lately I also use gdisk, etc.  Unlike fdisk, gdisk misreads my NetBSD 
>>> partition as a FreeBSD one.
>>
>> There's a lot you haven't stated that's likely relevant. For instance, 
>> is the disk currently MBR or GPT? If the latter, was it once MBR, but 
>> was converted to GPT; and if so, by what program? Is the fdisk you're 
>> using from util-linux or based on libparted? What column(s) of output 
>> are you reading in both fdisk and gdisk? Because I don't know the 
>> answers to these questions, I can't give you an answer about what's 
>> going on; however, I can say this....
> I guess everything's fine then.  The solid state drive (SSD/M2/NVME) is 
> currently MBR and I used fdisk from util-linux but also used it on *BSD 
> UNIX (which works differently).

Yes, if the disk is MBR, then what you're seeing is the expected 
behavior, caused by the fact that there is (AFAIK) no direct GPT 
correlate to the MBR 0xA9 type code. GPT fdisk does the same thing with 
a number of type codes for NTFS and several FAT variants; they all get 
compressed down to GPT fdisk's 0700.

> Thanks.  I'd more likely reinstall everything on that drive if I had a 
> reason to convert to GPT, but I aliased fdisk to gdisk

I STRONGLY recommend against doing this. Although I modeled gdisk's user 
interface on that for Linux fdisk, as this exchange has shown, gdisk is 
not completely compatible. I'd be especially worried about scripts that 
might try to parse fdisk's output, get it wrong, and do something 
disastrous as a result. Also, if you launch gdisk on an MBR disk and 
accidentally type "w", the result will be that the MBR partition table 
will be replaced by a GPT, which could cause serious problems.

> because when I 
> got two new 16TB WD/HGST hard disc drives and used fdisk on them, it 
> seemed they were broken, and I didn't want to accidentally try a third.
> Likely it wasn't fdisk causing it rather than just some decrease in 
> quality and a chance I got two bad ones.  However now I type fdisk 
> (gdisk) or /sbin/fdisk (the real fdisk).

Disk partitioning tools, including fdisk, gdisk, and parted, are 
unlikely to physically damage a disk. The worst they might do is to 
damage the partition table, or perhaps the contents of a partition. This 
is bad enough, of course, but it won't send a disk to a trash can; the 
disk should still be usable, after restoring it from a backup or using 
low-level recovery tools like PhotoRec.

That said, if you distrust util-linux's fdisk, you could try replacing 
it with GNU fdisk (https://directory.fsf.org/wiki/Fdisk), which is based 
on libparted (the same library that underlies parted and GParted, among 
others). It's been a while since I've done anything with it, and I'm not 
even sure what Linux package(s) might hold it in common distributions; 
but it has a user interface that's similar to that of util-linux's 
fdisk, but completely different internals.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

Re: [Gptfdisk-general] misreads NetBSD as FreeBSD

[David C. <dav...@gm...>]

On 8/3/23 6:59 AM, Rod Smith wrote:
> On 8/3/23 04:31, dch...@gm... wrote:
>> Lately I also use gdisk, etc.  Unlike fdisk, gdisk misreads my NetBSD 
>> partition as a FreeBSD one.
>
> There's a lot you haven't stated that's likely relevant. For instance, 
> is the disk currently MBR or GPT? If the latter, was it once MBR, but 
> was converted to GPT; and if so, by what program? Is the fdisk you're 
> using from util-linux or based on libparted? What column(s) of output 
> are you reading in both fdisk and gdisk? Because I don't know the 
> answers to these questions, I can't give you an answer about what's 
> going on; however, I can say this....
I guess everything's fine then.  The solid state drive (SSD/M2/NVME) is 
currently MBR and I used fdisk from util-linux but also used it on *BSD 
UNIX (which works differently).

> On an MBR disk, FreeBSD and NetBSD can use the same partition type 
> code (0xA5), although NetBSD also has its own code (0xA9)[1]; however, 
> on a GPT disk, the two OSes each have their own set of unique 
> GUIDs[2]. That said, the MBR 0xA5 and 0xA9 codes are both most often 
> used for a BSD "disklabel," which holds sub-partitions, similar to an 
> MBR extended partition. Among the GPT type codes, AFAIK only FreeBSD's 
> set includes an explicit "disklabel" partition 
> (516E7CB4-6ECF-11D6-8FF8-00022D09712B); AFAIK, there is no NetBSD 
> equivalent to this in GPT. Because GPT fdisk does an automatic 
> conversion from MBR to GPT, when you read an MBR disk with a NetBSD 
> 0xA5 partition with GPT fdisk, that partition will show up as a 
> FreeBSD partition, since 0xA5 is more strongly associated with FreeBSD 
> than with NetBSD. Also, in GPT fdisk, most a9xx codes get converted to 
> unique NetBSD codes; however, a900 (or 0xA9, when reading an MBR disk) 
> gets converted to 516E7CB4-6ECF-11D6-8FF8-00022D09712B, the FreeBSD 
> disklabel code, since the GPT type code list on Wikipedia[2] doesn't 
> specify a unique NetBSD disklabel type code, and I don't see anything 
> labeled as a "disklabel" code in the relevant NetBSD source code 
> file[3], either.
I specficially set the NetBSD partition to a9 but saw gdisk list the 
*BSD partitions (except DragonFlyBSD) as A500.

> It's possible that what you're seeing is a result of this, either on 
> an MBR disk or a disk converted to GPT from MBR. An fdisk that's based 
> on libparted, by contrast, would read the contents of the partition 
> and present a filesystem type rather than present the type code 
> itself; and util-linux fdisk would present the type code for an MBR 
> partition, rather than try to convert it to GPT, as GPT fdisk does.
>
> If the disk was partitioned initially as a GPT disk, then I'd expect 
> that NetBSD's partitions should use native NetBSD type codes, which 
> GPT fdisk presents as a901 through a906. If one of the partitions hold 
> an old-style BSD "disklabel," then AFAIK there's no NetBSD-specific 
> GPT type code for that, so the best choice for the GPT partition type 
> code would be 516E7CB4-6ECF-11D6-8FF8-00022D09712B, which is 
> officially a FreeBSD type code, and is presented as such by both GPT 
> fdisk and util-linux fdisk. (I don't know offhand how a 
> libparted-based fdisk presents such a partition, if it's created in 
> NetBSD.)
>
> One more factor: The GPT fdisk output includes the partition name. If 
> the partition is created in gdisk, then gdisk sets this name to a 
> description that's tied to the type code, by default. For instance:
>
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048        30296063   14.4 GiB    A500  FreeBSD 
> disklabel
>
> (That's two lines; the second one will likely wrap in this e-mail.)
>
> If the type code is changed outside of GPT fdisk, the name may not be 
> updated. For instance, taking the above disk and changing the type 
> code in util-linux's fdisk to fdisk's 79 ("NetBSD FFS") results in it 
> looking like this in GPT fdisk:
>
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048        30296063   14.4 GiB    A902  FreeBSD 
> disklabel
>
> Note that the type code has changed from A500 to A902, but the 
> partition's name remains "FreeBSD disklabel," although that's no 
> longer accurate. This is another strong possibility for what you're 
> seeing. If so, the solution is simply to update the partition's name 
> in GPT fdisk to something appropriate. This can be done with the "c" 
> main-menu option in gdisk. Note that util-linux fdisk does not present 
> the partition name in its main summary, although the information is 
> available via the "i" main-menu option.
>
> [1] https://www.win.tue.nl/~aeb/partitions/partition_types-1.html
> [2] https://en.wikipedia.org/wiki/GUID_Partition_Table
> [3] 
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/disklabel_gpt.h?rev=1.15&content-type=text/x-cvsweb-markup&f=h&only_with_tag=MAIN
Thanks.  I'd more likely reinstall everything on that drive if I had a 
reason to convert to GPT, but I aliased fdisk to gdisk because when I 
got two new 16TB WD/HGST hard disc drives and used fdisk on them, it 
seemed they were broken, and I didn't want to accidentally try a third.  
Likely it wasn't fdisk causing it rather than just some decrease in 
quality and a chance I got two bad ones.  However now I type fdisk 
(gdisk) or /sbin/fdisk (the real fdisk).

Re: [Gptfdisk-general] misreads NetBSD as FreeBSD

[Rod S. <rod...@ro...>]

On 8/3/23 04:31, dch...@gm... wrote:
> Lately I also use gdisk, etc.  Unlike fdisk, gdisk misreads my NetBSD 
> partition as a FreeBSD one.

There's a lot you haven't stated that's likely relevant. For instance, 
is the disk currently MBR or GPT? If the latter, was it once MBR, but 
was converted to GPT; and if so, by what program? Is the fdisk you're 
using from util-linux or based on libparted? What column(s) of output 
are you reading in both fdisk and gdisk? Because I don't know the 
answers to these questions, I can't give you an answer about what's 
going on; however, I can say this....

On an MBR disk, FreeBSD and NetBSD can use the same partition type code 
(0xA5), although NetBSD also has its own code (0xA9)[1]; however, on a 
GPT disk, the two OSes each have their own set of unique GUIDs[2]. That 
said, the MBR 0xA5 and 0xA9 codes are both most often used for a BSD 
"disklabel," which holds sub-partitions, similar to an MBR extended 
partition. Among the GPT type codes, AFAIK only FreeBSD's set includes 
an explicit "disklabel" partition 
(516E7CB4-6ECF-11D6-8FF8-00022D09712B); AFAIK, there is no NetBSD 
equivalent to this in GPT. Because GPT fdisk does an automatic 
conversion from MBR to GPT, when you read an MBR disk with a NetBSD 0xA5 
partition with GPT fdisk, that partition will show up as a FreeBSD 
partition, since 0xA5 is more strongly associated with FreeBSD than with 
NetBSD. Also, in GPT fdisk, most a9xx codes get converted to unique 
NetBSD codes; however, a900 (or 0xA9, when reading an MBR disk) gets 
converted to 516E7CB4-6ECF-11D6-8FF8-00022D09712B, the FreeBSD disklabel 
code, since the GPT type code list on Wikipedia[2] doesn't specify a 
unique NetBSD disklabel type code, and I don't see anything labeled as a 
"disklabel" code in the relevant NetBSD source code file[3], either.

It's possible that what you're seeing is a result of this, either on an 
MBR disk or a disk converted to GPT from MBR. An fdisk that's based on 
libparted, by contrast, would read the contents of the partition and 
present a filesystem type rather than present the type code itself; and 
util-linux fdisk would present the type code for an MBR partition, 
rather than try to convert it to GPT, as GPT fdisk does.

If the disk was partitioned initially as a GPT disk, then I'd expect 
that NetBSD's partitions should use native NetBSD type codes, which GPT 
fdisk presents as a901 through a906. If one of the partitions hold an 
old-style BSD "disklabel," then AFAIK there's no NetBSD-specific GPT 
type code for that, so the best choice for the GPT partition type code 
would be 516E7CB4-6ECF-11D6-8FF8-00022D09712B, which is officially a 
FreeBSD type code, and is presented as such by both GPT fdisk and 
util-linux fdisk. (I don't know offhand how a libparted-based fdisk 
presents such a partition, if it's created in NetBSD.)

One more factor: The GPT fdisk output includes the partition name. If 
the partition is created in gdisk, then gdisk sets this name to a 
description that's tied to the type code, by default. For instance:

Number  Start (sector)    End (sector)  Size       Code  Name
    1            2048        30296063   14.4 GiB    A500  FreeBSD disklabel

(That's two lines; the second one will likely wrap in this e-mail.)

If the type code is changed outside of GPT fdisk, the name may not be 
updated. For instance, taking the above disk and changing the type code 
in util-linux's fdisk to fdisk's 79 ("NetBSD FFS") results in it looking 
like this in GPT fdisk:

Number  Start (sector)    End (sector)  Size       Code  Name
    1            2048        30296063   14.4 GiB    A902  FreeBSD disklabel

Note that the type code has changed from A500 to A902, but the 
partition's name remains "FreeBSD disklabel," although that's no longer 
accurate. This is another strong possibility for what you're seeing. If 
so, the solution is simply to update the partition's name in GPT fdisk 
to something appropriate. This can be done with the "c" main-menu option 
in gdisk. Note that util-linux fdisk does not present the partition name 
in its main summary, although the information is available via the "i" 
main-menu option.

[1] https://www.win.tue.nl/~aeb/partitions/partition_types-1.html
[2] https://en.wikipedia.org/wiki/GUID_Partition_Table
[3] 
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/disklabel_gpt.h?rev=1.15&content-type=text/x-cvsweb-markup&f=h&only_with_tag=MAIN

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] misreads NetBSD as FreeBSD

[<dch...@gm...>]

Lately I also use gdisk, etc.  Unlike fdisk, gdisk misreads my NetBSD 
partition as a FreeBSD one.

[Gptfdisk-general] Correct printw specifier patch

[Nikolaos C. <nch...@gm...>]

Hello,

I noticed some warnings when compiling gdisk; the issue was that the
long long format was used to print unsigned 64-bit integers. This
warning is important because passing the wrong type to the
printf-family can invoke undefined behavior.

The patch I'm submitting should take care of this.

Regards,
Nikolaos Chatzikonstantinou

[Gptfdisk-general] Recent popt change seems to cause sgdisk segfault

[Adrian V. <adr...@gm...>]

Hello,

I'm running into a segmentation fault in `sgdisk --version`, that
seems to originate from the strdup call introduced in commit
5d5e76d369a412bfb3d2cebb5fc0a7509cef878d. There's a backtrace in the
downstream bug report[1], if you'd like to see it (though it's not
very interesting, so I won't bother to copy it here)

Here's my theory of what's going on:
- sgdisk parses the `--version` option & prints its version. Then
continues running
- sgdisk calls `poptGetArg`. In this situation, `poptGetArg` probably
returns NULL, since there's no  arguments on the command line
- Prior to 5d5e76d, this would have been OK (you check immediately
afterward & exit cleanly if `poptGetArg` returns NULL). However, now,
you end up calling `strdup(NULL)`, which leads to a segfault

I haven't looked too closely at your codebase, and I'm not very
familiar with popt's behavior, so I'm not certain that this is what's
happening, but it seems to make sense as a theory. Let me know if
there's anything I can do to assist you with fixing this bug

Thank you,
Adrian Vovk

[1]: https://gitlab.com/carbonOS/build-meta/-/issues/104

[Gptfdisk-general] sgdisk off-by-one error with negative start positions

[Parke <par...@gm...>]

Hello,

With sgdisk version 1.0.8 on Ubuntu 22.04, I am observing an
(apparent) off-by-one error with commands that use negative start
positions.

I don't see this issue mentioned in the NEWS file at SourceForge, so I
am guessing it may still exist.

Consider the following two commands, run on a GPT disk with no partitions:

sgdisk /dev/sdb --new=4:-20m --typecode=4:ef00
sgdisk /dev/sdb --new=3:-500m --typecode=3:8300

Information: Moved requested sector from 29990256 to 29988864 in
order to align on 2048-sector boundaries.

Information: Moved requested sector from 28964863 to 28962816 in
order to align on 2048-sector boundaries.

Then run gdisk -l /dev/sdb:

[snip]
Number  Start (sector)    End (sector)  Size       Code  Name
   3        28962816        29988863   501.0 MiB   8300  [snip]
   4        29988864        30031216   20.7 MiB    EF00  [snip]

Note that partition 3 was requested to be -500M, but its actual size
is (exactly) 501MiB.

Partition 4 does not end on a 2048-sector boundary.  Therefore, it is
understandable that partition 4 is larger than the requested -20M.

However, partition 3 does end on a 2048-sector boundary.  Therefore,
partition 3 could be exactly 500MiB.  Instead, it is 501MiB.

I suspect what is happening is exactly what is described in sgdisk's manpage.

    You can specify loca‐
    tions relative to the start or  end  of  the  specified  default
    range  by preceding the number by a '+' or '-' symbol, as in +2G
    to specify a point 2GiB after the default start sector, or -200M
    to  specify  a  point 200MiB before the last available sector.

If the last available sector is immediately before a 2048-sector
boundary, then rewinding 200M will place you one sector before another
2048-sector boundary.  sgdisk will then rewind further to the next
2048-sector boundary.  This adds an extra megabyte to the size of the
partition.

To create a 200M partition when -200M is specified, I believe the
offset should instead be calculated from the sector **immediately
after** the last available sector.

Cheers,

Parke

Re: [Gptfdisk-general] [PATCH] Fix uuid/uuid.h detection with util-linux 2.38

[Rod S. <rod...@ro...>]

On 4/16/22 01:44, Evangelos Foutras via Gptfdisk-general wrote:
> util-linux commit 10f5f79485964ab52272ebe79c3b0047b1f84d82 changed the
> header guard in uuid/uuid.h from _UUID_UUID_H to _UL_LIBUUID_UUID_H as
> the former was too generic; fix guid.cc to also look for the new name.

Thanks for the patch. I've made this change to the current git version
of GPT fdisk.

> ---
>  guid.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/guid.cc b/guid.cc
> index 1e73ab7..d3e4fd5 100644
> --- a/guid.cc
> +++ b/guid.cc
> @@ -141,7 +141,7 @@ void GUIDData::Zero(void) {
>  void GUIDData::Randomize(void) {
>     int i, uuidGenerated = 0;
>  
> -#ifdef _UUID_UUID_H
> +#if defined (_UUID_UUID_H) || defined (_UL_LIBUUID_UUID_H)
>     uuid_generate(uuidData);
>     ReverseBytes(&uuidData[0], 4);
>     ReverseBytes(&uuidData[4], 2);
> 
> 
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] [PATCH] Fix uuid/uuid.h detection with util-linux 2.38

[Evangelos F. <eva...@fo...>]

util-linux commit 10f5f79485964ab52272ebe79c3b0047b1f84d82 changed the
header guard in uuid/uuid.h from _UUID_UUID_H to _UL_LIBUUID_UUID_H as
the former was too generic; fix guid.cc to also look for the new name.
---
 guid.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guid.cc b/guid.cc
index 1e73ab7..d3e4fd5 100644
--- a/guid.cc
+++ b/guid.cc
@@ -141,7 +141,7 @@ void GUIDData::Zero(void) {
 void GUIDData::Randomize(void) {
    int i, uuidGenerated = 0;
 
-#ifdef _UUID_UUID_H
+#if defined (_UUID_UUID_H) || defined (_UL_LIBUUID_UUID_H)
    uuid_generate(uuidData);
    ReverseBytes(&uuidData[0], 4);
    ReverseBytes(&uuidData[4], 2);

Re: [Gptfdisk-general] problem when building vs popt master (7182e4618ad5a0186145fc2aa4a98c2229afdfa8, revno: 740)

[Rod S. <rod...@ro...>]

On 4/15/22 11:51, bal...@un... wrote:
> hello
> 
> this is actually more an headsup than a bug report
> 
> I just run the build of gptfdisk-1.0.9 (on linux) vs popt master (as per
> the subject) and got the following error from sgdisk at "make test":

Thanks for reporting this, and finding a fix! I've just committed your
fix to the GPT fdisk git repository.

>   ----8<----
>   [...]
>   **Testing sgdisk binary**
> 
>   Problem opening  for reading! Error is 2.
>   The specified file does not exist!
>   Warning! Unable to generate a proper UUID! Creating an improper one as a last
>   resort! Windows 7 may crash if you save this partition table!
>   Information: Creating fresh partition table; will override earlier problems!
>   Caution! Secondary header was placed beyond the disk's limits! Moving the
>   header, but other problems may occur!
>   Unable to open device '' for writing! Errno is 2! Aborting write!
>   **FAILED** sgdisk return 4 when creating partition table
>   make[1]: *** [Makefile:160: test] Error 1
>   make[1]: Leaving directory '/home/balducci/tmp/install-us-d/gptfdisk-1.0.9.d/gptfdisk-1.0.9'
>   ---->8----
> 
> Note that for gdisk all tests complete successfully
> 
> After some debugging, I seem to have clarified the situation.
> sgdisk (but not gdisk) uses popt to parse command line opts.
> In gptcl.cc the device filename is read from the command line  as:
>     ----8<----
>       device = (char*) poptGetArg(poptCon);
>     ---->8----
> 
> Note that poptGetArg returns its own allocated memory, not a copy of
> it:
>     ----8<----
>     const char * poptGetArg(poptContext con)
>     {
>         const char * ret = NULL;
>         if (con && con->leftovers != NULL && con->nextLeftover < con->numLeftovers)
>             ret = con->leftovers[con->nextLeftover++];
>         return ret;
>     }
>     ---->8----
> 
> Immediately after the poptGetArg call, gptcl.cc does:
>     ----8<----
>       poptResetContext(poptCon);
>     ---->8----
> 
> Now: in the latest commit to popt
> (7182e4618ad5a0186145fc2aa4a98c2229afdfa8, revno: 740) the
> poptResetContext function (in popt.c) *FREES* the leftovers (which it
> didn't until 740):
> 
>     ----8<----
>     ##> git diff a4afb898f7758160acda71d774c7d98d528da273 7182e4618ad5a0186145fc2aa4a98c2229afdfa8
>     diff --git a/src/popt.c b/src/popt.c
>     index 0521c8d..f3f26a3 100644
>     --- a/src/popt.c
>     +++ b/src/popt.c
>     @@ -216,6 +216,9 @@ void poptResetContext(poptContext con)
>          else
>             con->os->next = 0;
> 
>     +    for (i = 0; i < con->numLeftovers; i++) {
>     +        con->leftovers[i] = _free(con->leftovers[i]);
>     +    }
>          con->numLeftovers = 0;
>          con->nextLeftover = 0;
>          con->restLeftover = 0;
>     @@ -1534,7 +1537,7 @@ poptContext poptFreeContext(poptContext con)
>          con->numExecs = 0;
> 
>          for (i = 0; i < con->numLeftovers; i++) {
>     -        con->leftovers[i] = _free(&con->leftovers[i]);
>     +        con->leftovers[i] = _free(con->leftovers[i]);
>          }
>          con->leftovers = _free(con->leftovers);
>     ---->8----
> 
> The end result is that when sgdisk is linked vs latest popt (revno
> 740), the device variable in gptcl.cc does not point to valid memory
> after "poptResetContext(poptCon);" and causes the error reported above.
> 
> Note that this problem didn't exist before popt-740
> (7182e4618ad5a0186145fc2aa4a98c2229afdfa8) because for previous popt
> revisions the leftovers were not freed in poptResetContext.
> 
> As a matter of fact, this fixes everything for me and the tests
> complete successfully also for sgdisk:
> 
>     ----8<----
>      diff -c ./gptcl.cc.USE_STRDUP ./gptcl.cc
>     *** ./gptcl.cc.USE_STRDUP       Fri Apr 15 16:33:50 2022
>     --- ./gptcl.cc  Fri Apr 15 16:33:50 2022
>     ***************
>     *** 155,161 ****
>          } // while
> 
>          // Assume first non-option argument is the device filename....
>     !    device = (char*) poptGetArg(poptCon);
>          poptResetContext(poptCon);
> 
>          if (device != NULL) {
>     --- 155,161 ----
>          } // while
> 
>          // Assume first non-option argument is the device filename....
>     !    device = strdup((char*) poptGetArg(poptCon));
>          poptResetContext(poptCon);
> 
>          if (device != NULL) {
>     ---->8----
> 
> As I said, this is just to let you know the potential problem when
> sgdisk is linked vs popt>=740
> 
> I thank you very much for your excellent work
> 
> ciao
> -gabriele
> 
> 
> _______________________________________________
> Gptfdisk-general mailing list
> Gpt...@li...
> https://lists.sourceforge.net/lists/listinfo/gptfdisk-general


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] problem when building vs popt master (7182e4618ad5a0186145fc2aa4a98c2229afdfa8, revno: 740)

[<bal...@un...>]

hello

this is actually more an headsup than a bug report

I just run the build of gptfdisk-1.0.9 (on linux) vs popt master (as per
the subject) and got the following error from sgdisk at "make test":

  ----8<----
  [...]
  **Testing sgdisk binary**

  Problem opening  for reading! Error is 2.
  The specified file does not exist!
  Warning! Unable to generate a proper UUID! Creating an improper one as a last
  resort! Windows 7 may crash if you save this partition table!
  Information: Creating fresh partition table; will override earlier problems!
  Caution! Secondary header was placed beyond the disk's limits! Moving the
  header, but other problems may occur!
  Unable to open device '' for writing! Errno is 2! Aborting write!
  **FAILED** sgdisk return 4 when creating partition table
  make[1]: *** [Makefile:160: test] Error 1
  make[1]: Leaving directory '/home/balducci/tmp/install-us-d/gptfdisk-1.0.9.d/gptfdisk-1.0.9'
  ---->8----

Note that for gdisk all tests complete successfully

After some debugging, I seem to have clarified the situation.
sgdisk (but not gdisk) uses popt to parse command line opts.
In gptcl.cc the device filename is read from the command line  as:
    ----8<----
      device = (char*) poptGetArg(poptCon);
    ---->8----

Note that poptGetArg returns its own allocated memory, not a copy of
it:
    ----8<----
    const char * poptGetArg(poptContext con)
    {
        const char * ret = NULL;
        if (con && con->leftovers != NULL && con->nextLeftover < con->numLeftovers)
            ret = con->leftovers[con->nextLeftover++];
        return ret;
    }
    ---->8----

Immediately after the poptGetArg call, gptcl.cc does:
    ----8<----
      poptResetContext(poptCon);
    ---->8----

Now: in the latest commit to popt
(7182e4618ad5a0186145fc2aa4a98c2229afdfa8, revno: 740) the
poptResetContext function (in popt.c) *FREES* the leftovers (which it
didn't until 740):

    ----8<----
    ##> git diff a4afb898f7758160acda71d774c7d98d528da273 7182e4618ad5a0186145fc2aa4a98c2229afdfa8
    diff --git a/src/popt.c b/src/popt.c
    index 0521c8d..f3f26a3 100644
    --- a/src/popt.c
    +++ b/src/popt.c
    @@ -216,6 +216,9 @@ void poptResetContext(poptContext con)
         else
            con->os->next = 0;

    +    for (i = 0; i < con->numLeftovers; i++) {
    +        con->leftovers[i] = _free(con->leftovers[i]);
    +    }
         con->numLeftovers = 0;
         con->nextLeftover = 0;
         con->restLeftover = 0;
    @@ -1534,7 +1537,7 @@ poptContext poptFreeContext(poptContext con)
         con->numExecs = 0;

         for (i = 0; i < con->numLeftovers; i++) {
    -        con->leftovers[i] = _free(&con->leftovers[i]);
    +        con->leftovers[i] = _free(con->leftovers[i]);
         }
         con->leftovers = _free(con->leftovers);
    ---->8----

The end result is that when sgdisk is linked vs latest popt (revno
740), the device variable in gptcl.cc does not point to valid memory
after "poptResetContext(poptCon);" and causes the error reported above.

Note that this problem didn't exist before popt-740
(7182e4618ad5a0186145fc2aa4a98c2229afdfa8) because for previous popt
revisions the leftovers were not freed in poptResetContext.

As a matter of fact, this fixes everything for me and the tests
complete successfully also for sgdisk:

    ----8<----
     diff -c ./gptcl.cc.USE_STRDUP ./gptcl.cc
    *** ./gptcl.cc.USE_STRDUP       Fri Apr 15 16:33:50 2022
    --- ./gptcl.cc  Fri Apr 15 16:33:50 2022
    ***************
    *** 155,161 ****
         } // while

         // Assume first non-option argument is the device filename....
    !    device = (char*) poptGetArg(poptCon);
         poptResetContext(poptCon);

         if (device != NULL) {
    --- 155,161 ----
         } // while

         // Assume first non-option argument is the device filename....
    !    device = strdup((char*) poptGetArg(poptCon));
         poptResetContext(poptCon);

         if (device != NULL) {
    ---->8----

As I said, this is just to let you know the potential problem when
sgdisk is linked vs popt>=740

I thank you very much for your excellent work

ciao
-gabriele

Re: [Gptfdisk-general] [PATCH 00/15] Clean up makefiles and support building sgdisk executable for Windows

[Bin M. <bme...@gm...>]

Hi Rod,

On Sun, Apr 10, 2022 at 9:34 PM Rod Smith <rod...@ro...> wrote:
>
> On 4/2/22 03:00, Bin Meng wrote:
> > This series was originated from trying to build the sgdisk executable
> > for Windows host, that has not been formally supported as of today.
>
> Thanks for your extensive patch set! It's taken me a while to review it,
> but I've incorporated it into the latest version on the project's git
> repository. (I expect to do a new full release soon, too.) I made a few
> tweaks, mostly to the README.Windows file to more clearly describe how
> to get it to work; and I added the ability to build cgdisk for Windows,
> as well as sgdisk. (This currently works in Windows but not in my Ubuntu
> build environment, though.)
>

Thanks for merging the series. It looks like all my patches are
squashed into a single commit.

Two minor issues:

1. Makefile.mingw64 still contains "-g"
2. Makefile.mingw64 is missing "-static -static-libgcc
-static-libstdc++" in CXXFLAGS

Regards,
Bin

Re: [Gptfdisk-general] [PATCH 00/15] Clean up makefiles and support building sgdisk executable for Windows

[Rod S. <rod...@ro...>]

On 4/2/22 03:00, Bin Meng wrote:
> This series was originated from trying to build the sgdisk executable
> for Windows host, that has not been formally supported as of today.

Thanks for your extensive patch set! It's taken me a while to review it,
but I've incorporated it into the latest version on the project's git
repository. (I expect to do a new full release soon, too.) I made a few
tweaks, mostly to the README.Windows file to more clearly describe how
to get it to work; and I added the ability to build cgdisk for Windows,
as well as sgdisk. (This currently works in Windows but not in my Ubuntu
build environment, though.)

> The series starts from several patches to do some clean-ups to existing
> makefiles for various platforms (patch 1, 2, 3, 4, 6, 7).
> 
> Patch 5 is a build warning fix as the result of adding the '-O2' flag.
> 
> Patch 8 fixes several issues in the 'sgdisk' build rule for mingw*
> builds, and patch 9 enables the sgdisk build by default.
> 
> Path 10 does further clean-up to simplify the build rules.
> 
> Path 11 and 12 are fixes when using newer version gcc (e.g.: gcc 11)
> which is the one that ships on MSYS2.
> 
> Patch 13 switches the Windows executable build from static to shared.
> 
> Patch 14 allows MinGW compiler on both Linux and Windows to be used.
> 
> Patch 15 updates the Windows documentation with the latest information.
> 
> 
> Bin Meng (15):
>   makefile: Drop CC and CFLAGS
>   makefile: Remove the 'testguid' rule for mac build
>   makefile: Fix the 'clean' rule for freebsd/mingw* builds
>   makefile: Drop "-g" compiler flag for mac/mingw* builds
>   gptcl: Silence the compiler warning in BuildMBR()
>   makefile: Add "-O2" compiler flag for linux/freebsd builds
>   makefile: Drop duplicated "-static-libgcc" flag in mingw* builds
>   makefile: Fix the 'sgdisk' rule for mingw* builds
>   makefile: Enable building sgdisk by default for mingw* builds
>   makefile: Consolidate build rules with LDFLAGS and LDLIBS
>   crc32: Remove deprecated 'register' specifier for C++17
>   Explicitly namespace-qualify all std names in header files
>   makefile: Switch to building shared executables for mingw* builds
>   makefile: Avoid absolute path in CXX for mingw* builds
>   README: Update build instructions for Windows executables
> 
>  Makefile         | 17 +++++++----------
>  Makefile.freebsd | 22 +++++++++-------------
>  Makefile.mac     | 22 +++++++---------------
>  Makefile.mingw   | 26 +++++++++++++-------------
>  Makefile.mingw64 | 26 +++++++++++++-------------
>  README.Windows   | 37 ++++++++++++++++++++-----------------
>  attributes.h     | 10 ++++------
>  basicmbr.h       | 12 +++++-------
>  bsd.h            |  5 +----
>  crc32.cc         |  2 +-
>  diskio.h         | 16 +++++++---------
>  gdisk.cc         |  2 ++
>  gpt.h            | 20 +++++++++-----------
>  gptcl.cc         |  4 +++-
>  gptcl.h          | 10 ++++------
>  gptcurses.h      | 10 ++++------
>  gptpart.cc       | 11 +++++------
>  gptpart.h        |  6 ++----
>  gpttext.h        | 12 +++++-------
>  guid.h           | 12 +++++-------
>  mbr.h            |  4 +---
>  mbrpart.h        |  2 --
>  parttypes.h      | 16 +++++++---------
>  support.h        | 16 +++++++---------
>  24 files changed, 141 insertions(+), 179 deletions(-)
> 


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com

[Gptfdisk-general] [PATCH 11/15] crc32: Remove deprecated 'register' specifier for C++17

[Bin M. <bme...@gm...>]

When built with a C++17 compiler (e.g.: gcc 11), there is a
compiler warning:

  crc32.cc: In function ‘uint32_t chksum_crc32(unsigned char*, unsigned int)’:
  crc32.cc:34:27: warning: ISO C++17 does not allow ‘register’ storage class
  specifier [-Wregister]
     34 |    register unsigned long crc;
        |                           ^~~

Prior to C++17 the register storage class specifier was deprecated.
In C++17 it has been removed, making attempts to compile with gcc
'--std=c++17' fail. Let's remove the offending 'register' specifier.

Signed-off-by: Bin Meng <bme...@gm...>
---

 crc32.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crc32.cc b/crc32.cc
index d253dd9..5eca100 100644
--- a/crc32.cc
+++ b/crc32.cc
@@ -31,7 +31,7 @@ uint32_t crc_tab[256];
  */
 uint32_t chksum_crc32 (unsigned char *block, unsigned int length)
 {
-   register unsigned long crc;
+   unsigned long crc;
    unsigned long i;
 
    crc = 0xFFFFFFFF;
-- 
2.25.1

[Gptfdisk-general] [PATCH 07/15] makefile: Drop duplicated "-static-libgcc" flag in mingw* builds

[Bin M. <bme...@gm...>]

"-static-libgcc" flag is already in CXXFLAGS, hence drop the duplicated
one in all the build target rules.

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile.mingw   | 6 +++---
 Makefile.mingw64 | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Makefile.mingw b/Makefile.mingw
index 199547c..68e219c 100644
--- a/Makefile.mingw
+++ b/Makefile.mingw
@@ -13,13 +13,13 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -static-libgcc -o gdisk32.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk32.exe
 
 sgdisk: $(LIB_OBJS) sgdisk.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o -lpopt -static-libgcc -o sgdisk32.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o -lpopt -o sgdisk32.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
-	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -static-libgcc -o fixparts32.exe
+	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts32.exe
 
 lint:	#no pre-reqs
 	lint $(SRCS)
diff --git a/Makefile.mingw64 b/Makefile.mingw64
index fc8dfd6..5a8649c 100644
--- a/Makefile.mingw64
+++ b/Makefile.mingw64
@@ -13,13 +13,13 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -static-libgcc -o gdisk64.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk64.exe
 
 sgdisk: $(LIB_OBJS) sgdisk.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o -lpopt -static-libgcc -o sgdisk64.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o -lpopt -o sgdisk64.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
-	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -static-libgcc -o fixparts64.exe
+	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts64.exe
 
 lint:	#no pre-reqs
 	lint $(SRCS)
-- 
2.25.1

[Gptfdisk-general] [PATCH 13/15] makefile: Switch to building shared executables for mingw* builds

[Bin M. <bme...@gm...>]

Other platform builds generate shared executables except mingw* builds.
Switch to building shared executables for mingw* builds for consistency.
For sgdisk, we can list only '-lpopt' as the additional dependency as
the shared library itself can express its dependencies (-lintl -liconv)
very well.

With such change, $(CXXFLAGS) is no longer needed in the build rule too.

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile.mingw   | 8 ++++----
 Makefile.mingw64 | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Makefile.mingw b/Makefile.mingw
index 7425d89..7492598 100644
--- a/Makefile.mingw
+++ b/Makefile.mingw
@@ -1,6 +1,6 @@
 CXX=/usr/bin/i686-w64-mingw32-g++
 STRIP=/usr/bin/i686-w64-mingw32-strip
-CXXFLAGS=-O2 -Wall -static -static-libgcc -static-libstdc++ -D_FILE_OFFSET_BITS=64
+CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include -I/opt/local/include
 LDFLAGS+=
 LDLIBS+=-lrpcrt4
@@ -15,13 +15,13 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk32.exe
+	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk32.exe
 
 sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -lintl -liconv -o sgdisk32.exe
+	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -o sgdisk32.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
-	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts32.exe
+	$(CXX) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts32.exe
 
 lint:	#no pre-reqs
 	lint $(SRCS)
diff --git a/Makefile.mingw64 b/Makefile.mingw64
index f76acab..202690e 100644
--- a/Makefile.mingw64
+++ b/Makefile.mingw64
@@ -1,6 +1,6 @@
 CXX=/usr/bin/x86_64-w64-mingw32-g++
 STRIP=/usr/bin/x86_64-w64-mingw32-strip
-CXXFLAGS=-O2 -Wall -static -static-libgcc -static-libstdc++ -D_FILE_OFFSET_BITS=64
+CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include -I/opt/local/include
 LDFLAGS+=
 LDLIBS+=-lrpcrt4
@@ -15,13 +15,13 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk64.exe
+	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk64.exe
 
 sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -lintl -liconv -o sgdisk64.exe
+	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -o sgdisk64.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
-	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts64.exe
+	$(CXX) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts64.exe
 
 lint:	#no pre-reqs
 	lint $(SRCS)
-- 
2.25.1

[Gptfdisk-general] [PATCH 09/15] makefile: Enable building sgdisk by default for mingw* builds

[Bin M. <bme...@gm...>]

Now that we have fixed the 'sgdisk' build rule, the sgdisk executable
can be sucessfully built. Let's enable the build by default.

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile.mingw   | 6 +++---
 Makefile.mingw64 | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Makefile.mingw b/Makefile.mingw
index a3f2a7c..4484cde 100644
--- a/Makefile.mingw
+++ b/Makefile.mingw
@@ -10,7 +10,7 @@ MBR_LIB_OBJS=$(MBR_LIBS:=.o)
 LIB_HEADERS=$(LIB_NAMES:=.h)
 DEPEND= makedepend $(CFLAGS)
 
-all:	gdisk fixparts
+all:	gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
 	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk32.exe
@@ -25,10 +25,10 @@ lint:	#no pre-reqs
 	lint $(SRCS)
 
 clean:	#no pre-reqs
-	rm -f core *.o *~ gdisk32.exe fixparts32.exe
+	rm -f core *.o *~ gdisk32.exe sgdisk32.exe fixparts32.exe
 
 strip:	#no pre-reqs
-	$(STRIP) gdisk32.exe fixparts32.exe
+	$(STRIP) gdisk32.exe sgdisk32.exe fixparts32.exe
 
 # what are the source dependencies
 depend: $(SRCS)
diff --git a/Makefile.mingw64 b/Makefile.mingw64
index f062daa..2645fdd 100644
--- a/Makefile.mingw64
+++ b/Makefile.mingw64
@@ -10,7 +10,7 @@ MBR_LIB_OBJS=$(MBR_LIBS:=.o)
 LIB_HEADERS=$(LIB_NAMES:=.h)
 DEPEND= makedepend $(CFLAGS)
 
-all:	gdisk fixparts
+all:	gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
 	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk64.exe
@@ -25,10 +25,10 @@ lint:	#no pre-reqs
 	lint $(SRCS)
 
 clean:	#no pre-reqs
-	rm -f core *.o *~ gdisk64.exe fixparts64.exe
+	rm -f core *.o *~ gdisk64.exe sgdisk64.exe fixparts64.exe
 
 strip:	#no pre-reqs
-	$(STRIP) gdisk64.exe fixparts64.exe
+	$(STRIP) gdisk64.exe sgdisk64.exe fixparts64.exe
 
 # what are the source dependencies
 depend: $(SRCS)
-- 
2.25.1

[Gptfdisk-general] [PATCH 15/15] README: Update build instructions for Windows executables

[Bin M. <bme...@gm...>]

Update the Windows documentation to mention:
- sgdisk{32,64}.exe is now provided
- MSYS2 Windows-hosted MinGW compiler is verified
- instructions to compile on Windows and cross-compile on Linux

Signed-off-by: Bin Meng <bme...@gm...>

---

 README.Windows | 37 ++++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/README.Windows b/README.Windows
index 3f49023..752d988 100644
--- a/README.Windows
+++ b/README.Windows
@@ -28,12 +28,8 @@ Windows Use Notes
 
 The Windows version of GPT fdisk was added with version 0.6.2 of the
 package. The Windows binary package includes the gdisk.exe interactive
-text-mode program file but no equivalent to the sgdisk program that's
-available with Linux, FreeBSD, and OS X builds. In theory, an sgdisk.exe
-for Windows could be built if the popt library were installed. I've not
-attempted to do this myself, though. If you care to try, check
-http://gnuwin32.sourceforge.net/packages/popt.htm for information on popt
-for Windows.
+text-mode program file as well as the sgdisk program that's available
+with Linux, FreeBSD, and OS X builds.
 
 Beginning with version 0.8.10, I'm distributing both 32-bit and 64-bit
 binaries, which include the strings "32" or "64" in their names. The 32-bit
@@ -47,10 +43,11 @@ certain partition table problems that can be created by buggy partitioning
 software. Windows seems to be unfazed by most such problems, but I've not
 done an extensive survey of Windows partitioning tools on this score.
 
-To install the programs, copy the gdisk32.exe and fixparts32.exe (or
-gdisk64.exe and fixparts64.exe) program files to any directory on your
-path, such as C:\Windows. Alternatively, you can change to the program's
-directory or type its complete path whenever you use it.
+To install the programs, copy the gdisk32.exe, sgdisk32.exe and fixparts32.exe
+(or gdisk64.exe, sgdisk64.exe and fixparts64.exe) program files, as well as
+the required DLLs to any directory on your path, such as C:\Windows.
+Alternatively, you can change to the program's directory or type its complete
+path whenever you use it.
 
 To use the programs, first launch a Command Prompt as the Administrator. To
 do this, locate the Command Prompt program icon, right-click it, and select
@@ -103,13 +100,19 @@ Source Code and Compilation Issues
 I have successfully compiled GPT fdisk using three different Windows
 compilers:
 
-- MinGW (http://www.mingw.org), and in particular its Linux-hosted
-  cross-compiler -- Under Ubuntu Linux, the Makefile.mingw and
-  Makefile.mingw64 files enable compilation of the software via MinGW.
-  (Type "make -f Makefile.mingw" to compile 32-bit binaries, and "make -f
-  Makefile.mingw64" to compile 64-bit binaries.) If you try to compile
-  using another compiler or even using MinGW under Windows or another Linux
-  variety, you may need to adjust the Makefile.mingw options.
+- MinGW (https://www.mingw-w64.org/), either Linux-hosted cross-compiler
+  -- Under Ubuntu / Fedora Linux, or Windows-hosted compiler -- MSYS2
+  (https://www.msys2.org), the Makefile.mingw and Makefile.mingw64 files
+  enable compilation of the software via MinGW. (Type "make -f
+  Makefile.mingw" to compile 32-bit binaries, and "make -f Makefile.mingw64"
+  to compile 64-bit binaries.) For MSYS2, make sure you install the popt and
+  gettext packages (pacman -S mingw-w64-x86_64-popt mingw-w64-x86_64-gettext
+  if you are to compile 64-bit binaries; change 'x86_64' to 'i686' for 32-bit
+  packages). For Linux-hosted cross-compiler, the Linux distribution does not
+  provide the popt packages for MinGW, but you can manually copy the header
+  and the libraries in the MSYS2 package to the sysroot in the Linux-hosted
+  MinGW cross-compiler. If you try to compile using another compiler or
+  another Linux variety, you may need to adjust the Makefile.mingw options.
 
 - Microsoft Visual C++ 2008 Express
   (http://www.microsoft.com/express/Windows/) -- This compiler requires a
-- 
2.25.1

[Gptfdisk-general] [PATCH 12/15] Explicitly namespace-qualify all std names in header files

[Bin M. <bme...@gm...>]

The windows executables fail to compile with gcc 11 mingw cross-compile
toolchain which defaults to '-std=c++17', due to conflicting definitions.

  In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/wtypes.h:8,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/winscard.h:10,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:97,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/rpc.h:16,
                   from guid.h:23,
                   from parttypes.h:16,
                   from gptpart.h:22,
                   from gptpart.cc:27:
  /usr/x86_64-w64-mingw32/sys-root/mingw/include/rpcndr.h:64:11:
  error:reference to 'byte' is ambiguous
     64 |   typedef byte cs_byte;
        |           ^~~~
  In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/stl_algobase.h:61,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/char_traits.h:39,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ios:40,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ostream:38,
                   from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/iostream:39,
                   from gptpart.cc:26:
  /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum class std::byte'
    404 |   enum class byte : unsigned char;
        |                              ^~~~

The issue has been unnoticed so far all the way up to gcc 10, which
defaulted to '-std=c++14'. But it can still be reproduced with gcc 10
with an explicit '-std=c++17' flag.

"using namespace std" in header files is considered as a bad practice,
often known as global namespace pollution. Problems may occur when more
than one namespace has the same symbol name with signature, then it will
be ambiguous for the compiler to decide which one to use.

Let's explicitly namespace-qualify all std names in header files, and
move "using namespace std" to *.cc files.

Signed-off-by: Bin Meng <bme...@gm...>
---

 attributes.h | 10 ++++------
 basicmbr.h   | 12 +++++-------
 bsd.h        |  5 +----
 diskio.h     | 16 +++++++---------
 gdisk.cc     |  2 ++
 gpt.h        | 20 +++++++++-----------
 gptcl.cc     |  2 ++
 gptcl.h      | 10 ++++------
 gptcurses.h  | 10 ++++------
 gptpart.cc   | 11 +++++------
 gptpart.h    |  6 ++----
 gpttext.h    | 12 +++++-------
 guid.h       | 12 +++++-------
 mbr.h        |  4 +---
 mbrpart.h    |  2 --
 parttypes.h  | 16 +++++++---------
 support.h    | 16 +++++++---------
 17 files changed, 70 insertions(+), 96 deletions(-)

diff --git a/attributes.h b/attributes.h
index 6a61b8c..5eb57e3 100644
--- a/attributes.h
+++ b/attributes.h
@@ -10,11 +10,9 @@
 #define NUM_ATR 64 /* # of attributes -- 64, since it's a 64-bit field */
 #define ATR_NAME_SIZE 25 /* maximum size of attribute names */
 
-using namespace std;
-
 class Attributes {
 protected:
-   static string atNames[NUM_ATR];
+   static std::string atNames[NUM_ATR];
    static int numAttrs;
    void Setup(void);
    uint64_t attributes;
@@ -30,12 +28,12 @@ public:
    void ShowAttributes(const uint32_t partNum);
 
    void ChangeAttributes(void);
-   bool OperateOnAttributes(const uint32_t partNum, const string& attributeOperator, const string& attributeBits);
+   bool OperateOnAttributes(const uint32_t partNum, const std::string& attributeOperator, const std::string& attributeBits);
 
-   static const string& GetAttributeName(const uint32_t bitNum) {return atNames [bitNum];}
+   static const std::string& GetAttributeName(const uint32_t bitNum) {return atNames [bitNum];}
    static void ListAttributes(void);
 }; // class Attributes
 
-ostream & operator<<(ostream & os, const Attributes & data);
+std::ostream & operator<<(std::ostream & os, const Attributes & data);
 
 #endif
diff --git a/basicmbr.h b/basicmbr.h
index f4b0e45..696f826 100644
--- a/basicmbr.h
+++ b/basicmbr.h
@@ -16,8 +16,6 @@
 // Maximum number of MBR partitions
 #define MAX_MBR_PARTS 128
 
-using namespace std;
-
 /****************************************
  *                                      *
  * MBRData class and related structures *
@@ -57,23 +55,23 @@ protected:
    uint32_t numSecspTrack; // number of sectors per track, in CHS scheme
    DiskIO* myDisk;
    int canDeleteMyDisk;
-   string device;
+   std::string device;
    MBRValidity state;
    MBRPart* GetPartition(int i); // Return primary or logical partition
 public:
    BasicMBRData(void);
-   BasicMBRData(string deviceFilename);
+   BasicMBRData(std::string deviceFilename);
    BasicMBRData(const BasicMBRData &);
    ~BasicMBRData(void);
    BasicMBRData & operator=(const BasicMBRData & orig);
 
    // File I/O functions...
-   int ReadMBRData(const string & deviceFilename);
+   int ReadMBRData(const std::string & deviceFilename);
    int ReadMBRData(DiskIO * theDisk, int checkBlockSize = 1);
    int ReadLogicalParts(uint64_t extendedStart, int partNum);
    int WriteMBRData(void);
    int WriteMBRData(DiskIO *theDisk);
-   int WriteMBRData(const string & deviceFilename);
+   int WriteMBRData(const std::string & deviceFilename);
    int WriteMBRData(struct TempMBR & mbr, DiskIO *theDisk, uint64_t sector);
    void DiskSync(void) {myDisk->DiskSync();}
    void SetDisk(DiskIO *theDisk);
@@ -147,7 +145,7 @@ public:
    uint64_t GetLength(int i);
 
    // User interaction functions....
-   int DoMenu(const string& prompt = "\nMBR command (? for help): ");
+   int DoMenu(const std::string& prompt = "\nMBR command (? for help): ");
    void ShowCommands(void);
 }; // class BasicMBRData
 
diff --git a/bsd.h b/bsd.h
index c4b74a4..e042b7b 100644
--- a/bsd.h
+++ b/bsd.h
@@ -30,9 +30,6 @@
 // memory errors will occur.
 #define MAX_BSD_PARTS 64
 
-
-using namespace std;
-
 /****************************************
  *                                      *
  * BSDData class and related structures *
@@ -75,7 +72,7 @@ class BSDData {
    public:
       BSDData(void);
       ~BSDData(void);
-      int ReadBSDData(const string & deviceFilename, uint64_t startSector, uint64_t endSector);
+      int ReadBSDData(const std::string & deviceFilename, uint64_t startSector, uint64_t endSector);
       int ReadBSDData(DiskIO *myDisk, uint64_t startSector, uint64_t endSector);
       void ReverseMetaBytes(void);
       void DisplayBSDData(void);
diff --git a/diskio.h b/diskio.h
index 0bdaba4..b5c2ecc 100644
--- a/diskio.h
+++ b/diskio.h
@@ -37,8 +37,6 @@
 #include "support.h"
 //#include "parttypes.h"
 
-using namespace std;
-
 /***************************************
  *                                     *
  * DiskIO class and related structures *
@@ -47,9 +45,9 @@ using namespace std;
 
 class DiskIO {
    protected:
-      string userFilename;
-      string realFilename;
-      string modelName;
+      std::string userFilename;
+      std::string realFilename;
+      std::string modelName;
       int isOpen;
       int openForWrite;
 #ifdef _WIN32
@@ -62,9 +60,9 @@ class DiskIO {
       ~DiskIO(void);
 
       void MakeRealName(void);
-      int OpenForRead(const string & filename);
+      int OpenForRead(const std::string & filename);
       int OpenForRead(void);
-      int OpenForWrite(const string & filename);
+      int OpenForWrite(const std::string & filename);
       int OpenForWrite(void);
       void Close();
       int Seek(uint64_t sector);
@@ -73,12 +71,12 @@ class DiskIO {
       int DiskSync(void); // resync disk caches to use new partitions
       int GetBlockSize(void);
       int GetPhysBlockSize(void);
-      string GetModel(void) {return modelName;}
+      std::string GetModel(void) {return modelName;}
       uint32_t GetNumHeads(void);
       uint32_t GetNumSecsPerTrack(void);
       int IsOpen(void) {return isOpen;}
       int IsOpenForWrite(void) {return openForWrite;}
-      string GetName(void) const {return realFilename;}
+      std::string GetName(void) const {return realFilename;}
 
       uint64_t DiskSize(int* err);
 }; // class DiskIO
diff --git a/gdisk.cc b/gdisk.cc
index 5f85498..c9443bd 100644
--- a/gdisk.cc
+++ b/gdisk.cc
@@ -11,6 +11,8 @@
 #include <iostream>
 #include "gpttext.h"
 
+using namespace std;
+
 int main(int argc, char* argv[]) {
    GPTDataTextUI theGPT;
    string device = "";
diff --git a/gpt.h b/gpt.h
index cf05f59..5d19372 100644
--- a/gpt.h
+++ b/gpt.h
@@ -24,8 +24,6 @@
 // smallest Advanced Format drive I know of is 320GB in size
 #define SMALLEST_ADVANCED_FORMAT UINT64_C(585937500)
 
-using namespace std;
-
 /****************************************
  *                                      *
  * GPTData class and related structures *
@@ -67,7 +65,7 @@ protected:
    uint32_t numParts; // # of partitions the table can hold
    struct GPTHeader secondHeader;
    MBRData protectiveMBR;
-   string device; // device filename
+   std::string device; // device filename
    DiskIO myDisk;
    uint32_t blockSize; // device logical block size
    uint32_t physBlockSize; // device physical block size (or 0 if it can't be determined)
@@ -93,7 +91,7 @@ public:
    // Basic necessary functions....
    GPTData(void);
    GPTData(const GPTData &);
-   GPTData(string deviceFilename);
+   GPTData(std::string deviceFilename);
    virtual ~GPTData(void);
    GPTData & operator=(const GPTData & orig);
 
@@ -111,18 +109,18 @@ public:
    int FindInsanePartitions(void);
 
    // Load or save data from/to disk
-   int SetDisk(const string & deviceFilename);
+   int SetDisk(const std::string & deviceFilename);
    DiskIO* GetDisk(void) {return &myDisk;}
-   int LoadMBR(const string & f) {return protectiveMBR.ReadMBRData(f);}
+   int LoadMBR(const std::string & f) {return protectiveMBR.ReadMBRData(f);}
    int WriteProtectiveMBR(void) {return protectiveMBR.WriteMBRData(&myDisk);}
    void PartitionScan(void);
-   int LoadPartitions(const string & deviceFilename);
+   int LoadPartitions(const std::string & deviceFilename);
    int ForceLoadGPTData(void);
    int LoadMainTable(void);
    int LoadSecondTableAsMain(void);
    int SaveGPTData(int quiet = 0);
-   int SaveGPTBackup(const string & filename);
-   int LoadGPTBackup(const string & filename);
+   int SaveGPTBackup(const std::string & filename);
+   int LoadGPTBackup(const std::string & filename);
    int SaveMBR(void);
    int DestroyGPT(void);
    int DestroyMBR(void);
@@ -204,9 +202,9 @@ public:
    void ReversePartitionBytes(); // for endianness
 
    // Attributes functions
-   int ManageAttributes(int partNum, const string & command, const string & bits);
+   int ManageAttributes(int partNum, const std::string & command, const std::string & bits);
    void ShowAttributes(const uint32_t partNum);
-   void GetAttribute(const uint32_t partNum, const string& attributeBits);
+   void GetAttribute(const uint32_t partNum, const std::string& attributeBits);
 
 }; // class GPTData
 
diff --git a/gptcl.cc b/gptcl.cc
index 0141994..34c9421 100644
--- a/gptcl.cc
+++ b/gptcl.cc
@@ -26,6 +26,8 @@
 #include <popt.h>
 #include "gptcl.h"
 
+using namespace std;
+
 GPTDataCL::GPTDataCL(void) {
    attributeOperation = backupFile = partName = hybrids = newPartInfo = NULL;
    mbrParts = twoParts = outDevice = typeCode = partGUID = diskGUID = NULL;
diff --git a/gptcl.h b/gptcl.h
index 183b846..57d3f5d 100644
--- a/gptcl.h
+++ b/gptcl.h
@@ -25,8 +25,6 @@
 #include "gpt.h"
 #include <popt.h>
 
-using namespace std;
-
 class GPTDataCL : public GPTData {
    protected:
       // Following are variables associated with popt parameters....
@@ -41,14 +39,14 @@ class GPTDataCL : public GPTData {
       int BuildMBR(char* argument, int isHybrid);
    public:
       GPTDataCL(void);
-      GPTDataCL(string filename);
+      GPTDataCL(std::string filename);
       ~GPTDataCL(void);
-      void LoadBackupFile(string backupFile, int &saveData, int &neverSaveData);
+      void LoadBackupFile(std::string backupFile, int &saveData, int &neverSaveData);
       int DoOptions(int argc, char* argv[]);
 }; // class GPTDataCL
 
 int CountColons(char* argument);
-uint64_t GetInt(const string & argument, int itemNum);
-string GetString(string argument, int itemNum);
+uint64_t GetInt(const std::string & argument, int itemNum);
+std::string GetString(std::string argument, int itemNum);
 
 #endif
diff --git a/gptcurses.h b/gptcurses.h
index a080987..8d2ecaf 100644
--- a/gptcurses.h
+++ b/gptcurses.h
@@ -27,12 +27,10 @@
 #include "gptpart.h"
 #include "gpt.h"
 
-using namespace std;
-
 struct MenuItem {
    int key; // Keyboard shortcut
-   string name; // Item name; 8 characters
-   string desc; // Description
+   std::string name; // Item name; 8 characters
+   std::string desc; // Description
 };
 
 static struct MenuItem menuMain[] = {
@@ -81,7 +79,7 @@ protected:
    Space *lastSpace;
    Space *currentSpace;
    int currentSpaceNum;
-   string whichOptions;
+   std::string whichOptions;
    char currentKey;
    int numSpaces;
    int displayType;
@@ -130,7 +128,7 @@ public:
 void ClearLine(int lineNum);
 void ClearBottom(void);
 void PromptToContinue(void);
-void Report(string theText);
+void Report(std::string theText);
 void ShowTypes(void);
 
 #endif
diff --git a/gptpart.cc b/gptpart.cc
index b83254d..5fe7b5a 100644
--- a/gptpart.cc
+++ b/gptpart.cc
@@ -15,17 +15,16 @@
 #define __STDC_LIMIT_MACROS
 #define __STDC_CONSTANT_MACROS
 
-#ifdef USE_UTF16
-#include <unicode/ustdio.h>
-#else
-#define UnicodeString string
-#endif
-
 #include <string.h>
 #include <stdio.h>
 #include <iostream>
 #include "gptpart.h"
 #include "attributes.h"
+#ifdef USE_UTF16
+#include <unicode/ustdio.h>
+#else
+#define UnicodeString std::string
+#endif
 
 using namespace std;
 
diff --git a/gptpart.h b/gptpart.h
index 51bfb38..ede8139 100644
--- a/gptpart.h
+++ b/gptpart.h
@@ -23,8 +23,6 @@
 #include "guid.h"
 #include "attributes.h"
 
-using namespace std;
-
 // Values returned by GPTPart::IsSizedForMBR()
 #define MBR_SIZED_GOOD 0 /* Whole partition under 2^32 sectors */
 #define MBR_SIZED_IFFY 1 /* Partition starts under 2^32 & is less than 2^32, but ends over 2^32 */
@@ -59,7 +57,7 @@ class GPTPart {
       // Simple data retrieval:
       PartType & GetType(void) {return partitionType;}
       uint16_t GetHexType(void) const;
-      string GetTypeName(void);
+      std::string GetTypeName(void);
       UnicodeString GetUTypeName(void);
       const GUIDData GetUniqueGUID(void) const {return uniqueGUID;}
       uint64_t GetFirstLBA(void) const {return firstLBA;}
@@ -80,7 +78,7 @@ class GPTPart {
       void SetLastLBA(uint64_t l) {lastLBA = l;}
       void SetAttributes(uint64_t a) {attributes = a;}
       void SetAttributes(void) {attributes.ChangeAttributes();}
-      void SetName(const string & theName);
+      void SetName(const std::string & theName);
 #ifdef USE_UTF16
       void SetName(const UnicodeString & theName);
 #endif
diff --git a/gpttext.h b/gpttext.h
index 36a17f9..32e2f88 100644
--- a/gpttext.h
+++ b/gpttext.h
@@ -23,13 +23,11 @@
 
 #include "gpt.h"
 
-using namespace std;
-
 class GPTDataTextUI : public GPTData {
    protected:
    public:
       GPTDataTextUI(void);
-      GPTDataTextUI(string filename);
+      GPTDataTextUI(std::string filename);
       ~GPTDataTextUI(void);
 
       // This one needs to be explicitly defined, even though it does nothing new....
@@ -55,17 +53,17 @@ class GPTDataTextUI : public GPTData {
       void ShowDetails(void);
       void MakeHybrid(void);
       int XFormToMBR(void); // convert GPT to MBR, wiping GPT afterwards. Returns 1 if successful
-      uint64_t GetSectorNum(uint64_t low, uint64_t high, uint64_t def, const string & prompt);
+      uint64_t GetSectorNum(uint64_t low, uint64_t high, uint64_t def, const std::string & prompt);
 
       // An informational function....
       void WarnAboutIffyMBRPart(int partNum);
 
       // Main menu functions
-      void MainMenu(string filename);
+      void MainMenu(std::string filename);
       void ShowCommands(void);
-      void ExpertsMenu(string filename);
+      void ExpertsMenu(std::string filename);
       void ShowExpertCommands(void);
-      void RecoveryMenu(string filename);
+      void RecoveryMenu(std::string filename);
       void ShowRecoveryCommands(void);
 }; // class GPTDataTextUI
 
diff --git a/guid.h b/guid.h
index 229d5bd..515a75d 100644
--- a/guid.h
+++ b/guid.h
@@ -30,8 +30,6 @@ typedef unsigned char my_uuid_t[16];
 typedef uuid_t my_uuid_t;
 #endif
 
-using namespace std;
-
 // Note: This class's data size is critical. If data elements must be added,
 // it will be necessary to modify various GPT classes to compensate.
 class GUIDData {
@@ -39,17 +37,17 @@ class GUIDData {
       static bool firstInstance;
    protected:
       my_uuid_t uuidData;
-      string DeleteSpaces(string s);
+      std::string DeleteSpaces(std::string s);
    public:
       GUIDData(void);
       GUIDData(const GUIDData & orig);
-      GUIDData(const string & orig);
+      GUIDData(const std::string & orig);
       GUIDData(const char * orig);
       ~GUIDData(void);
 
       // Data assignment operators....
       GUIDData & operator=(const GUIDData & orig);
-      GUIDData & operator=(const string & orig);
+      GUIDData & operator=(const std::string & orig);
       GUIDData & operator=(const char * orig);
       void Zero(void);
       void Randomize(void);
@@ -59,9 +57,9 @@ class GUIDData {
       int operator!=(const GUIDData & orig) const;
 
       // Data retrieval....
-      string AsString(void) const;
+      std::string AsString(void) const;
 }; // class GUIDData
 
-ostream & operator<<(ostream & os, const GUIDData & data);
+std::ostream & operator<<(std::ostream & os, const GUIDData & data);
 
 #endif
diff --git a/mbr.h b/mbr.h
index 21c1d7b..3eea775 100644
--- a/mbr.h
+++ b/mbr.h
@@ -13,8 +13,6 @@
 #include "diskio.h"
 #include "basicmbr.h"
 
-using namespace std;
-
 /****************************************
  *                                      *
  * MBRData class and related structures *
@@ -26,7 +24,7 @@ class MBRData : public BasicMBRData {
 protected:
 public:
    MBRData(void) {}
-   MBRData(string deviceFilename) : BasicMBRData(deviceFilename) {}
+   MBRData(std::string deviceFilename) : BasicMBRData(deviceFilename) {}
    MBRData & operator=(const BasicMBRData & orig);
    ~MBRData(void);
 
diff --git a/mbrpart.h b/mbrpart.h
index 0de365f..6c7b21a 100644
--- a/mbrpart.h
+++ b/mbrpart.h
@@ -32,8 +32,6 @@
 #define EBR 4     /* sector is used as an EBR or MBR */
 #define INVALID 8 /* sector number is too large for disk */
 
-using namespace std;
-
 // Data for a single MBR partition record
 // Note that firstSector and lastSector are in CHS addressing, which
 // splits the bits up in a weird way.
diff --git a/parttypes.h b/parttypes.h
index 92f3d64..4e1d968 100644
--- a/parttypes.h
+++ b/parttypes.h
@@ -6,16 +6,14 @@
 
 #include <stdint.h>
 #include <stdlib.h>
+#include <string>
+#include "support.h"
+#include "guid.h"
 #ifdef USE_UTF16
 #include <unicode/ustream.h>
 #else
-#define UnicodeString string
+#define UnicodeString std::string
 #endif
-#include <string>
-#include "support.h"
-#include "guid.h"
-
-using namespace std;
 
 // A partition type
 struct AType {
@@ -24,7 +22,7 @@ struct AType {
    // codes required by GPT
    uint16_t MBRType;
    GUIDData GUIDType;
-   string name;
+   std::string name;
    int display; // 1 to show to users as available type, 0 not to
    AType* next;
 }; // struct AType
@@ -48,7 +46,7 @@ public:
    int AddType(uint16_t mbrType, const char * guidData, const char * name, int toDisplay = 1);
 
    // New assignment operators....
-   PartType & operator=(const string & orig);
+   PartType & operator=(const std::string & orig);
    PartType & operator=(const char * orig);
 
    // Assignment operators based on base class....
@@ -58,7 +56,7 @@ public:
    PartType & operator=(uint16_t ID); // Use MBR type code times 0x0100 to assign GUID
 
    // Retrieve transformed GUID data based on type code matches
-   string TypeName(void) const;
+   std::string TypeName(void) const;
    UnicodeString UTypeName(void) const;
    uint16_t GetHexType() const;
 
diff --git a/support.h b/support.h
index a61ddf4..e79b62e 100644
--- a/support.h
+++ b/support.h
@@ -69,18 +69,16 @@
 #define GPT_RESERVED 420
 #define NAME_SIZE 36 // GPT allows 36 UTF-16LE code units for a name in a 128 byte partition entry
 
-using namespace std;
-
-string ReadString(void);
-uint64_t GetNumber(uint64_t low, uint64_t high, uint64_t def, const string & prompt);
+std::string ReadString(void);
+uint64_t GetNumber(uint64_t low, uint64_t high, uint64_t def, const std::string & prompt);
 char GetYN(void);
-uint64_t IeeeToInt(string IeeeValue, uint64_t sSize, uint64_t low, uint64_t high, uint32_t sectorAlignment, uint64_t def = 0);
-string BytesToIeee(uint64_t size, uint32_t sectorSize);
-unsigned char StrToHex(const string & input, unsigned int position);
-int IsHex(string input); // Returns 1 if input can be hexadecimal number....
+uint64_t IeeeToInt(std::string IeeeValue, uint64_t sSize, uint64_t low, uint64_t high, uint32_t sectorAlignment, uint64_t def = 0);
+std::string BytesToIeee(uint64_t size, uint32_t sectorSize);
+unsigned char StrToHex(const std::string & input, unsigned int position);
+int IsHex(std::string input); // Returns 1 if input can be hexadecimal number....
 int IsLittleEndian(void); // Returns 1 if CPU is little-endian, 0 if it's big-endian
 void ReverseBytes(void* theValue, int numBytes); // Reverses byte-order of theValue
 void WinWarning(void);
-string ToLower(const string& input);
+std::string ToLower(const std::string& input);
 
 #endif
-- 
2.25.1

[Gptfdisk-general] [PATCH 08/15] makefile: Fix the 'sgdisk' rule for mingw* builds

[Bin M. <bme...@gm...>]

Currently the sgdisk build rule for mingw* builds is incorrect in
various aspects:

* missing an object file gptcl.o for compiling and linking
* linking to librpcrt4 library is missing too
* libpopt actually has a dependency to libintl, which in turn has
  a dependency to libiconv, and such dependencies have to be passed
  to the linker as we are building a static executable

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile.mingw   | 4 ++--
 Makefile.mingw64 | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile.mingw b/Makefile.mingw
index 68e219c..a3f2a7c 100644
--- a/Makefile.mingw
+++ b/Makefile.mingw
@@ -15,8 +15,8 @@ all:	gdisk fixparts
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
 	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk32.exe
 
-sgdisk: $(LIB_OBJS) sgdisk.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o -lpopt -o sgdisk32.exe
+sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o -lrpcrt4 -lpopt -lintl -liconv -o sgdisk32.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
 	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts32.exe
diff --git a/Makefile.mingw64 b/Makefile.mingw64
index 5a8649c..f062daa 100644
--- a/Makefile.mingw64
+++ b/Makefile.mingw64
@@ -15,8 +15,8 @@ all:	gdisk fixparts
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
 	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk64.exe
 
-sgdisk: $(LIB_OBJS) sgdisk.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o -lpopt -o sgdisk64.exe
+sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o -lrpcrt4 -lpopt -lintl -liconv -o sgdisk64.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
 	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts64.exe
-- 
2.25.1

[Gptfdisk-general] [PATCH 14/15] makefile: Avoid absolute path in CXX for mingw* builds

[Bin M. <bme...@gm...>]

At present CXX specifies absolute path for the MinGW GCC compiler.
But it only applies to MinGW cross compiler on the Linux host.
On a Windows host with MSYS2, MinGW GCC is normally installed at
/mingw{32,64}/bin which does not work with current makefile.

Remove the absolute path prefix, as on both Linux and Windows hosts
MinGW GCC compiler path is already in the PATH environment.

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile.mingw   | 4 ++--
 Makefile.mingw64 | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile.mingw b/Makefile.mingw
index 7492598..eaed728 100644
--- a/Makefile.mingw
+++ b/Makefile.mingw
@@ -1,5 +1,5 @@
-CXX=/usr/bin/i686-w64-mingw32-g++
-STRIP=/usr/bin/i686-w64-mingw32-strip
+CXX=i686-w64-mingw32-g++
+STRIP=i686-w64-mingw32-strip
 CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include -I/opt/local/include
 LDFLAGS+=
diff --git a/Makefile.mingw64 b/Makefile.mingw64
index 202690e..45a61cb 100644
--- a/Makefile.mingw64
+++ b/Makefile.mingw64
@@ -1,5 +1,5 @@
-CXX=/usr/bin/x86_64-w64-mingw32-g++
-STRIP=/usr/bin/x86_64-w64-mingw32-strip
+CXX=x86_64-w64-mingw32-g++
+STRIP=x86_64-w64-mingw32-strip
 CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include -I/opt/local/include
 LDFLAGS+=
-- 
2.25.1

[Gptfdisk-general] [PATCH 10/15] makefile: Consolidate build rules with LDFLAGS and LDLIBS

[Bin M. <bme...@gm...>]

At present there are duplications in the build rules of various
targets. Let's consolidate them using LDFLAGS and LDLIBS.

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile         | 12 +++++-------
 Makefile.freebsd | 14 ++++++--------
 Makefile.mac     | 13 +++++--------
 Makefile.mingw   |  6 ++++--
 Makefile.mingw64 |  6 ++++--
 5 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/Makefile b/Makefile
index d1ac530..7ecab54 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,7 @@
 #CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16
 CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64
 LDFLAGS+=
+LDLIBS+=-luuid #-licuio -licuuc
 LIB_NAMES=crc32 support guid gptpart mbrpart basicmbr mbr gpt bsd parttypes attributes diskio diskio-unix
 MBR_LIBS=support diskio diskio-unix basicmbr mbrpart
 LIB_OBJS=$(LIB_NAMES:=.o)
@@ -11,19 +12,16 @@ DEPEND= makedepend $(CXXFLAGS)
 all:	cgdisk gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) -luuid $(LDLIBS) -o gdisk
-#	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) -licuio -licuuc -luuid -o gdisk
+	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk
 
 cgdisk: $(LIB_OBJS) cgdisk.o gptcurses.o
-	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o $(LDFLAGS) -luuid -lncursesw $(LDLIBS) -o cgdisk
-#	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o $(LDFLAGS) -licuio -licuuc -luuid -lncurses -o cgdisk
+	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o $(LDFLAGS) $(LDLIBS) -lncursesw -o cgdisk
 
 sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
-	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) -luuid -lpopt $(LDLIBS) -o sgdisk
-#	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) -licuio -licuuc -luuid -lpopt -o sgdisk
+	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -o sgdisk
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
-	$(CXX) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) $(LDLIBS) -o fixparts
+	$(CXX) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts
 
 test:
 	./gdisk_test.sh
diff --git a/Makefile.freebsd b/Makefile.freebsd
index c0dd416..7223f2d 100644
--- a/Makefile.freebsd
+++ b/Makefile.freebsd
@@ -1,7 +1,8 @@
 CXX=clang++
 #CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16 -I/usr/local/include
 CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include 
-LDFLAGS+=
+LDFLAGS+=-L/usr/local/lib
+LDLIBS+=-luuid #-licuio
 LIB_NAMES=crc32 support guid gptpart mbrpart basicmbr mbr gpt bsd parttypes attributes diskio diskio-unix
 MBR_LIBS=support diskio diskio-unix basicmbr mbrpart
 LIB_OBJS=$(LIB_NAMES:=.o)
@@ -12,19 +13,16 @@ DEPEND= makedepend $(CXXFLAGS)
 all:	gdisk cgdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-#	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o -L/usr/local/lib $(LDFLAGS) -licuio -luuid -o gdisk
-	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o -L/usr/local/lib $(LDFLAGS) -luuid -o gdisk
+	$(CXX) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk
 
 cgdisk: $(LIB_OBJS) cgdisk.o gptcurses.o
-#	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o -L/usr/local/lib $(LDFLAGS) -licuio -luuid -lncurses -o cgdisk
-	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o -L/usr/local/lib $(LDFLAGS) -luuid -lncurses -o cgdisk
+	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o $(LDFLAGS) $(LDLIBS) -lncurses -o cgdisk
 
 sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
-#	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o -L/usr/local/lib $(LDFLAGS) -luuid -licuio -lpopt -o sgdisk
-	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o -L/usr/local/lib $(LDFLAGS) -luuid -lpopt -o sgdisk
+	$(CXX) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -o sgdisk
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
-	$(CXX) $(MBR_LIB_OBJS) fixparts.o -L/usr/local/lib $(LDFLAGS) -o fixparts
+	$(CXX) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts
 
 lint:	#no pre-reqs
 	lint $(SRCS)
diff --git a/Makefile.mac b/Makefile.mac
index bf68b83..91a281c 100644
--- a/Makefile.mac
+++ b/Makefile.mac
@@ -4,6 +4,8 @@ FATBINFLAGS=-arch x86_64 -arch arm64 -mmacosx-version-min=10.9
 THINBINFLAGS=-arch x86_64 -mmacosx-version-min=10.9
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16 -I/opt/local/include -I/usr/local/include -I/opt/local/include
 CXXFLAGS=$(FATBINFLAGS) -O2 -Wall -D_FILE_OFFSET_BITS=64 -stdlib=libc++ -I/opt/local/include -I /usr/local/include -I/opt/local/include
+LDFLAGS+=
+LDLIBS+= #-licucore
 LIB_NAMES=crc32 support guid gptpart mbrpart basicmbr mbr gpt bsd parttypes attributes diskio diskio-unix
 MBR_LIBS=support diskio diskio-unix basicmbr mbrpart
 #LIB_SRCS=$(NAMES:=.cc)
@@ -15,18 +17,13 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk sgdisk cgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gpttext.o gdisk.o
-	$(CXX) $(LIB_OBJS) gpttext.o gdisk.o $(FATBINFLAGS) -o gdisk
-#	$(CXX) $(LIB_OBJS) -L/usr/lib -licucore gpttext.o gdisk.o -o gdisk
+	$(CXX) $(LIB_OBJS) gpttext.o gdisk.o $(FATBINFLAGS) $(LDFLAGS) $(LDLIBS) -o gdisk
 
 cgdisk: $(LIB_OBJS) cgdisk.o gptcurses.o
-	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o /usr/local/Cellar/ncurses/6.2/lib/libncurses.dylib $(LDFLAGS) -o cgdisk
-#	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o /usr/lib/libncurses.dylib $(LDFLAGS) -o cgdisk
-#	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o $(LDFLAGS) -licucore -lncurses -o cgdisk
+	$(CXX) $(LIB_OBJS) cgdisk.o gptcurses.o $(LDFLAGS) $(LDLIBS) /usr/local/Cellar/ncurses/6.2/lib/libncurses.dylib -o cgdisk
 
 sgdisk: $(LIB_OBJS) gptcl.o sgdisk.o
-#	$(CXX) $(LIB_OBJS) gptcl.o sgdisk.o /opt/local/lib/libiconv.a /opt/local/lib/libintl.a /opt/local/lib/libpopt.a $(FATBINFLAGS) -o sgdisk
-	$(CXX) $(LIB_OBJS) gptcl.o sgdisk.o -L/usr/local/lib -lpopt $(THINBINFLAGS) -o sgdisk
-#	$(CXX) $(LIB_OBJS) gptcl.o sgdisk.o -L/sw/lib -licucore -lpopt -o sgdisk
+	$(CXX) $(LIB_OBJS) gptcl.o sgdisk.o $(LDFLAGS) -L/usr/local/lib $(LDLIBS) -lpopt $(THINBINFLAGS) -o sgdisk
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
 	$(CXX) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) $(FATBINFLAGS) -o fixparts
diff --git a/Makefile.mingw b/Makefile.mingw
index 4484cde..7425d89 100644
--- a/Makefile.mingw
+++ b/Makefile.mingw
@@ -2,6 +2,8 @@ CXX=/usr/bin/i686-w64-mingw32-g++
 STRIP=/usr/bin/i686-w64-mingw32-strip
 CXXFLAGS=-O2 -Wall -static -static-libgcc -static-libstdc++ -D_FILE_OFFSET_BITS=64
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include -I/opt/local/include
+LDFLAGS+=
+LDLIBS+=-lrpcrt4
 LIB_NAMES=guid gptpart bsd parttypes attributes crc32 mbrpart basicmbr mbr gpt support diskio diskio-windows
 MBR_LIBS=support diskio diskio-windows basicmbr mbrpart
 LIB_SRCS=$(NAMES:=.cc)
@@ -13,10 +15,10 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk32.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk32.exe
 
 sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o -lrpcrt4 -lpopt -lintl -liconv -o sgdisk32.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -lintl -liconv -o sgdisk32.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
 	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts32.exe
diff --git a/Makefile.mingw64 b/Makefile.mingw64
index 2645fdd..f76acab 100644
--- a/Makefile.mingw64
+++ b/Makefile.mingw64
@@ -2,6 +2,8 @@ CXX=/usr/bin/x86_64-w64-mingw32-g++
 STRIP=/usr/bin/x86_64-w64-mingw32-strip
 CXXFLAGS=-O2 -Wall -static -static-libgcc -static-libstdc++ -D_FILE_OFFSET_BITS=64
 #CXXFLAGS=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include -I/opt/local/include
+LDFLAGS+=
+LDLIBS+=-lrpcrt4
 LIB_NAMES=guid gptpart bsd parttypes attributes crc32 mbrpart basicmbr mbr gpt support diskio diskio-windows
 MBR_LIBS=support diskio diskio-windows basicmbr mbrpart
 LIB_SRCS=$(NAMES:=.cc)
@@ -13,10 +15,10 @@ DEPEND= makedepend $(CFLAGS)
 all:	gdisk sgdisk fixparts
 
 gdisk:	$(LIB_OBJS) gdisk.o gpttext.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o -lrpcrt4 -o gdisk64.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) gdisk.o gpttext.o $(LDFLAGS) $(LDLIBS) -o gdisk64.exe
 
 sgdisk: $(LIB_OBJS) sgdisk.o gptcl.o
-	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o -lrpcrt4 -lpopt -lintl -liconv -o sgdisk64.exe
+	$(CXX) $(CXXFLAGS) $(LIB_OBJS) sgdisk.o gptcl.o $(LDFLAGS) $(LDLIBS) -lpopt -lintl -liconv -o sgdisk64.exe
 
 fixparts: $(MBR_LIB_OBJS) fixparts.o
 	$(CXX) $(CXXFLAGS) $(MBR_LIB_OBJS) fixparts.o $(LDFLAGS) -o fixparts64.exe
-- 
2.25.1

[Gptfdisk-general] [PATCH 06/15] makefile: Add "-O2" compiler flag for linux/freebsd builds

[Bin M. <bme...@gm...>]

At present the makefiles for linux/freebsd builds don't use the "-O2"
compiler flag, while other platform builds do.

Let's add it to keep consistency with others.

Signed-off-by: Bin Meng <bme...@gm...>
---

 Makefile         | 4 ++--
 Makefile.freebsd | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 58e9d2d..d1ac530 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
-#CXXFLAGS+=-Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16
-CXXFLAGS+=-Wall -D_FILE_OFFSET_BITS=64
+#CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16
+CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64
 LDFLAGS+=
 LIB_NAMES=crc32 support guid gptpart mbrpart basicmbr mbr gpt bsd parttypes attributes diskio diskio-unix
 MBR_LIBS=support diskio diskio-unix basicmbr mbrpart
diff --git a/Makefile.freebsd b/Makefile.freebsd
index 13fc0fb..c0dd416 100644
--- a/Makefile.freebsd
+++ b/Makefile.freebsd
@@ -1,6 +1,6 @@
 CXX=clang++
-#CXXFLAGS+=-Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16 -I/usr/local/include
-CXXFLAGS+=-Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include 
+#CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64 -D USE_UTF16 -I/usr/local/include
+CXXFLAGS+=-O2 -Wall -D_FILE_OFFSET_BITS=64 -I /usr/local/include 
 LDFLAGS+=
 LIB_NAMES=crc32 support guid gptpart mbrpart basicmbr mbr gpt bsd parttypes attributes diskio diskio-unix
 MBR_LIBS=support diskio diskio-unix basicmbr mbrpart
-- 
2.25.1