On my system,
'whereis -b cpp' indicates the location is /usr/bin --- an FHS
standard location. Where is that file installed in Arch? Or is the file name
changed in Arch? That would be the path to add with the -Y switch.
In the same spot:
22:13 archangel:/dat_e/abs/util-linux> whereis -b cpp
cpp: /usr/bin/cpp
As /usr/bin is a standard FHS location, I'd like to know where rpcgen is hard-coded to
look for the cpp executable. I hope this is not Yet Another WTF example of egghead
development.
((You really need to install and run at least one
partition
of Arch. Talk about the excitement of trying to iterate down to a final finished
project the size of TDE when the foundation is constantly changing -- wow!
It never gets old...))
I don't have that kind of energy. :-) Rolling releases tend to sound like a great
idea, but these kinds of problems discourage me from going down that road.
Seriously, I think there has rarely been any 3 month
stretch
before in recent history where so many of the underlying libraries have had
significant upstream changes as TDE has tried to dial in a next release -- not to
mention one with the polish and improvement that TDE has undergone to get to
the point of this R14 release.
Little more time on the front end -- better reviews, less
bugs on the backend :)
I suspect people working with other projects have experienced the same issues. A
significant difference is they have more people participating, group knowledge levels are
higher and deeper, and therefore they can resolve these bumps faster. Possibly, because
those other projects have many more people staying in contact with these upstream groups,
I suspect these types of changes get forewarned in one manner or another to those other
groups but not to us.
These upstream changes greatly reflect the scratch-your-own-itch mentality. The upstream
developers might forewarn everybody of upcoming changes, they might not, but they are
going to do whatever they want. Not to mention that the developers who participate in
these dependent upstream projects like gcc and glibc are mostly paid programmers working
for the big shots in the industry, such as RedHat. They aren't going to wait for
people in small projects to voice an opinion.
I think the overall problem is free/libre software changes at a relentless and unforgiving
pace. Free source code is just too much to resist for most software geeks, so they tweak,
and they tweak, and they tweak.... :-)
Darrell