Configuring GParted on a machine with automake >= 1.14 produces this
warning:
$ ./autogen.sh
...
lib/gtest/Makefile.am:58: warning: source file 'src/gtest-all.cc' is in a subdirectory,
lib/gtest/Makefile.am:58: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
lib/gtest/Makefile.am:60: warning: source file 'src/gtest_main.cc' is in a subdirectory,
lib/gtest/Makefile.am:60: but option 'subdir-objects' is disabled
lib/gtest/Makefile.am: installing './depcomp'
tests/Makefile.am:22: warning: source file '../src/BlockSpecial.cc' is in a subdirectory,
tests/Makefile.am:22: but option 'subdir-objects' is disabled
tests/Makefile.am:23: warning: source file '../src/PipeCapture.cc' is in a subdirectory,
tests/Makefile.am:23: but option 'subdir-objects' is disabled
...
From the automake 1.14 NEWS file:
http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS?h=v1.14#n125
"The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option. In order to smooth out the transition,
we now give a warning (in the category 'unsupported') whenever a
source file is present in a subdirectory but the 'subdir-object' is
not enabled. For example, the following usage will trigger such a
warning:
bin_PROGRAMS = sub/foo
sub_foo_SOURCES = sub/main.c sub/bar.c
"
Set the subdir-objects automake option, silencing the warning.
Bug 781978 - Add Google Test C++ test framework
So far only includes tests of the construction of BlockSpecial objects
and the interaction with the internal cache used to reduce the number of
stat(2) calls. Tests have been designed to be runable by non-root users
and assume as little as possible about the environment by discovering
used block device names and symbolic link name.
Bug 781978 - Add Google Test C++ test framework
Now 'make check' will additionally build and run the test suites in the
./tests directory. Add initial always successful dummy test suite.
This is done using Automake support for testing.
Automake Manual, 15 Support for test suites
https://www.gnu.org/software/automake/manual/automake.html#Tests
./tests/Makefile.am takes some influence from the same file in the
minimal-gtest-autotools template project.
654848ec01/tests/Makefile.am
Bug 781978 - Add Google Test C++ test framework
This closely follows the minimal-gtest-autotools template project.
https://github.com/octol/minimal-gtest-autotools
Now 'make check' will additionally build the Google Test C++ test
framework libraries.
Bug 781978 - Add Google Test C++ test framework
As with glibmm [1] the latest versions of libsigc++ also uses ISO C++
2011 features. The NEWS file [2] says:
2.5.1 (unstable):
* Use (and require) C++11
(Kjell Ahlstedt)
* Using C++11 lambda functions to create sigc::slots:
Avoid the need for SIGC_FUNCTORS_DEDUCE_RESULT_TYPE_WITH_DECLTYPE.
(Kjell Ahlstedt)
Without enabling C++11 compiler features, compilation of GParted with
libsigc++ 2.5.1 and later fails with errors such as theses:
/usr/include/sigc++-2.0/sigc++/trackable.h:40:3: warning: identifier 'noexcept' is a keyword in C++11 [-Wc++0x-compat]
trackable_callback(void* data, func_destroy_notify func) noexcept
^
[1] d6d7cb2bbf
Enable C++11 compilation when using glibmm 2.45.40 and later (#756035)
[2] libsigc++ 2.5.1 NEWS file
https://git.gnome.org/browse/libsigcplusplus/tree/NEWS?h=2.5.1
Bug 758545 - gparted-0.24.0 fails to build with gnome 3.18 mm packages
(on Gentoo)
Previously the autoconf check for Gtk::Window::set_default_icon_name()
method was a compile test because the documentation reported the method
was available in gtkmm from 2.6 [1], however it wasn't available on
RHEL / CentOS 5.x with gtkmm 2.10.
Then commit [2] added detection and enabling of C++11 compilation, but
after the above autoconf check. So on Fedora 23 the compiler based
autoconf check for set_default_icon_name() method failed because C++11
compilation had not yet been enabled:
> checking for Gtk::Window::set_default_icon_name method... no
checking for gtk_show_uri function... yes
checking for Gtk::MessageDialog::get_message_area() method... yes
> checking for glibmm >= 2.45.40 which requires C++11 compilation... yes
> checking whether g++ supports C++11 features by default... no
> checking whether g++ supports C++11 features with -std=gnu++11... yes
The gtkmm source code reveals that set_default_icon_name() method was
only added in gtkmm 2.11.1 [3] so switch to a PKG_CHECK_EXISTS for this
version of gtkmm.
[1] gtkmm GTK::Window Class Reference
https://developer.gnome.org/gtkmm/3.6/classGtk_1_1Window.html#a533d03e9b92d8ccd142ab3a44005cae4
[2] Enable C++11 compilation when using glibmm 2.45.40 and later (#756035)
d6d7cb2bbf
[3] gtkmm NEWS file
https://git.gnome.org/browse/gtkmm/tree/NEWS?h=gtkmm-2.14.0#n565
Bug 762184 - Autoconf check for C++11 comes after compile test for
Gtk::Window::set_default_icon_name()
Debian has deprecated the use of bzip2 for tarballs since dpkg-1.17.7,
released 2014-04-21. See:
https://lintian.debian.org/tags/uses-deprecated-compression-for-data-tarball.html
The choices going forward were to use gzip for maximum compatibility and
speed, or to use xz for maximum compression.
Since we strive for backwards compatibility, gzip was chosen.
Bug 760099 - Revert tarball compression to gzip
Glibmm 2.45.40 and later uses features in the ISO C++ 2011 standard.
The NEWS file [1] says:
Changes in 2.46 compared to 2.44:
General:
* Use, and require C++11, using features such as move operations,
noexcept auto, = delete, nulltpr, override.
(Murray Cumming, Kjell Ahlstedt)
Also found this by Murray Cumming [2]:
glibmm 2.45.40 requires C++11, both for its own build and by any
apps that use it. gtkmm also now requires C++11.
I think you are seeing a symptom of building the application without
C++11 support. For instance, using CXXFLAGS="--std=c++11", though
you'd be better of using an m4 macro such as
AX_CXX_COMPILE_STDCXX_11().
Without enabling C++11 compiler features, compilation of GParted with
the latest glibmm library fails with errors such as these:
/usr/include/glibmm-2.4/glibmm/ustring.h:267:14: error: expected ';' at end of member declaration
~ustring() noexcept;
^
/usr/include/glibmm-2.4/glibmm/ustring.h:267:14: error: 'noexcept' does not name a type
~ustring() noexcept;
^
/usr/include/glibmm-2.4/glibmm/ustring.h:267:14: note: C++11 'noexcept' only available with -std=c++11 or -std=gnu++11
[1] glibmm NEWS file
https://git.gnome.org/browse/glibmm/tree/NEWS?id=934e8290ce913b12e251ea617d0fc8ac53c385c6
[2] https://bugs.launchpad.net/ubuntu/+source/glibmm2.4/+bug/1478367
Bug 756035 - GParted does not compile with newer gtkmm libraries in
Fedora 23
When configuring GParted build with libparted from GIT it may perform
the version compares incorrectly and think the version of libparted is
higher that it actually is. Libparted uses the number of commits from
the last git tag as the third part of the version number.
For example install libparted from one commit before release 3.1, 142
commits after release 3.0.
$ git checkout v3.1^
$ describe
v3.0-142-g82327a3
$ ./bootstrap
$ ./configure --prefix=/tmp/parted-3.0-git
$ make && make install
Configure GParted:
$ export CPPFLAGS=-I/tmp/parted-3.0-git/include
$ export LDFLAGS=-L/tmp/parted-3.0-git/lib
$ export LD_RUN_PATH=/tmp/parted-3.0-git/lib
$ export PKG_CONFIG_PATH=/tmp/parted-3.0-git/lib/pkgconfig
$ ./configure
...
checking for libparted >= 1.7.1 (querying pkg-config)... 3.0.142-8232
checking for 2.0 <= libparted <= 3.0 (loop table creation doesn't delete old partitions)... (cached) no
checking for libparted >= 2.2 (improved pt re-read)... (cached) yes
checking for ped_file_system_resize in -lparted... no
checking for ped_file_system_resize in -lparted-fs-resize... yes
checking for libparted >= 3.2 (online resize)... (cached) no
...
Libparted is reported as version 3.0.142, but checking of the version
between 2.0 and 3.0 inclusive fails.
The configure script is multiplying components of the version by 100
when adding them together.
$ echo 3.0.142-8232 | awk -F. '{print $1 * 10000 + $2 * 100 + $3}'
30142
So it is only allowing up to 99 commits before it is equivalent to the
second minor number increasing by one. Increase the multiplication
factor to 10000, allowing up to 9999 commits between releases. An order
of magnitude more commits than so far seen between parted releases.
Bug 753525 - Configuration issues when using non-system location or
non-released versions of libparted
When the following conditions were met GParted would fail to recognise a
newly created whole disk device file system, and instead show an unknown
file system filling the disk:
1) Disk was previously partitioned and contained at least one partition.
2) Using libparted version 2.0 to 3.0 inclusive.
Initial status:
# blkid | fgrep sdc
# fgrep sdc /proc/partitions
8 32 976762584 sdc
8 33 104857600 sdc1
# parted /dev/sdc
GNU Parted 2.4
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 107GB 107GB primary
When creating the loop partition table libparted would not inform the
kernel to delete the old partitions. /proc/partitions still contained
the details of the old partitions.
(parted) mktable loop
Warning: The existing disk label on /dev/sdc will be destroyed and
all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
(parted) print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Number Start End Size File system Flags
(parted) quit
# fgrep sdc /proc/partitions
8 32 976762584 sdc
8 33 104857600 sdc1
Creation of the whole disk device file system goes unnoticed by blkid
because the kernel and therefore blkid's cache have stale partition
information.
# mkfs.xfs -f /dev/sdc
# blkid | fgrep sdc
NOTE:
On a Linux Software RAID array, as opposed to a hard disk, blkid does
notice creation of the whole disk device file system. However the
kernel still has old partition details.
This was fixed in libparted 3.1 by commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=f5c909c0cd50ed52a48dae6d35907dc08b137e88
libparted: remove has_partitions check to allow loopback partitions
Fix by deleting old partitions before creating the loop table when
compiled with a broken version of libparted. The GParted UI provides
no feedback while a new partition table is created, and with some
versions of GTK the UI become unresponsive too, so it is important to be
as fast as possible. Evaluated three different methods, deleting 15 and
22 MSDOS partitions on a physical 5400 RPM hard drive using libparted
2.4:
M1) Delete and commit one partition at a time.
Takes up to 24 seconds to delete 15 partitions. With 22 partitions
libparted always reports finding some of the partitions busy and
unable to inform the kernel about the modifications.
Too slow and doesn't work.
M2) Delete all partitions in one go and commit once.
Takes up to 1.4 seconds to delete either 15 or 22 partitions. Never
removes partitions 17 and higher from the kernel.
Doesn't work.
M3) Write GPT table (letting libparted delete any old partitions).
Takes up to 0.8 seconds to delete either 15 or 22 partitions.
Fast and works.
Use method 3 - write a GPT table thus using libparted code to inform the
kernel of the old partition deletions.
Bug 743181 - Add unpartitioned drive read-write support
The GNOME Logo & Trademarks page
(http://www.gnome.org/logo-and-trademarks/) says:
* All the letters in "GNOME" should be capitalized.
Also correctly capitalise the program name as GNOME Partition Editor in
the Manual, and gparted.doap file (used in web git browser).
Bug 739805 - GNOME is incorrectly capitalised on the website and else
where
First use of PKG_CHECK_EXISTS causes additional checking messages to be
reported which splits the libparted version check message from it's
result, like this:
checking for libparted >= 1.7.1 (querying pkg-config)... checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
2.3
Call PKG_CHECK_EXISTS early, before first use to avoid this. Output
now looks like:
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
:
checking for libparted >= 1.7.1 (querying pkg-config)... 2.3
Bug 740004 - use pkg-config to check for version of libparted
Currently ./configure links and runs a program to query the libparted
library version, which is used to determine the availability of some
features. This makes cross-compiling harder because the compile host
has to fake a virtual installation target in which to run the check.
Because of this, pkg-config based Autoconf checks are preferred.
Switch to using a pkg-config based Autoconf check first to determine the
version of libparted, falling back to the previous method for older
distributions which don't provide a pkg-config file for libparted.
Also small comment tidy-up elsewhere.
Bug 740004 - use pkg-config to check for version of libparted
Use AC_ARG_ENABLE() and AS_HELP_STRING() macros to improve handling of
the --disable-doc option.
Change the names, and sence, of the Autoconf and Automake definitions
used to control building of the help documentation. Reasons are:
(1) Switch from negative to positive statements which are more natural
to comprehend.
(2) Insert HELP in the names from *_DOC to *_HELP_DOC as they control
building of the documentation in the help subdirectory, not the
manual page in the doc directory.
Autoconf: HAVE_DISABLE_DOC -> ENABLE_HELP_DOC
Automake: DISABLE_DOC -> BUILD_HELP_DOC
Bug #734076 - Autodetect parted online partition resizing capability
Use AC_ARG_ENABLE() Autoconf macro to set enable_libparted_dmraid
variable to either yes or no in all cases, whether set on the command
line or not. Use AS_HELP_STRING() macro to format the option help text.
Bug #734076 - Autodetect parted online partition resizing capability
Configure script checks for libparted version >= 3.2 to automatically
determine the availability of online resize capability in libparted.
This can be overridden from the ./configure command line. Override
enable when an older version of libparted has been patched to include
online resize support with:
./configure --enable-online-resize
Override disable with libparted 3.2 or later to disable the feature when
it is not wanted with:
./configure --disable-online-resize
Note that GParted also requires, and checks for at runtime, Linux
kernel >= 3.6 for online resize support. See commit for more details:
de2844d02d
Add online resize support (#694622)
Bug #734076 - Autodetect parted online partition resizing capability
Currently -lparted is passed to the linker by being hard coded in the
gpartedbin_LDFLAGS variable in src/Makefile.am and -lparted-fs-resize
by conditionally being appended to the gpartedbin_LDFLAGS.
Add an Autoconf AC_CHECK_LIB check for the parted library using it's
default action-if-found to extend LIBS. Update the existing
AC_CHECK_LIB check for the parted-fs-resize library so that the
overridden action-if-found also extends LIBS with -lparted-fs-resize.
These libraries are then assigned via the LIBS variable in the
generated Makefiles.
This matches how the other libraries, dl and uuid, were found in the
configure script and passed to the Makefiles.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Configure.ac still builds and runs very similar test executables twice
to determine in the version of libparted is >= minimum require 1.7.1 and
2.2 for improved partition re-read code.
Build and run a single test to determine the version of libparted and
cache the result. Use this cached version number when testing the
version of libparted. Inspired by the version checking for intltool
from /usr/share/aclocal/intltool.m4.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
If ped_file_system_resize() function is found in the parted library
don't bother to go on to check for it in the parted-fs-resize library.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Remove HAVE_LIBPARTED_2_2_0_PLUS definition
Rename version specific #define HAVE_LIBPARTED_2_2_0_PLUS into two
separate feature specific names set as required:
Name Set when?
ENABLE_PT_REREAD_WORKAROUND (libparted < 2.2)
USE_LIBPARTED_LARGE_SECTOR_SUPPORT (libparted >= 2.2)
Using feature specific #defines is the standard Autoconf way and makes
the resultant conditional code easier to understand. Still have to
check the version of libparted though.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Replace Autoconf check for libparted >= 3.0
Currently uses a custom check which compiles an executable to check for
libparted version >= 3.0 to determine if the ped_file_system_resize()
function exists in the parted library.
Change to use a direct Autoconf check to determine the availability of
the ped_file_system_resize() function in the parted library.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Remove HAVE_LIBPARTED_3_0_0_PLUS definition
The #define only controls whether fat16 and fat32 file systems are moved
by libparted (for versions <= 2.4) or the GParted internal algorithm
(for libparted versions >= 3.0). See this commit for more details:
0fda1d011d
Enable new fs resize library available with parted-3.1 (#668281)
As nearly all other file system are moved using the GParted internal
algorithm, just always use it to move fat16 and fat32 file systems too.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Remove HAVE_LIBPARTED_3_1_0_PLUS definition and replace Autoconf
check for libparted >= 3.1
Currently uses custom check which compiles an executable to check for
libparted version >= 3.1 to determine the availability of the library
parted-fs-resize and the need to include the header <parted/filesys.h>.
Change to use a direct Autoconf check to determine the availability of
the ped_file_system_resize() function in the parted-fs-resize library.
Remove inclusion of the header <parted/filesys.h> as it has always been
included via <parted/parted.h>, at least as far back as parted 1.8.0,
and even in parted 3.0 when ped_file_system_resize() and libparted file
system resize capability didn't exist.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
AM_PROG_LIBTOOL is an old name and alias for AC_PROG_LIBTOOL. Update.
NOTE:
In turn AC_PROG_LIBTOOL is an old name and alias for LT_INIT, but
CentOS 5.x with libtool 1.5.22 doesn't have LT_INIT defined in
/usr/share/aclocal/libtool.m4 serial 48, only AC_PROG_LIBTOOL and
AM_PROG_LIBTOOL. Therefore only update to AC_PROG_LIBTOOL and not
LT_INIT while CentOS 5.x is supported.
Bug #734718 - Update Autoconf version specific libparted checks and
defines to feature specific ones
Currently ./configure passes successfully even if a C++ compiler is not
installed. The first time building the code fails is when make tries
to compile the first C++ source file and the compiler executable is not
found.
Also because there is no C++ compiler the autoconf generated test for
Gtk::Window::set_default_icon_name() will always fail, leaving
HAVE_SET_DEFAULT_ICON_NAME unset. Therefore as well as installing a
C++ compiler, ./configure must be run again to correctly test for
set_default_icon_name().
This is as a result of a little known consequence of having AC_PROG_CC
proceed AC_PROG_CXX in the autoconf file configure.ac.
Subject: AC_PROG_CXX behaviour when no C++ compiler is found
http://lists.gnu.org/archive/html/bug-autoconf/2010-05/msg00001.html
Reverse the order, placing AC_PROG_CXX before AC_PROG_CC, so that the
generated ./configure script fails with an error if there is no C++
compiler available.
Bug #732803 - ./configure is successful even when C++ compile is missing
Mike Fleetwood