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

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

[Martin Panter]

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

Re: QA issue with staging (workdir) for .la files in xmlrpc-c package

[Frans Meulenbroeks]

2010/12/23 Martin Panter <vadmium+floss@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 ?

Frans

Re: QA issue with staging (workdir) for .la files in xmlrpc-c package

[Martin Panter]

On 23 December 2010 18:43, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/12/23 Martin Panter <vadmium+floss@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@gmail.com> wrote:
> 2010/12/23 Martin Panter <vadmium+floss@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)

Re: QA issue with staging (workdir) for .la files in xmlrpc-c package

[Martin Panter]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On 23 December 2010 07:26, Martin Panter <vadmium+floss@gmail.com> wrote:
> 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 think I've solved this problem. Half of my solution is to modify the
xmlrpc-c package's Make file to pass the library file names directly
instead of using the "-L<directory> -l<name>" method. The other half
is to force it to use the newer Libtool version instead of its own.
See patch #1 attached, though I'm not really an expert on Libtool or
Open embedded, so I can't say if it might break something else, and I
haven't even tested out the packages I built yet.

> 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.

Still confused why this other failure temporarily went away but when I
fixed the "workdir" issue above, this "GNU_HASH" one came back.
Solution I originally tried worked and is in patch #2 attached.

-Martin

[-- Attachment #2: 1.xmlrpc-la-workdir.patch.txt --]
[-- Type: text/plain, Size: 3733 bytes --]

From 52867ad00845a4f67ac9ae4cf8335ff1f4c3daaa Mon Sep 17 00:00:00 2001
From: Martin Panter <vadmium à gmail.com>
Date: Fri, 24 Dec 2010 02:00:44 +0000
Subject: [PATCH 1/2] XML-RPC: Avoid "QA issue" where build directory is hard-coded into .la files

Adds a patch to avoid using -L link flags, and forces the Make files to use a
newer external Libtool.
---
 recipes/xmlrpc-c/xmlrpc-c-1.06.41/lib-path.patch |   58 ++++++++++++++++++++++
 recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb             |    9 +++-
 2 files changed, 66 insertions(+), 1 deletions(-)
 create mode 100644 recipes/xmlrpc-c/xmlrpc-c-1.06.41/lib-path.patch

diff --git a/recipes/xmlrpc-c/xmlrpc-c-1.06.41/lib-path.patch b/recipes/xmlrpc-c/xmlrpc-c-1.06.41/lib-path.patch
new file mode 100644
index 0000000..1ec148b
--- /dev/null
+++ b/recipes/xmlrpc-c/xmlrpc-c-1.06.41/lib-path.patch
@@ -0,0 +1,58 @@
+Don't use build directories in the library search path because it apparently
+causes Libtool to hard-code the build directories inside installed .la files,
+triggering "QA issues". Use with newer Libtool.
+--- xmlrpc-c-1.06.41/src/Makefile
++++ xmlrpc-c-1.06.41/src/Makefile
+@@ -7,8 +7,8 @@ VPATH = .:$(SRCDIR)
+ 
+ include $(BUILDDIR)/Makefile.config
+ 
+-ABYSS_LIBDIR = $(BUILDDIR)/lib/abyss/src/.libs
+-LIBUTIL_LIBDIR = $(BUILDDIR)/lib/libutil/.libs
++ABYSS_LIB = $(BUILDDIR)/lib/abyss/src/libxmlrpc_abyss.la
++LIBUTIL_LIB = $(BUILDDIR)/lib/libutil/libxmlrpc_util.la
+ 
+ default: all
+ 
+@@ -70,17 +70,17 @@ endif
+ # may require the necessary -L options in addition.
+ 
+ LIBXMLRPC_CLIENT_OBJS = xmlrpc_client.lo xmlrpc_client_global.lo
+-LIBXMLRPC_CLIENT_LIBDEP = -lxmlrpc_util -lxmlrpc
++LIBXMLRPC_CLIENT_LIBDEP = $(LIBUTIL_LIB) libxmlrpc.la
+ 
+ LIBXMLRPC_SERVER_OBJS = registry.lo system_method.lo
+-LIBXMLRPC_SERVER_LIBDEP = -lxmlrpc_util -lxmlrpc
++LIBXMLRPC_SERVER_LIBDEP = $(LIBUTIL_LIB) libxmlrpc.la
+ 
+ LIBXMLRPC_SERVER_ABYSS_OBJS = xmlrpc_server_abyss.lo
+ LIBXMLRPC_SERVER_ABYSS_LIBDEP = \
+-  -lxmlrpc_util -lxmlrpc_server -L$(ABYSS_LIBDIR) -lxmlrpc_abyss -lxmlrpc
++  $(LIBUTIL_LIB) libxmlrpc_server.la $(ABYSS_LIB) libxmlrpc.la
+ 
+ LIBXMLRPC_SERVER_CGI_OBJS = xmlrpc_server_cgi.lo
+-LIBXMLRPC_SERVER_CGI_LIBDEP = -lxmlrpc_util -lxmlrpc_server -lxmlrpc
++LIBXMLRPC_SERVER_CGI_LIBDEP = $(LIBUTIL_LIB) libxmlrpc_server.la libxmlrpc.la
+ 
+ LIBXMLRPC_OBJS = \
+ 	trace.lo \
+@@ -96,7 +96,7 @@ LIBXMLRPC_OBJS = \
+ 	xmlrpc_utf8.lo \
+ 	xmlrpc_authcookie.lo \
+ 
+-LIBXMLRPC_LIBDEP = -lxmlrpc_util $(LIBXML_LIBS)
++LIBXMLRPC_LIBDEP = $(LIBUTIL_LIB) $(LIBXML_LIBS)
+ 
+ LIB_OBJS = $(LIBXMLRPC_CLIENT_OBJS) $(LIBXMLRPC_SERVER_OBJS)
+ 
+@@ -133,9 +133,7 @@ all: $(TARGET_LTLIBRARIES) $(SUBDIRS:%=%
+ 
+ LDFLAGS = $(LADD)
+ 
+-LIBPATHS = -L.libs -L$(LIBUTIL_LIBDIR)
+-
+-LIBLDFLAGS = $(LDFLAGS_VERSINFO) -rpath $(LIBINST_DIR) $(LIBPATHS) $(LADD)
++LIBLDFLAGS = $(LDFLAGS_VERSINFO) -rpath $(LIBINST_DIR) $(LADD)
+ 
+ 
+ libxmlrpc.la: $(LIBXMLRPC_OBJS)
diff --git a/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb b/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb
index e9bbc31..46d3a8d 100644
--- a/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb
+++ b/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb
@@ -14,12 +14,19 @@ PARALLEL_MAKE = ""
 
 inherit autotools binconfig
 
+# EXTRA_OEMAKE only works if after inherit line above
+
+# Older internal Libtool doesn't work with lib-path.patch (below)
+EXTRA_OEMAKE += "LIBTOOL='${HOST_SYS}-libtool'"
+
 do_configure () {
 	gnu-configize
         oe_runconf
 }
 
-SRC_URI = "${SOURCEFORGE_MIRROR}/${PN}/${P}.tgz"
+SRC_URI = "${SOURCEFORGE_MIRROR}/${PN}/${P}.tgz \
+        file://lib-path.patch \
+"
 SRC_URI[md5sum] = "02c6b89b8ff911341b6b6d4a6c621ea9"
 SRC_URI[sha256sum] = "a13f5ef40ed75d89543b9cd086185121dead9fc7de850ca4d2edd9a0cec12205"
 
-- 
1.7.1


[-- Attachment #3: 2.xmlrpc-ldflags.patch.txt --]
[-- Type: text/plain, Size: 942 bytes --]

From b46e8e8f762c077347c525bf44e11533daea7038 Mon Sep 17 00:00:00 2001
From: Martin Panter <vadmium à gmail.com>
Date: Thu, 23 Dec 2010 05:09:48 +0000
Subject: [PATCH 2/2] XML-RPC: Fix a "QA issue" about missing "GNU_HASH"

Pass LDFLAGS to the Make files which contains the flags to stop this
---
 recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb b/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb
index 46d3a8d..d496fc3 100644
--- a/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb
+++ b/recipes/xmlrpc-c/xmlrpc-c_1.06.41.bb
@@ -19,6 +19,9 @@ inherit autotools binconfig
 # Older internal Libtool doesn't work with lib-path.patch (below)
 EXTRA_OEMAKE += "LIBTOOL='${HOST_SYS}-libtool'"
 
+# The Make files seem to overwrite LDFLAGS with the contents of LADD
+EXTRA_OEMAKE += "LADD='${LDFLAGS}'"
+
 do_configure () {
 	gnu-configize
         oe_runconf
-- 
1.7.1

Re: QA issue with staging (workdir) for .la files in xmlrpc-c package

[Khem Raj]

On 12/23/2010 1:44 AM, Martin Panter wrote:
> On 23 December 2010 18:43, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com>  wrote:
>> 2010/12/23 Martin Panter<vadmium+floss@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@gmail.com>  wrote:
>> 2010/12/23 Martin Panter<vadmium+floss@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?


Yes it a mix of libtool and the xmlrpc-c build system combined issue. 
The patch you provided solved some part of the problem. I have committed 
a modified patch which fixes several problems along with this
one in xmlrpc-c recipe

-Khem