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
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
