[LTP] [RFC] Realtime tests - autoconf problems in OpenEmbedded cross-build environment

[LTP] [RFC] Realtime tests - autoconf problems in OpenEmbedded cross-build environment

[Gary Robertson]

[-- Attachment #1.1: Type: text/plain, Size: 3033 bytes --]

LTP developers,

The autoconf scripts in 'ltp/testcases/realtime/m4/check.m4' evaluate
whether priority-inheriting mutexes and robust mutexes are supported on the
system for which the LTP realtime tests are being targeted.  Portions of
the LTP realtime test code required to test these features on the target
are then conditionally included or excluded at compile time based on
autoconf results.

To check these features, the autoconf scripts attempt to compile and then
execute initialization functions which rely on the features.  Is this done
because the mere presence of the appropriate headers and protocol value
definitions, etc. is insufficient proof that the features are supported?
That is, are there cases in which the headers may contain the associated
definitions but the installed runtime libraries lack the actual support
code for the features?:

The reason I ask is that in the OpenEmbedded cross-build environment, all
code is theoretically cross-compiled for the build target system.  When the
autoconf scripts subsequently attempt to execute the compiled code on the
cross-development host, the execution fails.  Even if the code were to be
compiled for the cross-development host and successfully executed, the
results would be misleading as they represent feature support on the
development host rather than on the test target system.

Without knowing the history of configuration issues in LTP I don't know
what conflicts may exist between the support for cross-build environments
and the reliable configuration of features in a wide variety of
native-build scenarios.

If autoconf in LTP must rely on the execution of target system code in
order to determine what features are supported on the target, then some
sort of override is needed in cross-build environments... so my question
is: what is the preferred method for handling this?

Possible solutions under consideration include:


   - adding command line options to be passed to the 'configure' script in
   order to force inclusion of support for the features in question without
   performing any tests, -or-
   - adding local patches to the bitbake recipe for LTP which would
   unconditionally patch either  the autoconf input files or the output of
   autoconf operations in order to force support for the features in
   question... and making no changes at the LTP level to address the problem.

If command line override options are the preferable solution, I notice
there are both '--with...' and '--enable...' options defined - but which
would be the more appropriate prefix for these new options?

OTOH, if the presence of the associated protocol name definitions, etc. in
the target system's header files is a sufficient indication of support,
could we just dispense with the execution of compiled target code and
configure support for the features based on the header contents alone?

I will be looking forward to your comments in order to determine the most
effective and/or least offensive means of addressing this problem.

Gary Robertson

[-- Attachment #1.2: Type: text/html, Size: 3277 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [RFC] Realtime tests - autoconf problems in OpenEmbedded cross-build environment

[chrubis]

Hi!
> The autoconf scripts in 'ltp/testcases/realtime/m4/check.m4' evaluate
> whether priority-inheriting mutexes and robust mutexes are supported on the
> system for which the LTP realtime tests are being targeted.  Portions of
> the LTP realtime test code required to test these features on the target
> are then conditionally included or excluded at compile time based on
> autoconf results.
> 
> To check these features, the autoconf scripts attempt to compile and then
> execute initialization functions which rely on the features.  Is this done
> because the mere presence of the appropriate headers and protocol value
> definitions, etc. is insufficient proof that the features are supported?

Maybe I've overlooked something but all I see in the check.m4 file is
AC_TRY_COMPILE() which should only try to run the code through the
compile not even link it. At which point does the relatime configure
execute the cross compiled binaries?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list