[oe] QA issue with staging (workdir) for .la files in xmlrpc-c package

[Martin Panter]

On 23 December 2010 18:43, Frans Meulenbroeks
<fransmeulenbroeks at gmail.com> wrote:
> 2010/12/23 Martin Panter <vadmium+floss at gmail.com>:
>> Hi all
>>
>> I'm having trouble building "xmlrpc-c", which I think is required for
>> rtorrent. It's failing at the "do_qa_staging" stage with the messages
>> such as "QA Issue with staging: libxmlrpc.la failed sanity test
>> (workdir)".
>>
>> I gather the issue is that my sysroots/*/usr/lib/libxmlrpc.la file has
>> the following, which mentions the tmp/work/ directory:
>>
>> # Libraries that this one depends upon.
>> dependency_libs=' -L.libs
>> -L/media/disk/home/vadmium/proj/aegle/build/tmp/work/armv7a-angstrom-linux-gnueabi/xmlrpc-c-1.06.41-r1/xmlrpc-c-1.06.41/src/../lib/libutil/.libs
>> -lxmlrpc_util -lxml2 -lz -lm'
>>
>> So looks like another Libtool issue. But I'm stuck this time so if
>> anyone has any hints that would be awesome. For instance why does that
>> -L. . ./tmp/work/. . . component get there, and perhaps is there some
>> Libtool option to prevent or fix it?
>>
>> I think the xmlrpc-c packages has its own version of Libtool (1.3.4?).
>> I tried coaxing the build process to use OE's Libtool version
>> (EXTRA_OEMAKE = "LIBTOOL='${HOST_SYS}-libtool'", after the import
>> line, in the recipe file), but this didn't seem to help.
>>
>> Previously I thought I had another "QA issue" with this xmlrpc-c
>> package, something about a "hash style", which I thought I solved by
>> passing LADD='${LDFLAGS}' to the Make command. But recently when I
>> removed this change I am not getting the earlier "hash style QA
>> issue"; only this newer "workdir" one. But I may be confused.
>>
>> -Martin
>>
>> These are the full messages taken straight from log.do_qa_staging file
>> with awesome-long path names:
>>
>> ERROR: QA Issue with staging: libxmlrpc.la failed sanity test
>> (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_server_abyss.la failed sanity
>> test (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_server.la failed sanity test
>> (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_server_cgi.la failed sanity
>> test (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_client.la failed sanity test
>> (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> FATAL: QA staging was broken by the package built above
>
> I *think* I've rebuild rtorrent yesterday. for beagleboard/minimal.
> Didn't get the error. Can't verify things right now. Feel frree to
> ping me this evening on irc (roughly 18.00-22.00 gmt) or tomorrow
> during the day)
> What libtool are you using? and is this on git head ?

On 23/12/2010, Frans Meulenbroeks <fransmeulenbroeks at gmail.com> wrote:
> 2010/12/23 Martin Panter <vadmium+floss at gmail.com>:
>> Hi all
>>
>> I'm having trouble building "xmlrpc-c", which I think is required for
>> rtorrent. It's failing at the "do_qa_staging" stage with the messages
>> such as "QA Issue with staging: libxmlrpc.la failed sanity test
>> (workdir)".
>>
>> I gather the issue is that my sysroots/*/usr/lib/libxmlrpc.la file has
>> the following, which mentions the tmp/work/ directory:
>>
>> # Libraries that this one depends upon.
>> dependency_libs=' -L.libs
>> -L/media/disk/home/vadmium/proj/aegle/build/tmp/work/armv7a-angstrom-linux-gnueabi/xmlrpc-c-1.06.41-r1/xmlrpc-c-1.06.41/src/../lib/libutil/.libs
>> -lxmlrpc_util -lxml2 -lz -lm'
>>
>> So looks like another Libtool issue. But I'm stuck this time so if
>> anyone has any hints that would be awesome. For instance why does that
>> -L. . ./tmp/work/. . . component get there, and perhaps is there some
>> Libtool option to prevent or fix it?
>>
>> I think the xmlrpc-c packages has its own version of Libtool (1.3.4?).
>> I tried coaxing the build process to use OE's Libtool version
>> (EXTRA_OEMAKE = "LIBTOOL='${HOST_SYS}-libtool'", after the import
>> line, in the recipe file), but this didn't seem to help.
>>
>> Previously I thought I had another "QA issue" with this xmlrpc-c
>> package, something about a "hash style", which I thought I solved by
>> passing LADD='${LDFLAGS}' to the Make command. But recently when I
>> removed this change I am not getting the earlier "hash style QA
>> issue"; only this newer "workdir" one. But I may be confused.
>>
>> -Martin
>>
>> These are the full messages taken straight from log.do_qa_staging file
>> with awesome-long path names:
>>
>> ERROR: QA Issue with staging: libxmlrpc.la failed sanity test
>> (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_server_abyss.la failed sanity
>> test (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_server.la failed sanity test
>> (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_server_cgi.la failed sanity
>> test (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> ERROR: QA Issue with staging: libxmlrpc_client.la failed sanity test
>> (workdir) in path
>> /media/disk/home/vadmium/proj/aegle/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib
>> FATAL: QA staging was broken by the package built above
>
> I *think* I've rebuild rtorrent yesterday. for beagleboard/minimal.
> Didn't get the error. Can't verify things right now. Feel frree to
> ping me this evening on irc (roughly 18.00-22.00 gmt) or tomorrow
> during the day)
> What libtool are you using? and is this on git head ?

I'm using a git master from last week, and I think the normal Libtool
it's using is 2.4. More configuration I'm currently using that might
be relevant, from my conf/local.conf file:
MACHINE = "beagleboard"
DISTRO = "angstrom-2010.x" (maybe might it be wiser for me to go back
to 2008.1?)
Bit bake 1.10.0 installed (too many issues with 1.10.1)