On Debian/Ubuntu systems, if autoconf version 2.13 is installed,
autoconf will try to automatically figure out whether autoconf 2.13 or
something more modern is required (since the autoconf maintainers,
curses be upon them, didn't bother to maintain compatibility between
autoconf 2.13 and 2.50). Unfortunately, the hueristics aren't
perfect, and although the configure.in file looks superficially like
it will be compatible with autoconf 2.13, it isn't. You will end up
with a number of very subtle compilation failures if you use autoconf
2.13.
So declare a requirement for autoconf 2.50 using AC_PREREQ(2.50).
Signed-off-by: "Theodore Ts'o" <[email protected]>
---
configure.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 10c4c61..664c0e9 100644
--- a/configure.in
+++ b/configure.in
@@ -1,4 +1,5 @@
AC_INIT(include/libxfs.h)
+AC_PREREQ(2.50)
AC_CONFIG_AUX_DIR([.])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADER(include/platform_defs.h)
--
1.7.4.1.22.gec8e1.dirty
The tree currently will blow out with a build failure if -DDEBUG is
specified.
Signed-off-by: "Theodore Ts'o" <[email protected]>
---
m4/package_globals.m4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/m4/package_globals.m4 b/m4/package_globals.m4
index e469671..d2a3e2f 100644
--- a/m4/package_globals.m4
+++ b/m4/package_globals.m4
@@ -17,7 +17,7 @@ AC_DEFUN([AC_PACKAGE_GLOBALS],
test -z "$BUILD_VERSION" || pkg_release="$BUILD_VERSION"
AC_SUBST(pkg_release)
- DEBUG=${DEBUG:-'-DDEBUG'} dnl -DNDEBUG
+ DEBUG=${DEBUG:-'-DNDEBUG'} dnl -DNDEBUG
debug_build="$DEBUG"
AC_SUBST(debug_build)
--
1.7.4.1.22.gec8e1.dirty
The order in which libraries are searched matters if you are using
static libraries. Since libblkid uses some functions from libuuid, it
needs to come before libuuid in the link line.
Signed-off-by: "Theodore Ts'o" <[email protected]>
---
mkfs/Makefile | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/mkfs/Makefile b/mkfs/Makefile
index 8b61c2f..75da633 100644
--- a/mkfs/Makefile
+++ b/mkfs/Makefile
@@ -11,10 +11,6 @@ FSTYP = fstyp
HFILES = xfs_mkfs.h
CFILES = maxtrres.c proto.c xfs_mkfs.c
-LLDLIBS = $(LIBXFS) $(LIBUUID) $(LIBRT) $(LIBPTHREAD)
-LTDEPENDENCIES = $(LIBXFS)
-LLDFLAGS = -static
On Thu, Jul 21, 2011 at 07:50:36PM -0400, Theodore Ts'o wrote:
> The tree currently will blow out with a build failure if -DDEBUG is
> specified.
This still doesn't make sense to me. libxfs explicily overrides
DEBUG in the makefile:
# don't try linking xfs_repair with a debug libxfs.
DEBUG = -DNDEBUG
we really need to figure out why your enviroment doesn't pick this
up, especially as we've never seen that report from anybody else.
On Thu, Jul 21, 2011 at 07:50:35PM -0400, Theodore Ts'o wrote:
> On Debian/Ubuntu systems, if autoconf version 2.13 is installed,
> autoconf will try to automatically figure out whether autoconf 2.13 or
> something more modern is required (since the autoconf maintainers,
> curses be upon them, didn't bother to maintain compatibility between
> autoconf 2.13 and 2.50). Unfortunately, the hueristics aren't
> perfect, and although the configure.in file looks superficially like
> it will be compatible with autoconf 2.13, it isn't. You will end up
> with a number of very subtle compilation failures if you use autoconf
> 2.13.
>
> So declare a requirement for autoconf 2.50 using AC_PREREQ(2.50).
Thanks a lot, I've applied our xfsprogs and xfstests patches, and also
ported the change to the xfsdump and dmapi repositories.
On Thu, Jul 21, 2011 at 07:50:37PM -0400, Theodore Ts'o wrote:
> The order in which libraries are searched matters if you are using
> static libraries. Since libblkid uses some functions from libuuid, it
> needs to come before libuuid in the link line.
Thanks, applied.
On Fri, Jul 22, 2011 at 10:17:53AM -0400, Christoph Hellwig wrote:
> On Thu, Jul 21, 2011 at 07:50:36PM -0400, Theodore Ts'o wrote:
> > The tree currently will blow out with a build failure if -DDEBUG is
> > specified.
>
> This still doesn't make sense to me. libxfs explicily overrides
> DEBUG in the makefile:
>
> # don't try linking xfs_repair with a debug libxfs.
> DEBUG = -DNDEBUG
I added some debugging statements in libxfs/Makefile, and found this
(see below).
It looks like the problem is that GNU make 3.81 is doing an immediate
expansion of this line in builddefs:
CFLAGS += $(FCFLAGS) $(GCFLAGS) $(PCFLAGS) $(LCFLAGS)
- Ted
LTCOMPILE is /bin/sh ../libtool --quiet --tag=CC --mode=compile gcc -I/kbuild/xfstests/bld/include -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -I. -g -O2 -DNDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I../include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall
FCFLAGS is -I.
GCFLAGS is -g -O2 -DNDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I../include -DENABLE_GETTEXT
PCFLAGS is -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall
CFLAGS is -I/kbuild/xfstests/bld/include -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -I. -g -O2 -DNDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I../include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall
CCF is gcc -I/kbuild/xfstests/bld/include -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -I. -g -O2 -DNDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I../include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall
On Fri, Jul 22, 2011 at 02:30:48PM -0400, Ted Ts'o wrote:
> I added some debugging statements in libxfs/Makefile, and found this
> (see below).
You can get most of this by simply using make V=1, not just in xfsprogs,
but in most projects using silent make output (including those using
automake)
> It looks like the problem is that GNU make 3.81 is doing an immediate
> expansion of this line in builddefs:
I'm having GNU make 3.81 on most of my test systems as well, so that
alone can't be the whole issue.
> CFLAGS += $(FCFLAGS) $(GCFLAGS) $(PCFLAGS) $(LCFLAGS)
>
> LTCOMPILE is /bin/sh ../libtool --quiet --tag=CC --mode=compile gcc -I/kbuild/xfstests/bld/include -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -g -O2 -DDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I./include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -I. -g -O2 -DNDEBUG -DVERSION="3.1.5" -DLOCALEDIR="//share/locale" -DPACKAGE="xfsprogs" -I../include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall
A typical V=1 compile line looks like:
/bin/bash ../libtool --quiet --tag=CC --mode=compile gcc -I. -g -O2 -DNDEBUG -DVERSION=\"3.1.5\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -DENABLE_GETTEXT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir2_sf.c
for me. The biggest thing is that you have another directory in your
include path. How did you add that one? Did you add anything else
special to the ./configure or make command lines?
On Fri, Jul 22, 2011 at 02:38:30PM -0400, Christoph Hellwig wrote:
>
> You can get most of this by simply using make V=1, not just in xfsprogs,
> but in most projects using silent make output (including those using
> automake)
Yeah, I know about V=1 (and I have been using it), but I wanted to
know which of the many Makefile variables which finally make up
$(CFLAGS) was getting set to which value, and V=1 doesn't do this.
> for me. The biggest thing is that you have another directory in your
> include path. How did you add that one? Did you add anything else
> special to the ./configure or make command lines?
Yes I needed it because I wanted to do a hermetic build; that is, I
didn't want to depend on the version of the acl, attr, dmapi, etc.,
shipped by the distribution. (This is actually more important when
building xfstests, since I wanted to make sure we used the version of
the xfsprogs headers shipped by the very tip of xfsprogs-dev, since in
the past I've had problems because the distro-shipped header files
were too old.)
The way I did that was by setting the environment CFLAGS to
-I/kbuild/xfstests/bld/include. And that seems to be the problem. If
CFLAGS is set as an environment variable, then it's set as a :=, which
means that CFLAGS is set right away, the first time buildmacros is
included.
How about this instead? A patch like this so that CFLAGS can be
remembered at configure time:
diff --git a/include/builddefs.in b/include/builddefs.in
index 4c8ec64..81ebfcd 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -25,6 +25,7 @@ OPTIMIZER = @opt_build@
MALLOCLIB = @malloc_lib@
LOADERFLAGS = @LDFLAGS@
LTLDFLAGS = @LDFLAGS@
+CFLAGS = @CFLAGS@
LIBRT = @librt@
LIBUUID = @libuuid@
Then I don't have to set an environment variable when running make; I
just have to pass it to configure.
- Ted
On Fri, Jul 22, 2011 at 06:34:58PM -0400, Ted Ts'o wrote:
> Yes I needed it because I wanted to do a hermetic build; that is, I
> didn't want to depend on the version of the acl, attr, dmapi, etc.,
> shipped by the distribution. (This is actually more important when
> building xfstests, since I wanted to make sure we used the version of
> the xfsprogs headers shipped by the very tip of xfsprogs-dev, since in
> the past I've had problems because the distro-shipped header files
> were too old.)
Given that you are on a Debian-ish environment, did you consider simply
using pbuilder? I use that regularly to test clean package builds,
without all these weird overrides.
> The way I did that was by setting the environment CFLAGS to
> -I/kbuild/xfstests/bld/include. And that seems to be the problem. If
> CFLAGS is set as an environment variable, then it's set as a :=, which
> means that CFLAGS is set right away, the first time buildmacros is
> included.
>
> How about this instead? A patch like this so that CFLAGS can be
> remembered at configure time:
>
> diff --git a/include/builddefs.in b/include/builddefs.in
> index 4c8ec64..81ebfcd 100644
> --- a/include/builddefs.in
> +++ b/include/builddefs.in
> @@ -25,6 +25,7 @@ OPTIMIZER = @opt_build@
> MALLOCLIB = @malloc_lib@
> LOADERFLAGS = @LDFLAGS@
> LTLDFLAGS = @LDFLAGS@
> +CFLAGS = @CFLAGS@
>
> LIBRT = @librt@
> LIBUUID = @libuuid@
>
> Then I don't have to set an environment variable when running make; I
> just have to pass it to configure.
This looks much better, and is indeed similar to some other fixes we
recently had to put in, probably due to changing make behaviour.
If you add a signoff and a proper description I'll put it into all the
repositories.
On Fri, 2011-07-22 at 14:38 -0400, Christoph Hellwig wrote:
> On Fri, Jul 22, 2011 at 02:30:48PM -0400, Ted Ts'o wrote:
. . .
> A typical V=1 compile line looks like:
>
> /bin/bash ../libtool --quiet --tag=CC --mode=compile gcc -I. -g -O2
> -DNDEBUG -DVERSION=\"3.1.5\" -DLOCALEDIR=\"/usr/share/locale\"
> -DPACKAGE=\"xfsprogs\" -I../include -DENABLE_GETTEXT -D_GNU_SOURCE
> -D_XOPEN_SOURCE=500 -D_FILE_OFFSET_BITS=64 -funsigned-char
> -fno-strict-aliasing -Wall -c xfs_dir2_sf.c
FWIW, I get a compile line for xfs_dir2_sf.c identical to
what Christoph supplied.
> for me. The biggest thing is that you have another directory in your
> include path. How did you add that one? Did you add anything else
> special to the ./configure or make command lines?
On Fri, Jul 22, 2011 at 09:32:14PM -0400, Christoph Hellwig wrote:
> > diff --git a/include/builddefs.in b/include/builddefs.in
> > index 4c8ec64..81ebfcd 100644
> > --- a/include/builddefs.in
> > +++ b/include/builddefs.in
> > @@ -25,6 +25,7 @@ OPTIMIZER = @opt_build@
> > MALLOCLIB = @malloc_lib@
> > LOADERFLAGS = @LDFLAGS@
> > LTLDFLAGS = @LDFLAGS@
> > +CFLAGS = @CFLAGS@
> >
> > LIBRT = @librt@
> > LIBUUID = @libuuid@
> >
> > Then I don't have to set an environment variable when running make; I
> > just have to pass it to configure.
>
> This looks much better, and is indeed similar to some other fixes we
> recently had to put in, probably due to changing make behaviour.
>
> If you add a signoff and a proper description I'll put it into all the
> repositories.
Can you at least provide the signoff? I can take care of the rest if
this means I can get it in ASAP.
On Tue, Jul 26, 2011 at 11:10:33AM -0400, Christoph Hellwig wrote:
> > This looks much better, and is indeed similar to some other fixes we
> > recently had to put in, probably due to changing make behaviour.
> >
> > If you add a signoff and a proper description I'll put it into all the
> > repositories.
>
> Can you at least provide the signoff? I can take care of the rest if
> this means I can get it in ASAP.
Ted,
can you please give me a signoff for this patch? I could probably just
put it in anyway given how trivial it is. But let's just stick to the
proper protocol if we can.
In order to build xfsprogs in a hermetic build, we need be able to
pass in -I and -L flags to the compiler and linker, respectively.
This needs to be used by the configure script, but we also need to
make sure these flags are used by the Makefiles as well.
Signed-off-by: "Theodore Ts'o" <[email protected]>
---
include/builddefs.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/builddefs.in b/include/builddefs.in
index 4c8ec64..81ebfcd 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -25,6 +25,7 @@ OPTIMIZER = @opt_build@
MALLOCLIB = @malloc_lib@
LOADERFLAGS = @LDFLAGS@
LTLDFLAGS = @LDFLAGS@
+CFLAGS = @CFLAGS@
LIBRT = @librt@
LIBUUID = @libuuid@
--
1.7.4.1.22.gec8e1.dirty
On Mon, Aug 01, 2011 at 05:58:24PM -0400, Theodore Ts'o wrote:
> In order to build xfsprogs in a hermetic build, we need be able to
> pass in -I and -L flags to the compiler and linker, respectively.
> This needs to be used by the configure script, but we also need to
> make sure these flags are used by the Makefiles as well.
Thanks a lot a Ted!
I've added this to xfsprogs, xfsdump and dmapi. xfstests actually
already has it, sent in in 2009 by Arek for the same reason you want
it in xfsprogs. Wish we would have been a bit better to propagate build
system fixes.