[Buildroot] Newbie: configure: error: cannot run test program while cross compiling

[Buildroot] Newbie: configure: error: cannot run test program while cross compiling

[Ernest L Williams]

Hi
I am working with the hdf5 package and having trouble getting past the 
configuration stage :(
hdf5 builds fine for my host machine but fails configuration when i try 
to build for
"x86_64-buildroot-linux-uclibc"


Oops,
package/pkg-generic.mk:172: recipe for target 
'/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14/.stamp_configured' 
failed

The hdf5 package uses autotools

Any ideas on what I should pursue?

By the way,  why does "package/pkg-generic.mk" show up in the output below?
I am using auto-tools.


checking if libtool needs -no-undefined flag to build shared libraries... no
checking if configure should try to set up large file support... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking if large (64-bit) files are supported on this system.... 
configure: error: in 
`/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14':
configure: error: cannot run test program while cross compiling
See `config.log' for more details
package/pkg-generic.mk:172: recipe for target 
'/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14/.stamp_configured' 
failed
make: *** 
[/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14/.stamp_configured] 
Error 1
[ernesto at localhost buildroot-uclibc-x86_64]$

Cheers,
Ernesto

[Buildroot] Newbie: configure: error: cannot run test program while cross compiling

[Yann E. MORIN]

Ernest, All,

On 2015-01-01 21:03 -0800, Ernest L Williams spake thusly:
> Hi
> I am working with the hdf5 package and having trouble getting past the
> configuration stage :(
> hdf5 builds fine for my host machine but fails configuration when i try to
> build for
> "x86_64-buildroot-linux-uclibc"
> 
> 
> Oops,
> package/pkg-generic.mk:172: recipe for target '/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14/.stamp_configured'
> failed
> 
> The hdf5 package uses autotools
> 
> Any ideas on what I should pursue?
> 
> By the way,  why does "package/pkg-generic.mk" show up in the output below?
> I am using auto-tools.
> 
> 
> checking if libtool needs -no-undefined flag to build shared libraries... no
> checking if configure should try to set up large file support... yes
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... no
> checking if large (64-bit) files are supported on this system.... configure:
> error: in `/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14':
> configure: error: cannot run test program while cross compiling

Damn, those pesky packagers that do not like cross-compilation! ;-)

What you can do is force the result of the test, by passing the
appropriate value on the command line when calling configure, something
like the following:

    HDF5_CONF_ENV = hdf5_cv_have_lfs=$(if $(BR2_LARGEFILE),yes,no)

This will tell configure not to run the test, and assume the result we
do provide.

Note-1: you can see what variable to preset by looking at configure.ac,
line 1455:

    1452   ## Now actually test to see if we can create large files after we've
    1453   ## checked for any needed defines.
    1454   AC_MSG_CHECKING([if large (64-bit) files are supported on this system.])
    1455   AC_CACHE_VAL([hdf5_cv_have_lfs],
    1456     [AC_TRY_RUN([
    [...]

Note-2: I used 'HDF5' as a prefix, assuming the package is named 'hdf5'
in Buildroot.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Newbie: configure: error: cannot run test program while cross compiling

[Williams]

Hi Yann,
________________________________________
From: Yann E. MORIN [yann.morin.1998 at gmail.com] on behalf of Yann E. MORIN [yann.morin.1998 at free.fr]
Sent: Friday, January 2, 2015 1:33 AM
To: Williams Jr., Ernest L.
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Newbie: configure: error: cannot run test program while cross compiling

Ernest, All,

On 2015-01-01 21:03 -0800, Ernest L Williams spake thusly:
> Hi
> I am working with the hdf5 package and having trouble getting past the
> configuration stage :(
> hdf5 builds fine for my host machine but fails configuration when i try to
> build for
> "x86_64-buildroot-linux-uclibc"
>
>
> Oops,
> package/pkg-generic.mk:172: recipe for target '/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14/.stamp_configured'
> failed
>
> The hdf5 package uses autotools
>
> Any ideas on what I should pursue?
>
> By the way,  why does "package/pkg-generic.mk" show up in the output below?
> I am using auto-tools.
>
>
> checking if libtool needs -no-undefined flag to build shared libraries... no
> checking if configure should try to set up large file support... yes
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... no
> checking if large (64-bit) files are supported on this system.... configure:
> error: in `/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14':
> configure: error: cannot run test program while cross compiling

Damn, those pesky packagers that do not like cross-compilation! ;-)

What you can do is force the result of the test, by passing the
appropriate value on the command line when calling configure, something
like the following:

    HDF5_CONF_ENV = hdf5_cv_have_lfs=$(if $(BR2_LARGEFILE),yes,no)

This will tell configure not to run the test, and assume the result we
do provide.

Note-1: you can see what variable to preset by looking at configure.ac,
line 1455:

    1452   ## Now actually test to see if we can create large files after we've
    1453   ## checked for any needed defines.
    1454   AC_MSG_CHECKING([if large (64-bit) files are supported on this system.])
    1455   AC_CACHE_VAL([hdf5_cv_have_lfs],
    1456     [AC_TRY_RUN([
    [...]

Note-2: I used 'HDF5' as a prefix, assuming the package is named 'hdf5'
in Buildroot.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>  Yes, the package name is "hdf5"
>>>  This actually worked great :)
>>>  Can I continue with this technique?
>>> Next error is the following:

>>> checking for struct tm.tm_zone... yes
>>> checking for struct timezone... yes
>>> checking whether gettimeofday() gives timezone... configure: 
>>> error: in `/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14':
>>> configure: error: cannot run test program while cross compiling
>>> See `config.log' for more details

>>> config.log does indeed reveal the variable name  "ac_cv_func_gettimeofday"
>>> But what buildroot string must I use  "HDF5_CONF_ENV = hdf5_cv_have_lfs=$(if $(BR2_XXXX),yes,no) ?
>>> Looks like I may bump into more of this ?

>>> Cheers,
Ernesto


Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Newbie: configure: error: cannot run test program while cross compiling

[Yann E. MORIN]

Ernesto, All,

[Note: it was hard to find your reply, since you used '>>>' to prefix
your reply; '>' is usually used to quote the original message you are
replying to, so it appears to me like this was quotation from a former
message, not your actual reply. Just write your reply without prefixing
it with anything, please ;-) ]

On 2015-01-02 16:25 +0000, Williams Jr., Ernest L. spake thusly:
[--SNIP--]
> What you can do is force the result of the test, by passing the
> appropriate value on the command line when calling configure, something
> like the following:
> 
>     HDF5_CONF_ENV = hdf5_cv_have_lfs=$(if $(BR2_LARGEFILE),yes,no)
[--SNIP--]
> >>>  This actually worked great :)
> >>>  Can I continue with this technique?

Yes, setting ac_cv_XXX is the way to go when the package wants to do
run-time testing, because there is no other way this can be solved for
cross-compilation.

(Well, there is another way, but it involves rewriting that dmn
configure.ac)

> >>> Next error is the following:
> 
> >>> checking for struct tm.tm_zone... yes
> >>> checking for struct timezone... yes
> >>> checking whether gettimeofday() gives timezone... configure: 
> >>> error: in `/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14':
> >>> configure: error: cannot run test program while cross compiling
> >>> See `config.log' for more details
> 
> >>> config.log does indeed reveal the variable name  "ac_cv_func_gettimeofday"
> >>> But what buildroot string must I use  "HDF5_CONF_ENV = hdf5_cv_have_lfs=$(if $(BR2_XXXX),yes,no) ?
> >>> Looks like I may bump into more of this ?

Yup, and you can find before hand without running, by looking for all
instances of the AC_TRY_RUN macro, and see the conrresponding ac_cv_XXX
variable.

As for how to set ip, it really depends. Some you can always set to
'tes', some you can always set to 'no', some you must define depending
on Builroot's configuration, and finally there might be some that you
can't guess (e.g. if it has to deal with the kernel, for example), in
which case you should be conservative, and assume the worst.

As for gettimeofday returning timezone, I don't know what it means.
Let's see at the code...

    [...]
    2180                 /* Check whether the function returned any value at all */
    2181              if(tz.tz_minuteswest == 7777 && tz.tz_dsttime == 7)
    2182                 exit(1);
    2183              else exit (0);
    [...]

On glibc, the answer if 'yes' (I just tested natively).

On uClibc and musl, gettimeofday is just a wtrapper aound the real syscall,
so it returns whatever the kernel provides it... I'd say 'yes' too, but
am not 100% sure...

So, you'd write:

    HDF5_CONF_ENV = hdf5_cv_have_lfs=yes \
        hdf5_cv_gettimeofday_tz=yes \
        hdf5_cv_szlib_can_encode=yes \                  [0]
        hdf5_cv_vsnprintf_works=yes \
        hdf5_cv_printf_ll=ll \
        hdf5_cv_system_scope_threads=yes \              [1]
        hdf5_cv_direct_io=yes \                         [2]
        hdf5_cv_ldouble_to_integer_works=yes \          [3]
        hdf5_cv_ulong_to_float_accurate=yes \
        hdf5_cv_ulong_to_fp_bottom_bit_accurate=yes \
        hdf5_cv_fp_to_ullong_accurate=yes \
        hdf5_cv_fp_to_ullong_right_maximum=yes \
        hdf5_cv_ldouble_to_uint_accurate=yes \
        hdf5_cv_ullong_to_ldouble_precision=yes \
        hdf5_cv_fp_to_integer_overflow_works=yes \
        hdf5_cv_ldouble_to_long_special=no \
        hdf5_cv_long_to_ldouble_special=no \
        hdf5_cv_ldouble_to_llong_accurate=yes \
        hdf5_cv_llong_to_ldouble_correct=yes


[0] depends on what your recent szip package does, of course...
[1] LT and NPTL have it
[2] a proper answer would need a more thorough test, because
    posix_memalign can be configured-out in uClibc. glibc and musl have
    it, though...
[3] that one and all the following are just insane test-cases for exotic
    machines, the yes/no are just what the comments state ("should be yes
    for all machines but XXX", or "should not be set except for YYY"...)

Note: there are AC_TRY_RUN calls that test compiler behaviour, just
forget about those, I had a cursory look, and it tseems we don't care
those failing.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Newbie: configure: error: cannot run test program while cross compiling

[Ernest Williams]

Hi Yann,


Cheers,
Ernesto

On Fri, Jan 2, 2015 at 9:26 AM, Yann E. MORIN <yann.morin.1998@free.fr>
wrote:

> Ernesto, All,
>
> [Note: it was hard to find your reply, since you used '>>>' to prefix
> your reply; '>' is usually used to quote the original message you are
> replying to, so it appears to me like this was quotation from a former
> message, not your actual reply. Just write your reply without prefixing
> it with anything, please ;-) ]
>

Okay, will do.


>
> On 2015-01-02 16:25 +0000, Williams Jr., Ernest L. spake thusly:
> [--SNIP--]
> > What you can do is force the result of the test, by passing the
> > appropriate value on the command line when calling configure, something
> > like the following:
> >
> >     HDF5_CONF_ENV = hdf5_cv_have_lfs=$(if $(BR2_LARGEFILE),yes,no)
> [--SNIP--]
> > >>>  This actually worked great :)
> > >>>  Can I continue with this technique?
>
> Yes, setting ac_cv_XXX is the way to go when the package wants to do
> run-time testing, because there is no other way this can be solved for
> cross-compilation.
>
> (Well, there is another way, but it involves rewriting that dmn
> configure.ac)
>
> > >>> Next error is the following:
> >
> > >>> checking for struct tm.tm_zone... yes
> > >>> checking for struct timezone... yes
> > >>> checking whether gettimeofday() gives timezone... configure:
> > >>> error: in
> `/home/ernesto/packages/buildroot-2014.11/buildroot-uclibc-x86_64/output/build/hdf5-1.8.14':
> > >>> configure: error: cannot run test program while cross compiling
> > >>> See `config.log' for more details
> >
> > >>> config.log does indeed reveal the variable name
> "ac_cv_func_gettimeofday"
> > >>> But what buildroot string must I use  "HDF5_CONF_ENV =
> hdf5_cv_have_lfs=$(if $(BR2_XXXX),yes,no) ?
> > >>> Looks like I may bump into more of this ?
>
> Yup, and you can find before hand without running, by looking for all
> instances of the AC_TRY_RUN macro, and see the conrresponding ac_cv_XXX
> variable.
>
> As for how to set ip, it really depends. Some you can always set to
> 'tes', some you can always set to 'no', some you must define depending
> on Builroot's configuration, and finally there might be some that you
> can't guess (e.g. if it has to deal with the kernel, for example), in
> which case you should be conservative, and assume the worst.
>
> As for gettimeofday returning timezone, I don't know what it means.
> Let's see at the code...
>
>     [...]
>     2180                 /* Check whether the function returned any value
> at all */
>     2181              if(tz.tz_minuteswest == 7777 && tz.tz_dsttime == 7)
>     2182                 exit(1);
>     2183              else exit (0);
>     [...]
>
> On glibc, the answer if 'yes' (I just tested natively).
>
> On uClibc and musl, gettimeofday is just a wtrapper aound the real syscall,
> so it returns whatever the kernel provides it... I'd say 'yes' too, but
> am not 100% sure...
>
> So, you'd write:
>
>     HDF5_CONF_ENV = hdf5_cv_have_lfs=yes \
>         hdf5_cv_gettimeofday_tz=yes \
>         hdf5_cv_szlib_can_encode=yes \                  [0]
>         hdf5_cv_vsnprintf_works=yes \
>         hdf5_cv_printf_ll=ll \
>         hdf5_cv_system_scope_threads=yes \              [1]
>         hdf5_cv_direct_io=yes \                         [2]
>         hdf5_cv_ldouble_to_integer_works=yes \          [3]
>         hdf5_cv_ulong_to_float_accurate=yes \
>         hdf5_cv_ulong_to_fp_bottom_bit_accurate=yes \
>         hdf5_cv_fp_to_ullong_accurate=yes \
>         hdf5_cv_fp_to_ullong_right_maximum=yes \
>         hdf5_cv_ldouble_to_uint_accurate=yes \
>         hdf5_cv_ullong_to_ldouble_precision=yes \
>         hdf5_cv_fp_to_integer_overflow_works=yes \
>         hdf5_cv_ldouble_to_long_special=no \
>         hdf5_cv_long_to_ldouble_special=no \
>         hdf5_cv_ldouble_to_llong_accurate=yes \
>         hdf5_cv_llong_to_ldouble_correct=yes
>
>
> [0] depends on what your recent szip package does, of course...
> [1] LT and NPTL have it
> [2] a proper answer would need a more thorough test, because
>     posix_memalign can be configured-out in uClibc. glibc and musl have
>     it, though...
> [3] that one and all the following are just insane test-cases for exotic
>     machines, the yes/no are just what the comments state ("should be yes
>     for all machines but XXX", or "should not be set except for YYY"...)
>


I added the new "HDF5_CONF_ENV"  that you mentioned above and now the
configure stage works :)
Thanks for your help.


>
> Note: there are AC_TRY_RUN calls that test compiler behaviour, just
> forget about those, I had a cursory look, and it tseems we don't care
> those failing.
>

Sounds good. :)


>
> Regards,
> Yann E. MORIN.
>
> --
>
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
>      |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There
> is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
>  conspiracy.  |
>
> '------------------------------^-------^------------------^--------------------'
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150102/32b925ed/attachment.html>