Dear Maintainer,

xmlrpc-c seems to directly run the configure script, and the same
seems to hard-code pkg-config.

Next, it also hard-codes it in config.mk.in and lastly, I see hard
coding in lib/openssl/Makefile though it seems to be unused, but
it is good to fix it anyway.

It should use the value of arch prefixed PKG_CONFIG variable which is setup
by the cross toolchain instead, which also needs to be passed via d/rules.

I've attached a patch that fixes this. Please consider applying.

Thanks
Nilesh

Hi Nilesh,

You are patching a generated file here. The source file is configure.in.

A better approach here would be using:

PKG_CHECK_MODULES([OPENSSL],[openssl],[HAVE_OPENSSL=yes],[HAVE_OPENSSL=no])

This requires regenerating configure (which is not presently happening
during build). The first argument is the variable prefix and the
variables thus become OPENSSL_LIBS and OPENSSL_CFLAGS. While the latter
matches the existing use, OPENSSL_LDADD would need to be renamed
throughout the code base.

If possible (and it often is), please do not call pkg-config from
Makefiles. It is meant to be used at configure time collecting all the
flags to be recorded in Makefiles. Substitute the flags instead.

OPENSSL_LIBS = @OPENSSL_LIBS@
OPENSSL_CFLAGS = @OPENSSL_CFLAGS@

Note that PKG_CHECK_MODULES implies the required AC_SUBST for this.

Once you record the detected flags in config.mk, there is no more need
to invoke pkg-config here.

As PKG_CHECK_MODULES uses AC_PATH_TOOL, this should become unnecessary.

Would you mind trying to produce an alternate version of this patch
based on PKG_CHECK_MODULES to be sent upstream as that change would be
more sustainable long-term? For the Debian side and short term, your
existing patch may be a good compromise (as long as we disable
autoreconf).

Helmut

Hi Helmut,

Right, but as you did say below that the configure is not getting generated
during the build, since d/rules has `dh $@ --without=autoreconf` and so patching
configure.in does not solve the problem on at least debian side.

Enabling autoreconf does not help either since there's no Makefile.am and there are other messy
things in the codebase that I don't think can be fixed with the corresponding build files.

So I am a bit confused on what exactly you think should be done here. Are you asking
me to come up with a patch get it merged upstream so when the configure file is generated
in their next release, it is more cross-friendly?

If so, and if I were to be honest with you, looking at (seemingly tedious process at) https://xmlrpc-c.sourceforge.io/techsupp.php and seeing there are development releases that have
moved forward (wrt current patch), it very much makes me not want to
jump through the upstreaming hoop.

Please let me know your thoughts.

Best,
Nilesh

Hi Nilesh,

Arguably, we do want to run autoreconf eventually. Otherwise, we incur
an rc bug once autoconf2.69 gets removed from unstable. Sometimes making
autoreconf work is part of the solution.

You can run autoconf without automake. More precisely, running
"autoconf2.69 -f -i" actually succeeds for xmlrpc-c. It just so happens
that Debian's autoconf2.69 has no clue about --runstatedir yet, so
dh_auto_configure then fails as it passes that. The configure script at
hand claims to be generated using 2.69, so this is a fairly strong clue
that a different (patched) autoconf2.69 was used for generating this
script. That autoconf is not part of Debian and therefore the source
code for the configure script is actually missing from Debian right now.
That's a DFSG item 2 violation and an rc bug.

Mostly yes.

I agree that going through such hoops is not pleasant, but I still think
that providing a sensible patch and mailing it to the maintainer is a
reasonable thing to do. If they reject such a patch, it's too bad but
then Debian may still use it once autoreconf is working again.

Helmut

Hi Nilesh,

I am attaching a patch for configure.in. Applying it requires running
autoreconf2.69 of course. With little tweaks this is possible:

    AUTOMAKE=true autoreconf2.69 -f -i
    sed -i -e 's/^ *-version/--runstatedir=*) ;; &/' configure

The sed script makes the configure script ignore the --runstatedir
option passed by dh_auto_configure.

This patch uses PKG_CHECK_MODULES and no longer runs pkg-config during
dh_auto_build. I think this is the way to go.

Helmut