| Message ID | 1431935001-15678-1-git-send-email-thuth@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, May 18, 2015 at 09:43:21AM +0200, Thomas Huth wrote: > Some recent patches require functions from libfdt version 1.4.0, > so we should check for this version during the configure step > already. Unfortunately, there does not seem to be a proper #define > for the version number in the libfdt headers. So alternatively, we > check for the availability of the fdtXX_t types instead which have > just been introduced with version 1.4.0. Um.. I'm confused by this. As far as I can recall the fdtXX_t types have been in libfdt since.. well, forever, basically. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > configure | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index b18aa9e..87a5bbc 100755 > --- a/configure > +++ b/configure > @@ -3091,9 +3091,10 @@ fi > if test "$fdt" != "no" ; then > fdt_libs="-lfdt" > # explicitly check for libfdt_env.h as it is missing in some stable installs > + # and also test for fdtXX_t to make sure we are on a version >= 1.4.0 > cat > $TMPC << EOF > #include <libfdt_env.h> > -int main(void) { return 0; } > +int main(void) { fdt32_t x = 0; return x; } > EOF > if compile_prog "" "$fdt_libs" ; then > # system DTC is good - use it > @@ -3111,7 +3112,7 @@ EOF > fdt_libs="-L\$(BUILD_DIR)/dtc/libfdt $fdt_libs" > elif test "$fdt" = "yes" ; then > # have neither and want - prompt for system/submodule install > - error_exit "DTC (libfdt) not present. Your options:" \ > + error_exit "DTC (libfdt) version >= 1.4.0 not present. Your options:" \ > " (1) Preferred: Install the DTC (libfdt) devel package" \ > " (2) Fetch the DTC submodule, using:" \ > " git submodule update --init dtc"
On 25 May 2015 at 02:35, David Gibson <david@gibson.dropbear.id.au> wrote: > On Mon, May 18, 2015 at 09:43:21AM +0200, Thomas Huth wrote: >> Some recent patches require functions from libfdt version 1.4.0, >> so we should check for this version during the configure step >> already. Unfortunately, there does not seem to be a proper #define >> for the version number in the libfdt headers. So alternatively, we >> check for the availability of the fdtXX_t types instead which have >> just been introduced with version 1.4.0. > > Um.. I'm confused by this. As far as I can recall the fdtXX_t types > have been in libfdt since.. well, forever, basically. There's no such typedef in the libfdt that QEMU is currently using (which I think is 1.3.0). It looks like they were added in this commit: https://git.kernel.org/cgit/utils/dtc/dtc.git/commit/libfdt/libfdt_env.h?id=feafcd972cb744750a65728440c99526e6199a6d in early 2013. QEMU took a copy of the dtc module in April 2013, at which point we used 1.3.0 as the most recently tagged stable version. thanks -- PMM
On Mon, May 25, 2015 at 01:30:11PM +0100, Peter Maydell wrote: > On 25 May 2015 at 02:35, David Gibson <david@gibson.dropbear.id.au> wrote: > > On Mon, May 18, 2015 at 09:43:21AM +0200, Thomas Huth wrote: > >> Some recent patches require functions from libfdt version 1.4.0, > >> so we should check for this version during the configure step > >> already. Unfortunately, there does not seem to be a proper #define > >> for the version number in the libfdt headers. So alternatively, we > >> check for the availability of the fdtXX_t types instead which have > >> just been introduced with version 1.4.0. > > > > Um.. I'm confused by this. As far as I can recall the fdtXX_t types > > have been in libfdt since.. well, forever, basically. > > There's no such typedef in the libfdt that QEMU is currently > using (which I think is 1.3.0). It looks like they were added > in this commit: > https://git.kernel.org/cgit/utils/dtc/dtc.git/commit/libfdt/libfdt_env.h?id=feafcd972cb744750a65728440c99526e6199a6d > in early 2013. Ah, duh, I was mixing up the fdtXX_t _types_ which were introduced with sparse annotations with the fdtXX_to_cpu functions/macros which have been around since forever. Still, I think looking at the actual exported functions is a better idea than looking at the types - which I see Thomas has already done in his latest spin.
diff --git a/configure b/configure index b18aa9e..87a5bbc 100755 --- a/configure +++ b/configure @@ -3091,9 +3091,10 @@ fi if test "$fdt" != "no" ; then fdt_libs="-lfdt" # explicitly check for libfdt_env.h as it is missing in some stable installs + # and also test for fdtXX_t to make sure we are on a version >= 1.4.0 cat > $TMPC << EOF #include <libfdt_env.h> -int main(void) { return 0; } +int main(void) { fdt32_t x = 0; return x; } EOF if compile_prog "" "$fdt_libs" ; then # system DTC is good - use it @@ -3111,7 +3112,7 @@ EOF fdt_libs="-L\$(BUILD_DIR)/dtc/libfdt $fdt_libs" elif test "$fdt" = "yes" ; then # have neither and want - prompt for system/submodule install - error_exit "DTC (libfdt) not present. Your options:" \ + error_exit "DTC (libfdt) version >= 1.4.0 not present. Your options:" \ " (1) Preferred: Install the DTC (libfdt) devel package" \ " (2) Fetch the DTC submodule, using:" \ " git submodule update --init dtc"
Some recent patches require functions from libfdt version 1.4.0, so we should check for this version during the configure step already. Unfortunately, there does not seem to be a proper #define for the version number in the libfdt headers. So alternatively, we check for the availability of the fdtXX_t types instead which have just been introduced with version 1.4.0. Signed-off-by: Thomas Huth <thuth@redhat.com> --- configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)