[Linux-ia64] The 1117 snapshot cpp problem

[Linux-ia64] The 1117 snapshot cpp problem

[H . J . Lu]

My email sent to ia64-tools@napali.hpl.hp.com went to a black hole :-).
I tried it again here.


H.J.
----- Forwarded message from "H . J . Lu" <hjl@valinux.com> -----

Date: Thu, 4 Jan 2001 14:26:30 -0800
From: "H . J . Lu" <hjl@valinux.com>
To: ia64-tools@napali.hpl.hp.com
Subject: The 1117 snapshot cpp problem.
User-Agent: Mutt/1.2.5i

I guess it is a long standing issue in the Cygnus toolchain. The
problem is this change:

--- gcc/configure.in	Fri Dec 22 13:55:48 2000
+++ gcc/configure.in	Thu Aug 17 12:02:45 2000
@@ -136,15 +136,17 @@ AC_ARG_WITH(elf,
 elf="$with_elf",
 elf=no)
 
-# Specify the local prefix
-local_prefix-AC_ARG_WITH(local-prefix,
-[  --with-local-prefix=DIR specifies directory to put local include.],
-[case "${withval}" in
-yes)	AC_MSG_ERROR(bad value ${withval} given for local include directory prefix) ;;
-no)	;;
-*)	local_prefix=$with_local_prefix ;;
-esac])
+# CYGNUS LOCAL: local_prefix
+#local_prefix+#AC_ARG_WITH(local-prefix,
+#[  --with-local-prefix=DIR specifies directory to put local include.],
+#[case "${withval}" in
+#yes)	AC_MSG_ERROR(bad value ${withval} given for local include directory prefix) ;;
+#no)	;;
+#*)	local_prefix=$with_local_prefix ;;
+#esac])
+local_prefix='$(prefix)'
+# END CYGNUS LOCAL
 
 # Default local prefix if it is empty
 if test x$local_prefix = x; then

Bascallly, it sets local_prefix = prefix, which means

$local_prefix/include = $prefix/include

It is ok and desirable for a cross toolchain as long as you don't
install it under /usr as a native compiler. Unfortunately, RedHat/ia64
does exactly that. That means $local_prefix/include = /usr/include.
Now, gcc will search /usr/include before others. It is not very good
for Linux.

# touch l.c
# gcc -M -v l.c
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/2.96-ia64-000717/specs
gcc version 2.96-ia64-000717 snap 001117
 /usr/lib/gcc-lib/ia64-redhat-linux/2.96-ia64-000717/cpp ...
GNU CPP version 2.96-ia64-000717 snap 001117 (cpplib)
 (IA-64)
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc-lib/ia64-redhat-linux/2.96-ia64-000717/include
 /usr/ia64-redhat-linux/include
End of search list.
l.o: l.c

H.J.

----- End forwarded message -----

Re: [Linux-ia64] The 1117 snapshot cpp problem

[Jim Wilson]

>I guess it is a long standing issue in the Cygnus toolchain. The
>problem is this change:
>Bascallly, it sets local_prefix = prefix, which means
>$local_prefix/include = $prefix/include

>Now, gcc will search /usr/include before others. It is not very good
>for Linux.

Yes, this is a problem.

I've reverted the Cygnus local change in my source tree, and have started
working to get the same change into the main Cygnus source tree.  This will
require changing some local build processes, so it may take a little time.

There is no problem with cross compilers as you suggested, because cross
compilers don't use /usr/local/include.  I believe the original problem was
that we shipped compilers to some customers that had random files in
/usr/local, the customers reported problems, and we had a lot of trouble
debugging the problem.  We fixed it by deciding not to use /usr/local/include
by default anymore.  This was 8 years ago, so Linux usage was not a concern.
Now that we are part of Red Hat, it is a serious concern.

The resulting patch is 100K because configure had to be rebuilt.  I put it
in the usual place, ftp.cygnus.com:/pub/ia64-linux/snap-001117/patch.055.

Jim

Re: [Linux-ia64] The 1117 snapshot cpp problem

[H . J . Lu]

On Wed, Jan 24, 2001 at 01:37:24PM -0800, Jim Wilson wrote:
> >I guess it is a long standing issue in the Cygnus toolchain. The
> >problem is this change:
> >Bascallly, it sets local_prefix = prefix, which means
> >$local_prefix/include = $prefix/include
> 
> >Now, gcc will search /usr/include before others. It is not very good
> >for Linux.
> 
> Yes, this is a problem.
> 
> I've reverted the Cygnus local change in my source tree, and have started
> working to get the same change into the main Cygnus source tree.  This will
> require changing some local build processes, so it may take a little time.
> 
> There is no problem with cross compilers as you suggested, because cross
> compilers don't use /usr/local/include.  I believe the original problem was
> that we shipped compilers to some customers that had random files in
> /usr/local, the customers reported problems, and we had a lot of trouble
> debugging the problem.  We fixed it by deciding not to use /usr/local/include
> by default anymore.  This was 8 years ago, so Linux usage was not a concern.
> Now that we are part of Red Hat, it is a serious concern.
> 
> The resulting patch is 100K because configure had to be rebuilt.  I put it
> in the usual place, ftp.cygnus.com:/pub/ia64-linux/snap-001117/patch.055.
> 

I don't think it works with the gnupro rpm from RedHat. I had to
add the patch enclosed here. I think the problem is includedir in gcc
is overriden from the toplevel Makefile.

-- 
H.J. Lu (hjl@valinux.com)
---
--- gcc/Makefile.in.local	Thu Jan  4 15:21:25 2001
+++ gcc/Makefile.in	Thu Jan  4 15:22:00 2001
@@ -292,7 +292,7 @@ build_tooldir = $(exec_prefix)/$(target_
 # Directory in which the compiler finds g++ includes.
 gcc_gxx_include_dir= @gcc_gxx_include_dir@
 # Directory to search for site-specific includes.
-includedir = $(local_prefix)/include
+localincludedir = $(local_prefix)/include
 # assertdir is overridden in cross-make.
 # (But this currently agrees with what is in cross-make.)
 assertdir = $(gcc_tooldir)/include
@@ -1881,7 +1881,7 @@ intl.distdir-fixup:
 PREPROCESSOR_DEFINES = \
   -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
   -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
-  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
+  -DLOCAL_INCLUDE_DIR=\"$(localincludedir)\" \
   -DCROSS_INCLUDE_DIR=\"$(gcc_tooldir)/sys-include\" \
   -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\"
 
@@ -2447,7 +2447,7 @@ installdirs:
 	  if [ -d $${fdir} ] ; then true ; else mkdir $${fdir}; chmod a+rx $${fdir}; fi ; \
 	done
 	-if [ -d $(bindir) ] ; then true ; else mkdir $(bindir) ; chmod a+rx $(bindir) ; fi
-	-if [ -d $(includedir) ] ; then true ; else mkdir $(includedir) ; chmod a+rx $(includedir) ; fi
+	-if [ -d $(localincludedir) ] ; then true ; else mkdir $(localincludedir) ; chmod a+rx $(localincludedir) ; fi
 	-if [ -d $(gcc_tooldir) ] ; then true ; else mkdir $(gcc_tooldir) ; chmod a+rx $(gcc_tooldir) ; fi
 	-if [ -d $(assertdir) ] ; then true ; else mkdir $(assertdir) ; chmod a+rx $(assertdir) ; fi
 	-if [ -d $(infodir) ] ; then true ; else mkdir $(infodir) ; chmod a+rx $(infodir) ; fi

Re: [Linux-ia64] The 1117 snapshot cpp problem

[Andreas Schwab]

"H . J . Lu" <hjl@valinux.com> writes:

|> On Wed, Jan 24, 2001 at 01:37:24PM -0800, Jim Wilson wrote:
|> > >I guess it is a long standing issue in the Cygnus toolchain. The
|> > >problem is this change:
|> > >Bascallly, it sets local_prefix = prefix, which means
|> > >$local_prefix/include = $prefix/include
|> > 
|> > >Now, gcc will search /usr/include before others. It is not very good
|> > >for Linux.
|> > 
|> > Yes, this is a problem.
|> > 
|> > I've reverted the Cygnus local change in my source tree, and have started
|> > working to get the same change into the main Cygnus source tree.  This will
|> > require changing some local build processes, so it may take a little time.
|> > 
|> > There is no problem with cross compilers as you suggested, because cross
|> > compilers don't use /usr/local/include.  I believe the original problem was
|> > that we shipped compilers to some customers that had random files in
|> > /usr/local, the customers reported problems, and we had a lot of trouble
|> > debugging the problem.  We fixed it by deciding not to use /usr/local/include
|> > by default anymore.  This was 8 years ago, so Linux usage was not a concern.
|> > Now that we are part of Red Hat, it is a serious concern.
|> > 
|> > The resulting patch is 100K because configure had to be rebuilt.  I put it
|> > in the usual place, ftp.cygnus.com:/pub/ia64-linux/snap-001117/patch.055.
|> > 
|> 
|> I don't think it works with the gnupro rpm from RedHat. I had to
|> add the patch enclosed here. I think the problem is includedir in gcc
|> is overriden from the toplevel Makefile.

This is a very old bug that I have already reported twice (see
http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00488.html and
http://gcc.gnu.org/ml/gcc-patches/1999-05/msg00477.html).

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: [Linux-ia64] The 1117 snapshot cpp problem

[H . J . Lu]

On Tue, Feb 06, 2001 at 01:56:13PM +0100, Andreas Schwab wrote:
> |> > 
> |> > There is no problem with cross compilers as you suggested, because cross
> |> > compilers don't use /usr/local/include.  I believe the original problem was
> |> > that we shipped compilers to some customers that had random files in
> |> > /usr/local, the customers reported problems, and we had a lot of trouble
> |> > debugging the problem.  We fixed it by deciding not to use /usr/local/include
> |> > by default anymore.  This was 8 years ago, so Linux usage was not a concern.
> |> > Now that we are part of Red Hat, it is a serious concern.
> |> > 
> |> > The resulting patch is 100K because configure had to be rebuilt.  I put it
> |> > in the usual place, ftp.cygnus.com:/pub/ia64-linux/snap-001117/patch.055.
> |> > 
> |> 
> |> I don't think it works with the gnupro rpm from RedHat. I had to
> |> add the patch enclosed here. I think the problem is includedir in gcc
> |> is overriden from the toplevel Makefile.
> 
> This is a very old bug that I have already reported twice (see
> http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00488.html and
> http://gcc.gnu.org/ml/gcc-patches/1999-05/msg00477.html).

It is ok if you use "make bootstrap" since $(includedir) passed down
is ignored during "make bootstrap" in gcc. But the toolchain may not
be built with "make bootstrap". I believe

"includedir=$(includedir)" \

should not be passed to gcc during any build.


-- 
H.J. Lu (hjl@valinux.com)

Re: [Linux-ia64] The 1117 snapshot cpp problem

[Jim Wilson]

>It is ok if you use "make bootstrap" since $(includedir) passed down
>is ignored during "make bootstrap" in gcc. But the toolchain may not
>be built with "make bootstrap". I believe
>"includedir=$(includedir)" \
>should not be passed to gcc during any build.

I don't like that idea.  It defeats the purpose of having the top level
Makefile, which is to ensure that all tools are compatible with each other.
Binutils for instance uses includedir.  It will install bfd.h there.  So
if binutils uses includedir and gcc does not, then they are no longer
compatible with each other.  binutils will install a header file someplace
where gcc can't find it.

I think this also explains part of the reason why the "Cygnus" tree sets
includedir to $prefix/include.  If you configure a tree setting $prefix, and
then install it, it is wrong to install files into /usr/local/include.
Everything has to be installed underneath $prefix.  This required creating
a new include directory underneath prefix, and making gcc look in it.
Unfortunately, our mistake here was that we replaced /usr/local/include
which other people are using.

This mistake has already been institutionalized by the gcc-2.95 release.
gcc-2.9 supports /usr/local/include.  gcc-2.95 supports $prefix/include.
There are people that want both, so I think we need to support both now.

This requires a bigger change though.  We have to document the new directory,
add support for the new directory to cpp and anyplace else that cares
(protoize?), and fix up the Makefile to pass both directory names on the
compile line for cpp.  This is a big enough change that I was not able to
have it done by yesterday.

Jim