<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.ltp">
    <title>gmane.linux.ltp</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17901"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17900"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17899"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17898"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17897"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17896"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17895"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17894"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17893"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17892"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17891"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17890"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17889"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17888"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17887"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17886"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17885"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17884"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17883"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ltp/17882"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17901">
    <title>Re: [PATCH v2] configure: add configure checks to compile kernel modules</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17901</link>
    <description>&lt;pre&gt;Hi!

So either we get linux version as parameter or we try to use uname, this
is ok.


The same with path, ok.


Now we check if the dir exists and parse the Makefile for MAJOR and
PATCHLEVEL, ok.


If there is Makefile and it contains reasonable content, proceed
with module build, ok.


Here we set the MAJOR and PATCHLEVEL even if WITH_MODULES is set to no.
Is this useful? (Maybe I overlooked something but when WITH_MODULES is
set to no, the kernel version is not needed. Or is this here just in
case we will need that someday?)


But generally it looks fine to me. Mike are you fine with this version
as well? 

&lt;/pre&gt;</description>
    <dc:creator>chrubis-AlSwsSmVLrQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-17T17:11:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17900">
    <title>Re: [PATCH] new testcase: kmsg01</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17900</link>
    <description>&lt;pre&gt;Hi!

Souns good.

&lt;/pre&gt;</description>
    <dc:creator>chrubis-AlSwsSmVLrQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-17T16:21:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17899">
    <title>Re: [PATCH] new testcase: kmsg01</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17899</link>
    <description>&lt;pre&gt;



----- Original Message -----

Works for me.


Sounds reasonable, will do.


Sure.


Good point, it's allocated on stack elsewhere in the code.


:-)


Sure.


It is. Let's open extra fd, which we attempt to read only at the end.
If reads fails with EPIPE we know that first message was overwritten.
If that happens we can retry for NUM_READ_RETRY and repeat the test.
If we get EPIPE in each attempt we can report TWARN.


I'm leaning towards ltp_syscall().


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-17T15:42:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17898">
    <title>Re: [PATCH] prot_hsymlinks &amp; cgroup_xattr: fix copyrightheader</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17898</link>
    <description>&lt;pre&gt;Hi!
Pushed, thanks.

&lt;/pre&gt;</description>
    <dc:creator>chrubis-AlSwsSmVLrQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-17T15:40:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17897">
    <title>Re: [PATCH] new testcase: kmsg01</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17897</link>
    <description>&lt;pre&gt;Hi!

I don't think that adding a bunch of new runtest files with one entry is
good way to go. What about adding a kernel runtest file (kernel_misc or
so) and put all the kernel tests that does not match more general group
there?


Perhaps we should include exact test name in the prefix so it's clear
which test created them.

Something as "LTP kmsg01 "


SAFE_CLOSE() ?


Is the bufsize expected to be too large to be declared on stack as
msg[bufsize] ?


return read(fd, &amp;amp;tmp, 1) ? :)


I would put the comment above the if, so that the one line block
underneath has really one line.


...


Is here a chance that the log would be overwritten by a kernel writing
urelated message? We do fill the log with a bunch of messages (126)
before this test, how much of the kernel log is filled by this? Looking
in the kernel .config I have LOG_BUF_SHIFT=18 which is 256KB which
should be large enough, but it could be set as low as 12 which is 4KB.


What about we add ltp_syscall_defined() or similar so that we don't have
to us&lt;/pre&gt;</description>
    <dc:creator>chrubis-AlSwsSmVLrQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-17T15:13:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17896">
    <title>[PATCH v3] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17896</link>
    <description>&lt;pre&gt;This test checks the device firmware loading. Since Linux 3.7 it can be loaded
directly (by-pass udev). The test consists of the two parts: userspace and
kernelspace.

Signed-off-by: Alexey Kodanev &amp;lt;alexey.kodanev-QHcLZuEGTsvQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 runtest/syscalls                                   |    2 +
 testcases/kernel/Makefile                          |    1 +
 testcases/kernel/firmware/Makefile                 |   45 ++++
 .../kernel/firmware/fw_load_kernel/.gitignore      |    1 +
 testcases/kernel/firmware/fw_load_kernel/Makefile  |   37 +++
 testcases/kernel/firmware/fw_load_kernel/README    |   16 ++
 testcases/kernel/firmware/fw_load_kernel/fw_load.c |  173 ++++++++++++++
 testcases/kernel/firmware/fw_load_user/.gitignore  |    1 +
 testcases/kernel/firmware/fw_load_user/Makefile    |   20 ++
 testcases/kernel/firmware/fw_load_user/README      |   11 +
 testcases/kernel/firmware/fw_load_user/fw_load.c   |  242 ++++++++++++++++++++
 11 files changed, 549 insertions(+), 0 deletions(-)
 &lt;/pre&gt;</description>
    <dc:creator>Alexey Kodanev</dc:creator>
    <dc:date>2013-06-17T13:01:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17895">
    <title>Re: [PATCH v2] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17895</link>
    <description>&lt;pre&gt;



----- Original Message -----

I noticed that too, because my udev wasn't getting any events - 
kernel I'm using has that option turned off.

I also came across this article: http://lwn.net/Articles/518942/
which says: "No events for a specific device, they decided,
would be processed until the process of loading the driver module
for that device had completed", but this one could be fixed easily
in fw_load kernel module.

Regards,
Jan

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-17T08:50:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17894">
    <title>Re: [PATCH v2] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17894</link>
    <description>&lt;pre&gt;
On 06/14/2013 07:16 PM, Jan Stancek wrote:
I see now, I think it is better to skip udev in the test entirely, 
because there is a tendency
in kernel community to disable user-mode helper firmware loading (udev). 
It is already guarded with
CONFIG_FW_LOADER_USER_HELPER option in firmware code: firmware: Make 
user-mode helper optional 
&amp;lt;http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7b1269f778782d2f42994a74bf4014d0cbebbf9f&amp;gt;.
There is only one use of it: loading firmware from non-standard path. It 
might also go away as soon as
configuring paths support had been added to kernel.

Thanks,
Alexey

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev_______________________________________________
Ltp-list mailing list
Ltp-list-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/ltp-list
&lt;/pre&gt;</description>
    <dc:creator>alexey.kodanev-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-17T08:39:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17893">
    <title>Re: [PATCH v2] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17893</link>
    <description>&lt;pre&gt;



----- Original Message -----

I'd go with TCONF or skip udev testcases if we can't be sure that udev is running
and properly configured.

I'm also missing firmware.sh, in new udev (now merged with systemd tree),
50-firmware.rules file depends on some compile switch. Even when enabled
the rule looks like this:
http://cgit.freedesktop.org/systemd/systemd/tree/rules/50-firmware.rules

firmware.sh appears to be converted to .c now:
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-firmware.c

Regards,
Jan


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-14T15:16:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17892">
    <title>Re: [PATCH v2] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17892</link>
    <description>&lt;pre&gt;Hi!

On 06/14/2013 05:48 PM, Jan Stancek wrote:
Would it be better to change failed copy command to just TWARN, and 
continue testing? After that, test will completed with udev failed 
test-cases, or if udev has those rules in the other configuration files, 
everything will be fine.
I just checked it on my machine, output will be:
fw_load     1  TPASS  :  Expect: can load firmware '.../n0_load_tst.fw', 
kernel used
fw_load     2  TPASS  :  Expect: can load firmware '.../n1_load_tst.fw', 
kernel used
fw_load     3  TPASS  :  Expect: can load firmware '.../n2_load_tst.fw', 
kernel used
fw_load     4  TPASS  :  Expect: can load firmware '.../n3_load_tst.fw', 
kernel used
fw_load     5  TFAIL  :  Expect: can load firmware '.../n4_load_tst.fw', 
udev used
fw_load     6  TFAIL  :  Expect: can load firmware '.../n5_load_tst.fw', 
udev used
fw_load     7  TFAIL  :  Expect: can load firmware '.../n6_load_tst.fw', 
udev used
fw_load     8  TFAIL  :  Expect: can load firmware '.../n7_load_tst.fw', 
udev used
fw_load   &lt;/pre&gt;</description>
    <dc:creator>alexey.kodanev-QHcLZuEGTsvQT0dZR+AlfA&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-14T14:44:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17891">
    <title>Re: [PATCH v2] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17891</link>
    <description>&lt;pre&gt;Hi,

I ran this on older kernel, which worked fine - it skipped the build.
Then I tried RHEL7 alpha, which has more recent kernel: 3.10.0-0.rc4,
but it failed:

# ./fw_load 
cp: cannot stat ‘/lib/udev/rules.d/50-firmware.rules’: No such file or directory
fw_load     1  TBROK  :  Failed to copy '/lib/udev/rules.d/50-firmware.rules' to '/etc/udev/rules.d/' at fw_load.c:164
fw_load     2  TBROK  :  Remaining cases broken
fw_load     0  TWARN  :  tst_rmdir: TESTDIR was NULL; no removal attempted

I'll see if I can find out what happened to 50-firmware.rules,
it could some side-effect of systemd.

I found this initialization a little confusing, since your test
always relies on passing it from user-space (which passes 9):


Regards,
Jan

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list&amp;lt; at &amp;gt;lists.sourcef&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-14T13:48:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17890">
    <title>[PATCH v2] fw_load: new test of device firmware loading</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17890</link>
    <description>&lt;pre&gt;This test checks that from kernel 3.7 firmware can be loaded directly
(by-pass udev) or as usual. The test consists of the two parts: userspace
and kernelspace.

Signed-off-by: Alexey Kodanev &amp;lt;alexey.kodanev-QHcLZuEGTsvQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 runtest/syscalls                                   |    2 +
 testcases/kernel/Makefile                          |    1 +
 testcases/kernel/firmware/Makefile                 |   45 +++
 .../kernel/firmware/fw_load_kernel/.gitignore      |    1 +
 testcases/kernel/firmware/fw_load_kernel/Makefile  |   37 +++
 testcases/kernel/firmware/fw_load_kernel/README    |   14 +
 testcases/kernel/firmware/fw_load_kernel/fw_load.c |  162 ++++++++++
 testcases/kernel/firmware/fw_load_user/.gitignore  |    1 +
 testcases/kernel/firmware/fw_load_user/Makefile    |   20 ++
 testcases/kernel/firmware/fw_load_user/README      |   11 +
 testcases/kernel/firmware/fw_load_user/fw_load.c   |  325 ++++++++++++++++++++
 11 files changed, 619 insertions(+), 0 deletions(-)
 create mode &lt;/pre&gt;</description>
    <dc:creator>Alexey Kodanev</dc:creator>
    <dc:date>2013-06-14T11:17:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17889">
    <title>[PATCH v2] configure: add configure checks to compile kernelmodules</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17889</link>
    <description>&lt;pre&gt;There're new configure options added to tune modules building process.
New m4 function tries to determine if kernel-devel package is available
and sets makefile's variables (WITH_MODULES, ...) accordingly.

Signed-off-by: Alexey Kodanev &amp;lt;alexey.kodanev-QHcLZuEGTsvQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
---
 configure.ac                 |    1 +
 include/mk/config.mk.default |    6 +++
 include/mk/config.mk.in      |    6 +++
 m4/ltp-kernel_devel.m4       |   82 ++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 95 insertions(+), 0 deletions(-)
 create mode 100644 m4/ltp-kernel_devel.m4

diff --git a/configure.ac b/configure.ac
index f217f50..f0fc6b0 100644
--- a/configure.ac
+++ b/configure.ac
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -167,5 +167,6 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; LTP_CHECK_MADVISE
 LTP_CHECK_ACL_SUPPORT
 LTP_CHECK_FS_IOC_FLAGS
 LTP_CHECK_MREMAP_FIXED
+LTP_CHECK_KERNEL_DEVEL
 
 AC_OUTPUT
diff --git a/include/mk/config.mk.default b/include/mk/config.mk.default
index bd364a6..a84f42a 100644
--- a/include/mk/config.mk.default
+++ b/include/mk/config.mk.default
&amp;lt; at &amp;gt;&lt;/pre&gt;</description>
    <dc:creator>Alexey Kodanev</dc:creator>
    <dc:date>2013-06-13T13:28:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17888">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17888</link>
    <description>&lt;pre&gt;
Thanks, using bash instead of sh is letting me compile some things,
I'll see how far I can get :)

Ismael



diff --git a/scripts/abspath.sh b/scripts/abspath.sh
index a7f0cf6..6d56a9e 100755
--- a/scripts/abspath.sh
+++ b/scripts/abspath.sh
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1,4 +1,4 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
-#!/bin/sh
+#!/bin/bash
 #
 #    make 3.81 $(abspath .. ) emulation layer
 #


--
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Ismael Farfán</dc:creator>
    <dc:date>2013-06-12T20:36:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17887">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17887</link>
    <description>&lt;pre&gt;



----- Original Message -----

Or maybe trying different shell? Some might have builtin echo,
that supports -n.


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-12T20:14:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17886">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17886</link>
    <description>&lt;pre&gt;Hi!

Looks like the -n gets there from scripts/abspath.sh that is used from
include/mk/functions.mk in MAKE_3_80_abspath which is used to emulate
abspath which is implemented in newer GNU make.

If I'm right fixing the script to call echo that supports -n or getting
GNU make that supports abspath should help.

&lt;/pre&gt;</description>
    <dc:creator>chrubis-AlSwsSmVLrQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-12T20:11:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17885">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17885</link>
    <description>&lt;pre&gt;
I'm using gmake 3.8

I got this new line from gmake after the patch:
/tmp/ltp-full-20130109/include/mk/env_pre.mk:77: abs dirs: -n
/tmp/ltp-full-20130109 -n /tmp/ltp-full-20130109

The appended "-n" looks kind of suspicious?

Cheers



--
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Ismael Farfán</dc:creator>
    <dc:date>2013-06-12T17:10:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17884">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17884</link>
    <description>&lt;pre&gt;Hi!

What is you gmake version? Note that we support 3.80 and newer.

Also running the LTP on AIX is not supported nor tested, so you are on
your own...

&lt;/pre&gt;</description>
    <dc:creator>chrubis-AlSwsSmVLrQ&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-06-12T16:15:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17883">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17883</link>
    <description>&lt;pre&gt;


----- Original Message -----

&amp;lt;SNIP&amp;gt;

Right, I also don't see anything suspicious. Your output shows
that include.mk is created, so the only other thing that comes to mind
is that $(abs_top_builddir) is wrong.

You can try making change according to diff below and re-running gmake.
If everything works OK, this should be warning with path: /tmp/ltp-full-20130109

diff --git a/include/mk/env_pre.mk b/include/mk/env_pre.mk
index f1584a8..1d284ea 100644
--- a/include/mk/env_pre.mk
+++ b/include/mk/env_pre.mk
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -74,6 +74,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; else
 abs_top_builddir               := $(abspath $(top_builddir))
 endif

+$(warning abs dirs: $(abs_top_srcdir) $(abs_top_builddir))
+
 # Where's the root object directory?
 builddir                       := .

Regards,
Jan

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list&amp;lt; at &amp;gt;l&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-12T15:47:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17882">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17882</link>
    <description>&lt;pre&gt;Thanks for the answer.

Since configure didn't fail I thought it didn't mind a few missing
headers. Here it is:


ltp-full-20130109/ ~$ ./configure
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... powerpc-ibm-aix6.1.0.0
checking host system type... powerpc-ibm-aix6.1.0.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for ar... ar
checking for flex...&lt;/pre&gt;</description>
    <dc:creator>Ismael Farfán</dc:creator>
    <dc:date>2013-06-12T14:34:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ltp/17881">
    <title>Re: Help compiling in AIX 6.1</title>
    <link>http://permalink.gmane.org/gmane.linux.ltp/17881</link>
    <description>&lt;pre&gt;



----- Original Message -----

include/mk/env_pre.mk:100 is include of "$(abs_top_builddir)/include/mk/config.mk",
so I'm guessing something went wrong with ./configure.
Can you send output of "./configure"?

Regards,
Jan


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
&lt;/pre&gt;</description>
    <dc:creator>Jan Stancek</dc:creator>
    <dc:date>2013-06-12T06:51:50</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.ltp">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.ltp</link>
  </textinput>
</rdf:RDF>
