GPT fdisk (aka gdisk, cgdisk, and sgdisk) and FixParts
by Roderick W. Smith, rodsmith@rodsbooks.com

Introduction
------------

This package includes the source code for four related disk partitioning
programs:

- gdisk -- This program is modeled after Linux fdisk, but it operates on
  GUID Partition Table (GPT) disks rather than the Master Boot Record (MBR)
  disks that fdisk modifies. As such, gdisk is an interactive text-mode
  tool for manipulating partitions, but it does nothing to the contents of
  those partitions (usually filesystems, but sometimes swap space or other
  data).

- cgdisk -- This program is modeled after Linux cfdisk, but it operates on
  GPT disks rather than the MBR disks that cfdisk modifies. As such, cgdisk
  is a curses-based text-mode tool for manipulating partitions, which is to
  say that it uses an interface that relies on arrow keys and a dynamic
  display rather than the command letters and a scrolling display like
  gdisk uses.

- sgdisk -- This program is conceptually similar to the Linux sfdisk and
  FreeBSD gpt programs, but its operational details differ. It enables
  manipulation of GPT disks using command-line options, so it's suitable
  for use in scripts or by experts to perform specific tasks that might
  take several commands in gdisk to accomplish.

- fixparts -- This program, unlike the preceding three, operates on MBR
  disks. It's intended to fix certain problems that can be created by
  various utilities. Specifically, it can fix mis-sized extended partitions
  and primary partitions located in the middle of extended partitions. It
  also enables changing primary vs. logical partition status (within limits
  of what's legal in the MBR scheme) and making a few other minor changes.
  It does NOT support creating new partitions; for that, you should use
  fdisk, parted, or some other tool.

More details about the abilities of these tools follows.

All four programs rely on the same set of underlying code base; they differ
only in their control interfaces (defined in gdisk.cc, cgdisk.cc,
sgdisk.cc, and fixparts.cc, respectively) and in which support code they
use.

GPT fdisk (gdisk, cgdisk, and sgdisk) Details
---------------------------------------------

The gdisk program is intended as a (somewhat) fdisk-workalike program for
GPT-partitioned disks, cgdisk is similarly a workalike for fdisk, and
sgdisk provides most of gdisk's functionality in a more script-friendly
program. Although libparted and programs that use it (GNU Parted, gparted,
etc.) provide the ability to handle GPT disks, they have certain
limitations that gdisk overcomes. Specific advantages of gdisk, cgdisk, and
sgdisk include:

* The ability to convert MBR-partitioned disks in-place to GPT format,
  without losing data

* The ability to convert BSD disklabels in-place to create GPT
  partitions, without losing data

* The ability to convert from GPT format to MBR format without data loss
  (gdisk and sgdisk only)

* More flexible specification of filesystem type code GUIDs, which
  GNU Parted tends to corrupt

* Clear identification of the number of unallocated sectors on a
  disk

* A user interface that's familiar to long-time users of Linux
  fdisk and cfdisk (gdisk and cgdisk only)

* The MBR boot loader code is left alone

* The ability to create a hybrid MBR, which permits GPT-unaware OSes to
  access up to three GPT partitions on the disk (gdisk and sgdisk only)

Of course, GPT fdisk isn't without its limitations. Most notably, it lacks
the filesystem awareness and filesystem-related features of GParted. You
can't resize a partition's filesystem or create a partition with a
filesystem already in place with gdisk, for instance. There's no GUI
version of gdisk.

The GPT fdisk package provides three program files: the interactive
text-mode gdisk, the curses-based interactive cgdisk, and the
command-line-driven sgdisk. The first two are intended for use in manually
partitioning disks or changing partitioning details; sgdisk is intended for
use in scripts to help automate tasks such as disk cloning or preparing
multiple disks for Linux installation.

FixParts Details
----------------

This program's creation was motivated by cries for help I've seen in online
forums from users who have found their partition tables to be corrupted by
various buggy partitioning tools. Although most OSes can handle the
afflicted disks fine, libparted-based tools (GParted, parted, most Linux
installers, etc.) tend to flake out when presented with these disks.
Typically, the symptom is a disk that appears to hold no partitions;
however, sometimes the libparted tool presents partitions other than those
that the OS sees.

I've observed four causes of these symptoms, three of which FixParts can
correct:

* Old GPT data -- If a disk is used as a GPT disk and then re-used as an
  MBR disk, the GPT data may be incompletely erased. This happens if the
  disk is repartitioned with fdisk or the Microsoft Windows installer, for
  instance. (Tools based on libparted correctly remove the old GPT data
  when converting from GPT to MBR format.) FixParts checks for this problem
  when it starts and offers to correct it. If you opt to erase the GPT
  data, this erasure occurs immediately, unlike other changes the program
  makes.

* Mis-sized extended partitions -- Some tools create an extended partition
  that's too large, typically ending after the last sector of the disk.
  FixParts automatically corrects this problem (if you use the 'w' option
  to save the partition table).

* Primary partitions inside an extended partition -- Some utilities create
  or move primary partitions to within the range covered by the extended
  partition. FixParts can usually correct this problem by turning the
  primary partition into a logical partition or by changing one or more
  other logical partitions into primaries. Such corrections aren't always
  possible, though, at least not without deleting or resizing other
  partitions.

* Leftover RAID data -- If a disk is used in a RAID array and then re-used
  as a non-RAID disk, some utilities can become confused and fail to see
  the disk. FixParts can NOT correct this problem. You must destroy the old
  RAID data, or possibly remove the dmraid package from the system, to fix
  this problem.

When run, FixParts presents an fdisk-like interface, enabling you to adjust
partition types (primary, logical, or omitted), change type codes, change
the bootable flag, and so on. Although you can delete a partition (by
omitting it), you can't create new partitions with the program. If you're
used to partitioning disks, particularly with Linux fdisk, two unusual
features of FixParts require elaboration:

* No extended partitions -- Internally, FixParts reads the partition table
  and discards data on any extended partition(s) it finds. When you save
  the partition table, the program generates a new extended partition. This
  design means that the program automatically corrects many problems
  related to the extended partition. It also means that you'll see no
  evidence of extended partitions in the FixParts user interface, although
  it keeps track of the requirements and prevents you from creating illegal
  layouts, such as a primary between two logicals.

* Partition numbering -- In most Linux tools, partitions 1-4 are primaries
  and partitions 5 and up are logicals. Although a legal partition table
  loaded into FixParts will initially conform to this convention, some
  types of damaged table might not, and various changes you make can also
  cause deviations. When FixParts writes the partition table, its numbering
  will be altered to conform to the standard MBR conventions, but you
  should use the explicit labeling of partitions as primary or logical
  rather than the partition numbers to determine a partition's status.

Installing
----------

To compile GPT fdisk, you must have appropriate development tools installed,
most notably the GNU Compiler Collection (GCC) and its g++ compiler for C++.
I've also tested compilation with Clang, which seems to work; however, I've
not done extensive testing of the resulting binaries, beyond checking a few
basics. See the README.Windows files for additional notes on compiling the
software for Windows. In addition, note these requirements:

* On Linux, FreeBSD, macOS, and Solaris, libuuid must be installed. This is
  the standard for Linux and macOS, although you may need to install a
  package called uuid-dev or something similar to get the headers. On
  FreeBSD, the e2fsprogs-libuuid port must be installed.

* 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 no longer be required. Nonetheless, you can
  use it if you're having problems with the new UTF-16 support. This
  library is normally installed in Linux and macOS, but you may need to
  install the development headers (libicu-dev or something similar in
  Linux; or the libicu36-dev Fink package in macOS). To compile with ICU
  support, you must modify the Makefile: Look for commented-out lines that
  refer to USE_UTF16, -licuuc, -licudata, or -licucore. Uncomment them and
  comment out the equivalents that lack these lines.

* The cgdisk program requires the ncurses library and its development files
  (headers). Most Linux distributions install ncurses by default, but you
  may need to install a package called libncurses5-dev, ncurses-devel, or
  something similar to obtain the header files. On my macOS development
  system, I installed the nurses Homebrew ("brew") package; however, other
  Unix-style software repositories are available and may work for you (see
  the next item). If you're having problems installing ncurses, you can
  compile gdisk and/or sgdisk without cgdisk by specifying only the targets
  you want to compile to make.

* The sgdisk program requires the popt library and its development files
  (headers). Most Linux distributions install popt by default, but you may
  need to install a package called popt-dev, popt-devel, or something
  similar to obtain the header files. MacOS users can find a version of
  popt for Mac OS from Darwin Ports (http://popt.darwinports.com), MacPorts
  (https://trac.macports.org/browser/trunk/dports/devel/popt/Portfile), Fink
  (http://www.finkproject.org), or brew (http://macappstore.org/popt/);
  however, you'll first need to install the relevant environment
  (instructions exist on the relevant projects' pages). When I re-built my
  Mac build environment in February of 2020, I found that brew was, by far,
  the easiest of these to install. Some of the others seem to have been
  abandoned, but I didn't investigate thoroughly. I'm leaving the references
  in case they might be useful in the future. Instead of installing one of
  These ports, you can compile gdisk and/or cgdisk alone, without sgdisk;
  gdisk and cgdisk don't require popt.

When all the necessary development tools and libraries are installed, you
can uncompress the package and type "make" at the command prompt in the
resulting directory. (Beginning with version 1.0.9, GPT fdisk provides a
consolidated Makefile for all supported OSes. Earlier versions used
OS-specific Makefiles, such as Makefile.mac and Makefile.freebsd, which are
still provided, but are deprecated.) You must use GNU make (gmake on
FreeBSD) with this Makefile. You may also need to add header (include)
directories or library directories by setting the CXXFLAGS environment
variable or by editing the Makefile. The result should be program files
called gdisk, cgdisk, sgdisk, and fixparts (or variants with "32.exe" or
"64.exe" added for Windows binaries). Typing "make gdisk", "make cgdisk",
"make sgdisk", or "make fixparts" will compile only the requested programs.
You can use these programs in place or copy the files to a suitable
directory, such as /usr/local/sbin. You can copy the man pages (gdisk.8,
cgdisk.8, sgdisk.8, and fixparts.8) to /usr/local/man/man8 to make them
available.

Cross-compiling is possible, but is not well-tested, except for compiling
Windows binaries on Linux. (See README.Windows for details.) To
cross-compile, specify the TARGET environment variable when launching make,
as in "TARGET=win64 make" to compile for 64-bit (x86-64, X64, AMD64) Windows
on a non-Windows platform. Supported TARGET values are linux, freebsd,
solaris, macos, win32, and win64.

Caveats
-------

DISK PARTITIONING SOFTWARE IS DANGEROUS! Although the GPT fdisk project has
existed since 2009, I do not claim it is entirely bug-free; in fact a glance
at the revision history shows recent bug fixes. I believe all
data-corruption bugs to be squashed, but I know full well that the odds of
my missing something are high. This is particularly true for large
(over-2TiB) drives and use in exotic environments.

My main development platform is a system running the 64-bit version of
Ubuntu Linux. I've also tested on several other 32- and 64-bit Linux
distributions, Intel-based macOS 10 and 11, 64-bit FreeBSD 7.1, and Windows
7 and 10. Other environments qualify as "exotic," and even macOS and Windows
are borderline exotic in this context, since I use Linux almost exclusively,
and my impression is that GPT fdisk is far more commonly used on Linux than
in other OSes.

Redistribution
--------------

This program is licensed under terms of the GNU GPL (see the file COPYING).

Acknowledgements
----------------

This code is mostly my own; however, I've used three functions from two
other GPLed programs:

- The code used to generate CRCs is taken from the efone program by
  Krzysztof Dabrowski and ElysiuM deeZine. (See the crc32.h and
  crc32.cc source code files.)

- A function to find the disk size is taken from Linux fdisk by A. V. Le
  Blanc. This code has subsequently been heavily modified.

Additional code contributors include:

- Yves Blusseau (1otnwmz02@sneakemail.com)

- David Hubbard (david.c.hubbard@gmail.com)

- Justin Maggard (justin.maggard@netgear.com)

- Dwight Schauer (das@teegra.net)

- Florian Zumbiehl (florz@florz.de)

- Guillaume Delacour (contributed the gdisk_test.sh script)

README for EFI version of GPT fdisk
===================================

GPT fdisk for EFI is a binary build of gdisk to run as a pre-boot EFI
application. It's OS-independent and may be used to check or recover
partition tables before installing or booting an OS. It may be used to
overcome boot problems caused by partition table damage or to prepare a
partition table prior to installing an OS.

Installing GPT fdisk for EFI
----------------------------

The contents of this archive are:

- COPYING -- The GNU GPL
- gdisk.html -- The gdisk man page, in HTML form
- gdisk_x64.efi -- The gdisk binary, built for EFI (x86-64 CPU)
- NEWS -- The GPT fdisk changelog
- README-efi.txt -- This file
- refind.cer -- The rEFInd public key, .cer (DER) form
- refind.crt -- The rEFInd public key, .crt form

The gdisk_x64.efi binary included here is built using the UEFI GPT fdisk
library (https://sourceforge.net/p/uefigptfdisk/), which is a beta-level
partial C++ library for UEFI. To use it, you must copy it to your EFI
System Partition (ESP) or some other EFI-accessible location. Under Linux,
the ESP is usually one of the first two or three partitions on /dev/sda.
Under OS X, it's usually the first partition on /dev/disk0 (that is,
/dev/disk0s1). Under Windows, you can mount it to S: by typing "mountvol S:
/S" in an Administrator command prompt. In any of these cases, the
recommended location for gdisk_x64.efi is the EFI/tools directory on the
ESP. In that location, my rEFInd boot manager will detect the gdisk binary
and create a menu option to launch it. If you don't use rEFInd, you can
launch the program using an EFI shell, register it as a boot program with
your firmware, or configure your boot manager (GRUB, gummiboot, etc.) to
launch it. Note that boot LOADERS, such as SYSLINUX and ELILO, can't launch
gdisk.

Alternatively, you can create a USB flash drive that will launch gdisk when
you boot from it. To do so, create a FAT filesystem on a partition on a USB
flash drive and copy gdisk_x64.efi to it as EFI/BOOT/bootx64.efi. (You'll
need to create the EFI/BOOT directory.) Some systems may require the FAT
filesystem to be flagged as an ESP (with a type code of EF00 in gdisk). You
can use your firmware's built-in boot manager to boot from the USB flash
drive. Some such boot managers present two options for booting USB flash
drives. If yours does this, select the option that includes the string
"UEFI" in the description.

The gdisk_x64.efi binary is signed with the rEFInd Secure Boot key. Thus,
if you're launching a rEFInd that I've compiled and distributed myself,
gdisk should launch, too. If you're *NOT* running rEFInd but ARE using
Shim, you'll need to add the refind.cer file to your MOK list by using the
MokManager utility. If you're using Secure Boot and you've signed rEFInd
yourself, you'll need to sign gdisk_x64.efi yourself, too. Note that the
rEFInd PPA distributes unsigned binaries and signs them with a local key
stored in /etc/refind/keys. To copy and sign the gdisk_x64.efi binary, you
should type (as root or using sudo):

sbsign --key /etc/refind.d/keys/refind_local.key \
  --cert /etc/refind.d/keys/refind.crt \
  --output /boot/efi/EFI/tooks/gdisk_x64.efi ./gdisk_x64.efi

This command assumes you have local rEFInd keys stored in the locations
created by the rEFInd installation script. Substitute your own keys if
you've built them in some other way. Some distributions don't provide the
sbsign binary, so you may need to build it yourself. See the following page
for details:

https://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/

Note that you do *NOT* need to sign gdisk if your computer doesn't use
Secure Boot or if you've disabled this feature.

Using gdisk for EFI
-------------------

The EFI version of gdisk is basically the same as using the Linux, OS X, or
other OS versions. One exception is that you do not specify a disk device
on the command line; gdisk for EFI instead displays a list of devices when
you launch and enables you to select one, as in:

List of hard disks found:
 1: Disk EFI_HANDLE(3EB5DD98): 108423424 sectors, 51.7 GiB
    Acpi(PNP0A03,0)/Pci(1|1)/Ata(Primary,Master)
 2: Disk EFI_HANDLE(3EB58289): 105456768 sectors, 50.3 GiB
    Acpi(PNP0A03,0)/Pci(D|0)?

Disk number (1-2): 2

Once you've selected your disk, it should operate in much the same way as
any other version of gdisk. (See the next section, though!) Some programs,
including my rEFInd boot manager, complain about the changed partition
table, even if you've made no changes. If you run into problems using other
programs or launching an OS immediately after running gdisk, reboot; that
should cause the firmware to re-load its partition table.

Caveats
-------

I've tested gdisk_x64.efi on several systems. It's worked fine for me on 4
of 6 computers (5 of 7, counting VirtualBox). Two systems gave me problems,
though:

* gdisk presented a never-ending list of options (as if receiving a
  never-ending string of "?" or other unrecognized command characters) on a
  2014 MacBook Air.
* A computer based on an Intel DG43NB motherboard rebooted as soon as I
  launched gdisk.

Both computers have relatively old EFIs. (Despite its newness, the Mac has
a 1.10 EFI, as do all Macs, to the best of my knowledge.) Most of the
computers that worked had 2.31 EFIs, although one had a 2.10 EFI.

The bottom line is that I can't guarantee that this binary will work on all
computers. It's conceivable that recompiling gdisk with the latest version
of the UEFI GPT fdisk library will help. Also, I haven't compiled a 32-bit
version, so if you have a 32-bit EFI, you'll have to compile it yourself or
do without.

References
----------

The following sites have useful additional information:

UEFI GPT fdisk:
https://sourceforge.net/projects/uefigptfdisk/

sbsigntools git repository:
https://git.kernel.org/cgit/linux/kernel/git/jejb/sbsigntools.git/

rEFInd:
http://www.rodsbooks.com/refind/

GPT fdisk (aka gdisk) and FixParts

by Roderick W. Smith, rodsmith@rodsbooks.com

******************************** IMPORTANT ********************************
Most versions of Windows cannot boot from a GPT disk on BIOS-based
computers, and most varieties prior to Vista cannot read GPT disks. GPT
fdisk is a partition editor for GPT disks, and it will *AUTOMATICALLY
CONVERT* MBR disks to GPT form. Therefore, you should **NOT** use GPT fdisk
on a Windows system unless you fully understand what you're doing or are
certain that your computer boots in EFI/UEFI mode! If you accidentally use
GPT fdisk on a BIOS-mode boot disk, or perhaps even on a data disk, you may
find recovery to be very difficult! Pre-installed Windows 8 and later
systems almost always use GPT disks and boot in EFI/UEFI mode, but
self-installed Windows 8 systems sometimes use BIOS mode. This caveat does
not apply to FixParts, though; that tool works only on MBR disks.
***************************************************************************

Read the main README file for general information on the program, and read
the gdisk.html or fixparts.html documents (the Linux man pages converted to
HTML format) for detailed use information. My GPT fdisk Web page,
http://www.rodsbooks.com/gdisk/, provides a more tutorial introduction to
the software. I originally wrote GPT fdisk on Linux, and some Linux- and
Unix-centric language remains in the documentation.

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 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
binaries work fine on most versions of Windows, but some 64-bit
installations of Windows 8 lack 32-bit support libraries and so may need
the 64-bit binaries.

The FixParts program (fixparts32.exe and fixparts64.exe) is new with GPT
fdisk 0.7.0. As described in the main README file, this program fixes
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, cgdisk32.exe, sgdisk32.exe
and fixparts32.exe (or gdisk64.exe, cgdisk64.exe, sgdisk64.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 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
"Run as Administrator." If you use a non-Administrator Command Prompt, you
won't be able to edit hard disk partition tables, although you will be able
to edit raw disk image files.

The program requires a hard disk identifier as an option. You can specify
this in either of two forms. The first way is as a number followed by a
colon, as in:

gdisk 0:

Disks are numbered starting from 0, so the preceding command launches gdisk
on the first disk. The second way to specify a disk device is via a
harder-to-remember name:

gdisk32 \\.\physicaldrive0

This command is equivalent to the earlier one -- it edits the partition
table on the first physical disk. Change the number at the end of the
device name to change the disk edited.

If you pass the "-l" option to gdisk64.exe in addition to the disk
identifier, the program displays the current partition table information and
then exits. (Alternatively, you can pass "-p" to sgdisk64.exe.) This use
entails no risk to MBR disks, since the program never writes data back to
the disk when used in this way.

As noted above, editing the first disk with GPT fdisk is a Bad Idea on older
BIOS-based computers. Newer computers typically use an Extensible Firmware
Interface (EFI) and boot from GPT disks. It's safer to edit non-boot disks,
which usually have numbers of 1 and above, but only if you run a version of
Windows with GPT support. For more information on Windows' support of GPT,
see Microsoft's Web page on the topic:

http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx

The Windows binaries I've compiled do not support Unicode UTF-16LE GPT
partition names. This feature was added to version 0.7.1 of the software
for Linux, FreeBSD, and OS X, and with changes to some #ifndef lines in the
source files, it can be compiled for Windows; however, it seems to do
little good in Windows because of Command Prompt window and/or ICU library
limitations. Thus, I've omitted this support in the interests of
simplifying the binary distribution, since including it would mean
distributing the ICU libraries.

Source Code and Compilation Issues
----------------------------------

I have successfully compiled GPT fdisk using three different Windows
compilers:

- MinGW (https://www.mingw-w64.org/), using either a Linux-hosted
  cross-compiler or under Windows using the original MinGW or MSYS2
  (https://www.msys2.org). This is my only GPT fdisk development environment
  for Windows in 2022.

- Microsoft Visual C++ 2008 Express
  (http://www.microsoft.com/express/Windows/) -- This compiler requires a
  third-party stdint.h file (I used the one from
  http://web.archive.org/web/20130317001712/http://msinttypes.googlecode.com/svn/trunk/stdint.h),
  but it otherwise worked fine the last time I tried it. A project is easily
  created by adding all the *.h files and all the *.cc files except
  diskio-unix.cc, sgdisk.cc, and whichever program file you intend to NOT
  build (gdisk.cc or fixparts.cc).

- Microsoft Visual C++ 2010 Express -- This compiler works much like the
  2008 version, although I didn't need to add a third-party stdint.h file.

Although I used Microsoft Visual C++ in the past, I haven't tried using
these compilers recently and so I can't promise they would work today (in
2022).

If you modify GPT fdisk to get it to compile under another compiler, I
welcome submission of patches.

The following instructions focus on use of MinGW to compile GPT fdisk for
Windows.

My primary development environment is Ubuntu Linux, using the MinGW
cross-compiler. This system can compile the gdisk and fixparts binaries with
no need for additional libraries; after installing MinGW (via the
g++-mingw-w64 package in Ubuntu, or the equivalent in another distribution),
you can type "TARGET=win32 make" to compile 32-bit binaries, and
"TARGET=win64 make" to compile 64-bit binaries. This will attempt to build
gdisk, sgdisk, and fixparts; but the sgdisk build will fail until you
install the popt libraries, as described shortly. You can build the other
binaries by specifying them, as in "TARGET=win64 make gdisk" to build the
64-bit gdisk binary alone.

If you use Windows, your best bet is likely to be to install the MSYS2
package (https://www.msys2.org). This package provides MinGW and a package
management system based on pacman (used by Arch Linux) for installing
additional libraries. To install the libraries needed to compile sgdisk and
cgdisk, type "pacman -S mingw-w64-x86_64-popt mingw-w64-x86_64-gettext
mingw-w64-x86_64-ncurses" if you want to compile 64-bit binaries; change
'x86_64' to 'i686' for 32-bit packages. This command will install the popt
library needed by sgdisk and the ncurses library needed by cgdisk, along
with gettext, which is needed by popt. With these libraries installed, you
should be able to compile all four Linux programs -- gdisk, cgdisk, sgdisk,
and fixparts. Typing "make" alone in the MSYS2 shell should build all four
programs for the host architecture (x86-64 or i686); to compile for the
other architecture, you must specify it with a "TARGET=" specification, as
under Linux. (The Makefile does not currently support ARM64 targets for
Windows.)

If you want to compile sgdisk for Windows under Linux, you can do so;
however, you must copy the relevant header and library files from a Windows
installation to Linux. Specifically, you must copy:

    Windows File                   Linux Directory
    ------------                   ---------------
    /mingw64/include/popt.h        /usr/x86_64-w64-mingw32/include/
    /mingw64/lib/libpopt.a         /usr/x86_64-w64-mingw32/lib/
    /mingw64/lib/libintl.a         /usr/x86_64-w64-mingw32/lib/
    /mingw64/lib/libiconv.a        /usr/x86_64-w64-mingw32/lib/

For 32-bit binaries, change /mingw64 to /mingw32 on the Windows source and
x86_64-w64-mingw32 to i686-w64-mingw32 on the Linux destination.

In theory, you should be able to do something similar to compile cgdisk. The
relevant files are:

    Windows File                            Linux Directory
    ------------                            ---------------
    /mingw64/include/ncursesw/curses.h      /usr/x86_64-w64-mingw32/include/ncursesw/
    /mingw64/include/ncursesw/ncurses.h     /usr/x86_64-w64-mingw32/include/ncursesw/
    /mingw64/include/ncursesw/ncurses_dll.h /usr/x86_64-w64-mingw32/include/ncursesw/
    /mingw64/include/ncursesw/unctrl.h      /usr/x86_64-w64-mingw32/include/ncursesw/
    /mingw64/lib/libncurses.a               /usr/x86_64-w64-mingw32/lib/

In practice, this has not worked for me; the compilation fails with a
complaint about an undefined reference to 'nanosleep'. My guess is that the
ncurses version installed in Windows is too new to work with the MinGW
libraries in Ubuntu (20.04 or 22.04). It's conceivable it would work with
another distribution, though.

The Makefile is configured to create statically-linked binaries so as to
simplify installation of the binaries. If you want smaller binaries, you can
remove the various static options from the Makefile. You can also strip the
binaries ("make strip") to remove unused code.