RE: Problem compiling glibc with gcc 2.95.3

[David Korn]

>> On Mon, 19 Mar 2001, Venetis Ioannis wrote:
>>>
>>> While compiling the glibc 2.1.3 source a program named 'rpcgen' is 
>>>created in the directory 'sunrpc'. This program is used to further 
>>>compile the library, but when it was invoked I got an error message
>>>telling that it could not find the C preprocessor 'cpp'.

>The error message occurs when executing the following command in the
>Makefile that lies in the directory sunrpc of glibc:
>
>/home/iev/Work/glibc-build2/elf/ld-linux.so.2 \
>--library-path <a very long colon seperated list of directories> \
>/home/iev/Work/glibc-build2/sunrpc/rpcgen -Y \
>`gcc -print-file-name=cpp | sed "s|/cpp$||"` -c 
>rpcsvc/bootparam_prot.x \
>-o /home/iev/Work/glibc-build2/sunrpc/xbootparam_prot.T
>
>cannot find C preprocessor: cpp/cpp
>/home/iev/Work/glibc-build2/sunrpc/rpcgen: C preprocessor 
>failed with exit code 1

  What is going on here is that the rpcgen program is attempting to find
the C preprocessor.

  Due to bad design it is looking for the compiler's private internal
subprogram: it uses a function of the gcc driver that provides the path to
an internal compiler component.  Really, it should be trying to use the
public 'cpp' program.  This is a specialized variant of the gcc driver
program, that assumes the -E flag by default, and so runs only the
preprocessor.

  Unfortunately, the name of the private internal subprogram has changed
between 2.95.2 and 2.95.3; it is now called 'cpp0'.  There is a very good
reason for this: it's dangerous having a driver program called 'cpp' that
tries to find and execute a subprogram that is also called 'cpp', because
with only a slight mixup in the PATH settings or installation, the cpp
driver will find itself, instead of the cpp subprogram, and recursively
call itself forever.  The name of the subprogram was changed to prevent
this bug arising, and give a proper 'file not found' error if the cpp
driver cannot find the internal cpp subprogram.

>ii) glibc doesn't use the correct method to determine the full path to the
>C preprocessor

  I feel that this is the answer.

  It's kind of dangerous for one program to assume it knows too much
about the internals of another, and this is a perfect example of why.  I
guess that because gcc and glibc are quite closely tied to each other,
it seemed like a reasonable design decision.  However it's certainly
broken now.

  If you want a quick fix, edit the makefile in the sunrpc subdirectory,
changing the part that says

    `gcc -print-file-name=cpp | sed "s|/cpp$||"`

to say

    `gcc -print-file-name=cpp0 | sed "s|/cpp0$||"`


  I can think of several ways to make longer term fixes:

1) gcc-2.95.3+ could notice when it was being asked for the internal
subprogram 'cpp' and return the result as if it had been asked for 'cpp0'.
This is a bit of a nasty hack, as it would fail if someone asked for 
the path to cpp and then stripped off the path and appended the filename
themselves.

2) glibc could be fixed so that it knows (according to the gcc version
number) whether to look for 'cpp' or 'cpp0'

3) glibc could be made to look for the public cpp driver that lives in
$prefix/$target/bin, instead of the compiler's internal subprogram.  There
may be some good reason why it wants the subprogram rather than the
public interface, but I can't guess why off the top of my head.

  I've x-posted this to the libc bugs mailing list (of which I'm not a 
subscriber) in order to alert them to the problem.


     DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************