Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included
Hi,
On 7/11/22 18:30, Aurelien Jarno wrote:
control: tag -1 + moreinfo
Hi,
On 2022-07-11 02:46, Magnus Danielson wrote:
Package: rpcsvc-proto
Version: 1.4.2-4
Severity: grave
Justification: renders package unusable
rpcsvc-proto is used to build many packages in Debian, so I doubt it is
completely unusable.
Fair enough, but for my purpose it failed completely. Of the options
given by text in recommended tool reportbug this was closest to my
experienced situation.
Dear Maintainer,
Template answers first, for your convenience.
* What led up to the situation?
Rebuilding an application using rpcgen.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Run rpcgen, then tried to compile the produced files.
* What was the outcome of this action?
Any of the /usr/include/rpc/* header-files referenced such as
#include <rpc/rpc.h>
etc. fail to include, all the related definitions missing causes large
amount
of compile errors.
Could you please give me more details about the issue? Ideally copy and
paste the error message.
make
rpcgen core.x
gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 -c core_svc.c
In file included from core_svc.c:6:
core.h:9:10: fatal error: rpc/rpc.h: No such file or directory
9 | #include <rpc/rpc.h>
| ^~~~~~~~~~~
compilation terminated.
make: *** [Makefile:514: core_svc.o] Error 1
So, here rpcgen process the core.x, outputting core_clnt.c, core_svc.c,
core_xdr.c and core.h.
The next step is to compile these, and for the case of core_svc.c this
fails because
#include <rpc/rpc.h>
which is generated by rpcgen (there is no such reference in core.x) and
thus needed by users for rpcgen.
I think it is fair to assume that when using rpcgen, the associated
headerfiles needed to compile is either directly or indirectly in the
package (or dependencies of the package).
My guess is that your problem is not related to rpcsvc-proto itself
which just provides rpcgen and related header files, but with the
removal of the SunRPC implementation for glibc. You need to switch to
the TI RPC implementation instead (using the libtirpc-dev package).
Which does not work out, since rpcgen does generate the dependence to
/usr/include/rpc/* and the installed libtirpc-dev delivers the files in
/usr/include/tirpc/rpc/* so despite being installed, gcc does not find
it, and the rpcgen produces files that does not compile.
* What outcome did you expect instead?
Nice compile as headerfiles is found.
This is most likely a consequence of repackaging the rpc-part. Looking back
at
the stable version of libc6 the header files is there in libc6-dev, but for
testing and unstable they are not. I expect that using these this would
work.
If the headerfiles is in another package, dependence on that should be in
place.
The files that are removed from libc6-dev are the ones related to the
removed SunRPC implementation. libc6-dev (indirectly) depends on
libtirpc3-dev so the replacement header files should be available on
your system. That said it is not a one to one replacement, so you need
to use pkgconfig to get the compile and link flags.
Which is documented where for this change?
The repackaging caused generated code that did work fail to work. It
seems that rpcgen is in the wrong package so that it is not managed
alongside the header-files that successful use of the workflow. If you
only depend on the other headerfiles then you see no problem, but for me
using the rpcgen tool to generate the code for the parser I depend on
these header files that is not matching up to where they get elsewhere
delivered. One way to resolve this would be to have the libtirpc-dev
move its header files now that libc6-dev does not deliver them and
neither does rpcsvc-proto. The rpcgen tool should probably be included
into the libtirpc-dev rather than rpcsvc-proto for best coordination.
Never the less, the pieces does not fit as result of this change.
Usually the package-maintainers re-arrange things under the hood such
that normal users do not really see the changes. That did not line up
well here.
I do not mind updating my code with pkg-config, trouble is that I now
need to specify specifically tirpc, which I did not know about was the
new library for the headers, rather than the generic rpc or similar. So
also pkg-config fails to transition silently the baton in this case. So
pkg-config unfortunately does not solve the main problem that is usually
hidden by package maintainance, to change and alter things without
disturbing the user applications.
So, I ended up requiring to know much more about how things changed
implementations and moved behind the scenes in packaging, than is
usually and I fail to find hints in changelog for the package to
indicate this.
Package-testing should actually include a dummy-application that generates
through rpcgen and then compiles it successfully. Then this error would be
caught. Another approach would be to check that the same header files gets
installed from previous packaging and new packaging. Both methods would be
recommended to create fail-safes and quick turn-around for package
maintainers.
Don't hesitate to provide a patch doing that.
For the record, I'm using the core.x out of the VXI11 standard, that is
publically available, and do rpcgen for that. I expected that the
package providing rpcgen either had header files or dependencies to
header files such that generated code compiles. Turns out that in this
case one needs additional specifics how the Debian packaging was
changed. I could trivially provide a test-case that attempts to build
the code, but as it is altered to know about tirpc it would fail to be
representative of normal user usage.
Cheers,
Magnus
Reply to: