Bug 14303 - rpcgen looks for "cpp" in /lib, but not in /usr/bin
Summary: rpcgen looks for "cpp" in /lib, but not in /usr/bin
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: nis (show other bugs)
Version: 2.15
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-27 14:54 UTC by Arjan van de Ven
Modified: 2014-06-18 04:31 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
add /usr/bin to the places to search (583 bytes, patch)
2012-06-27 14:54 UTC, Arjan van de Ven
Details | Diff
Use execvp to fall back to system cpp (612 bytes, patch)
2012-07-14 08:25 UTC, Allan McRae
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arjan van de Ven 2012-06-27 14:54:39 UTC
Created attachment 6491 [details]
add /usr/bin to the places to search

attached patch solves the issue

rpcgen by default looks for /lib/cpp only (well and some sun specific weird path), but not in "/usr/bin", where gcc installs it. gcc does not install a /lib/cpp symlink. (although many distros manually add it, I suppose for rpcgen's sake)

patch makes it look also in /usr/bin.
I had to restructure the code slightly to avoid having a 3rd nested if, but it's really only 3 new lines of code
Comment 1 Allan McRae 2012-07-06 15:40:20 UTC
There are other patches floating around to do this.

The one attached to https://bugzilla.redhat.com/show_bug.cgi?id=456089 makes an array of paths to search.  That would be easier to extend.

Others use execvp to call cpp and so use the system path, although I doubt that will detect /lib/cpp and /usr/ccs/lib/cpp will not be a PATH so that would not be backwards compatible.
Comment 2 Arjan van de Ven 2012-07-06 15:48:15 UTC
there are obviously many ways to skin this cat
I went for "least invasive to clearly very old code"
Comment 3 Rich Felker 2012-07-06 17:21:19 UTC
Isn't /lib/cpp usually a "traditional" (non-ANSI/ISO-conformant) "C preprocessor" used for non-C-language config file preprocessing, etc.? I may be wrong, but if so, it seems like it could be useful/desirable to have this somewhere outside the normal bin path so that the "cpp" in the path can actually be a conformant C preprocessor.
Comment 4 Andreas Jaeger 2012-07-06 17:26:40 UTC
Btw. my system has as /lib/cpp the following script:

#!/bin/sh
# Traditionally, /lib/cpp only knew about C.
exec /usr/bin/cpp -xc "$@"
Comment 5 Arjan van de Ven 2012-07-06 17:33:18 UTC
interesting discussion.

but the real question is .. what does rpcgen expect for its own use
and afaics that's just the normal /usr/bin/cpp anyway.
Comment 6 Allan McRae 2012-07-14 08:25:32 UTC
Created attachment 6530 [details]
Use execvp to fall back to system cpp

How about the attached patch using execvp to fall back to using the system cpp?  This saves hardcoding another path.
Comment 7 Allan McRae 2012-07-14 08:30:18 UTC
> what does rpcgen expect for its own use

It appears to need a vey basic C pre-processor so /usr/bin/cpp from gcc is more than enough.
Comment 8 Andreas Jaeger 2012-07-25 18:01:37 UTC
Allan, I like your patch. could you send it to libc-alpha for review, please?
Comment 9 Andreas Jaeger 2012-08-08 07:20:25 UTC
This has been fixed now, thanks for the report.

commit bf9b740a119eecf01499b4de0dc8cbd27b7c47bd
Author: Allan McRae <allan@archlinux.org>
Date:   Sat Aug 4 12:19:09 2012 +1000

    rpcgen - fall back to looking for cpp in system path
    
    Fall back to the system cpp when /lib/cpp is not present. Removes
    searching for /usr/ccs/lib/cpp which is not supported on any system that
    uses glibc.