rpcgen should not generate absolute #includes
Every so often (not often enough to remember about this) I move a workspace around, or otherwise build it when its prior location was inaccessible.
It turns out this fails, because libidmap's idmap_xdr.c is generated with an absolute path to idmap_xdr.h within it. It should use workspace-relative paths.
Updated by Gordon Ross over 10 years ago
In the past, I've dealt with this using sed in the Makefile like this:
RPCGENFLAGS = -C -M -i 0
foo_xdr.c : $(FOO_X)
$(RPCGEN) $(RPCGENFLAGS) -c -o $
.tmp $(FOO_X).tmp > $
sed -e $(SED_INCL) < $
$(RM) -f $
Would be nice if rpcgen gave you a little more control instead...
Updated by Gary Mills over 6 years ago
I tried to reproduce this problem, but was unable to do so. It's true that idmap_xdr.c contains an absolute path to the idmap_prot.h header, but the idmap_xdr.c file is also deleted and recreated at the beginning of every build. This happens because the file is added to the CLOBBERFILES macro in Makefile.com .
I don't see any problem here. It's true that rpcgen could be modified to generate a relative path, but that won't provide an immediate solution because the build uses rpcgen from the build host, not the one from illumos.
Makefile.com could also be modified to produce a relative include path.
What should be fixed here? Maybe the bug report should simply be closed.
Updated by Igor Kozhukhov over 6 years ago
i have made some change for using rpcgen from workspace(it built with tools) instead of build host.
i have found that if we have updated rpcgen it will be using only after install it to build host - it is a problem.
my changes works such as: build rpcgen with tools or by 'dmake setup' and use it from tools proto instead of build host.
Updated by Electric Monk over 6 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 77eb9dd4fa1a2a4b00af3d1973a84b60fbf40cdf Author: Gary Mills <firstname.lastname@example.org> Date: 2015-07-02T17:53:15.000Z 687 rpcgen should not generate absolute #includes Reviewed by: Marcel Telka <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>