Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[H . J . Lu]

On Sat, May 20, 2000 at 09:51:33AM -0700, Mark Mitchell wrote:
> 
>     Alexandre> Another alternative to solve this problem, that occurs
>     Alexandre> to me only now, is to append -B${prefix}/${target}/ to
>     Alexandre> the GCC invocation line.
> 
> Yes, that sounds like a better solution.
> 

Ok, here is the patch. I also swapped the order of -B./ | -B$$r/gcc
and -B$(build_tooldir)/bin/ since the last one will be used and we want
to use the one in gcc. For ia64, binutils changed a few times. If we
have -B./ -B$(build_tooldir)/bin/ and -B$$r/gcc -B$(build_tooldir)/bin/,
the old one in $(build_tooldir)/bin/ will be used. As the result, we
get some strange errors.

Thanks for everyone.


H.J.
---
20000-05-20  H.J. Lu  (hjl@gnu.org)

	* gcc/Makefile.in (GCC_FOR_TARGET): Make sure as/ld in the gcc
	directory are used if they exist. Make sure
	$(build_tooldir)/include is searched for header files,
	$(build_tooldir)/lib/ for library files.
	* Makefile (CC_FOR_TARGET): Likewise.
	(CXX_FOR_TARGET): Likewise.

--- gcc/Makefile.in.tool	Wed May 17 14:48:00 2000
+++ gcc/Makefile.in	Wed May 17 14:52:07 2000
@@ -162,7 +162,7 @@ INSTALL_ASSERT_H = install-assert-h
 # The GCC to use for compiling libgcc2.a, enquire, and libgcc1-test.
 # Usually the one we just built.
 # Don't use this as a dependency--use $(GCC_PASSES) or $(GCC_PARTS).
-GCC_FOR_TARGET = ./xgcc -B$(build_tooldir)/bin/ -B./ -isystem $(build_tooldir)/include
+GCC_FOR_TARGET = ./xgcc -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B./ -isystem $(build_tooldir)/include
 
 # This is used instead of ALL_CFLAGS when compiling with GCC_FOR_TARGET.
 # It omits XCFLAGS, and specifies -B./.
--- Makefile.in.tool	Wed May 17 14:47:52 2000
+++ Makefile.in	Wed May 17 16:37:27 2000
@@ -226,7 +226,7 @@ CC_FOR_TARGET = ` \
 	  ;; \
       esac \
     else \
-      echo $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/bin/; \
+      echo $$r/gcc/xgcc -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$$r/gcc/ -isystem $(build_tooldir)/include; \
     fi; \
   else \
     if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \
@@ -240,7 +240,7 @@ CC_FOR_TARGET = ` \
 # variable is passed down to the gcc Makefile, where it is used to
 # build libgcc2.a.  We define it here so that it can itself be
 # overridden on the command line.
-GCC_FOR_TARGET = $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/bin/ -I$(build_tooldir)/include
+GCC_FOR_TARGET = $$r/gcc/xgcc -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$$r/gcc/ -I$(build_tooldir)/include
 
 CHILL_FOR_TARGET = ` \
   if [ -f $$r/gcc/xgcc ] ; then \
@@ -269,7 +269,7 @@ CXX_FOR_TARGET = ` \
 	  ;; \
       esac \
     else \
-      echo $$r/gcc/g++ -B$$r/gcc/ -B$(build_tooldir)/bin/; \
+      echo $$r/gcc/g++ -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$$r/gcc/ -I$(build_tooldir)/include; \
     fi; \
   else \
     if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On May 21, 2000, "H . J . Lu" <hjl@valinux.com> wrote:

> Ok, here is the patch. I also swapped the order of -B./ | -B$$r/gcc
> and -B$(build_tooldir)/bin/ since the last one will be used and we want
> to use the one in gcc.

AFAIK, multiple -B flags accumulate, and they're searched
left-to-right.  Therefore, the change is actually arranging for
installed binaries to be preferred over non-installed ones, which is
obviously wrong.  BTW, wouldn't it cause the installed `cpp' driver to
be found when what we want is the actual preprocessor, in the gcc
build directory?

> For ia64, binutils changed a few times. If we have -B./
> -B$(build_tooldir)/bin/ and -B$$r/gcc -B$(build_tooldir)/bin/, the
> old one in $(build_tooldir)/bin/ will be used. As the result, we get
> some strange errors.

This is really strange.  There must be something wrong with -B
handling, then.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[H . J . Lu]

On Sun, May 21, 2000 at 08:43:32PM -0300, Alexandre Oliva wrote:
> On May 21, 2000, "H . J . Lu" <hjl@valinux.com> wrote:
> 
> > Ok, here is the patch. I also swapped the order of -B./ | -B$$r/gcc
> > and -B$(build_tooldir)/bin/ since the last one will be used and we want
> > to use the one in gcc.
> 
> AFAIK, multiple -B flags accumulate, and they're searched
> left-to-right.  Therefore, the change is actually arranging for
> installed binaries to be preferred over non-installed ones, which is
> obviously wrong.  BTW, wouldn't it cause the installed `cpp' driver to
> be found when what we want is the actual preprocessor, in the gcc
> build directory?

I have verified that the last valid -B will be used, at least it
is the case for gcc 2.95 and ia64 gcc. I don't think it is changed
in gcc 3.0.

You can put some dummy "as" in some directories. Those dummy "as"
just echo something you can tell them apart. Then use -B to see
which one is called.

H.J.

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[Jim Wilson]

In article < orbt1z5v17.fsf@tamanduatei.dcc.unicamp.br > you write:
>AFAIK, multiple -B flags accumulate, and they're searched
>left-to-right.

-B flags are prepended to gcc's internal search lists.  Hence, the last
one specified is the first one searched, and they are searched right to left.
It has always been this way.

The part of H.J.'s patch that puts the gcc -B option last is correct.
When -B flags were added to the Makefiles, there were put in the wrong order,
and no one noticed for a long time because the order matters only when
binutils changes in an incompatible way.

The part of H.J.'s patch that I don't understand is why he adds a
-B option pointing to a library directory: -B$(build_tooldir)/lib/.
There are no executables there, so adding a -B option for that directory
seems wrong and unnecessary.

Jim

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[H . J . Lu]

On Mon, May 22, 2000 at 03:55:23PM -0700, Jim Wilson wrote:
> In article < orbt1z5v17.fsf@tamanduatei.dcc.unicamp.br > you write:
> >AFAIK, multiple -B flags accumulate, and they're searched
> >left-to-right.
> 
> -B flags are prepended to gcc's internal search lists.  Hence, the last
> one specified is the first one searched, and they are searched right to left.
> It has always been this way.
> 
> The part of H.J.'s patch that puts the gcc -B option last is correct.
> When -B flags were added to the Makefiles, there were put in the wrong order,
> and no one noticed for a long time because the order matters only when
> binutils changes in an incompatible way.
> 
> The part of H.J.'s patch that I don't understand is why he adds a
> -B option pointing to a library directory: -B$(build_tooldir)/lib/.
> There are no executables there, so adding a -B option for that directory
> seems wrong and unnecessary.
> 

You are right.  -B$(build_tooldir)/lib/ is not necessary for gcc. But
it is needed for the top level Makefile.in. Otherwise, the target
libiberty won't configure:

configure:1765: /work/ia64/bin/cygnus/20000501/gcc/xgcc -B/usr/ia64-cygnus-linux/ia64-cygnus-linux/bin/ -I/usr/ia64-cygnus-linux/ia64-cygnus-linux/include -B/work/ia64/bin/cygnus/20000501/gcc/ -o conftest -g -O2  -pipe -Dno_inhibit_libc   conftest.c  1>&5
lt-ld-new: cannot open crt1.o: No such file or directory
collect2: ld returned 1 exit status
configure: failed program was:

#line 1760 "configure"
#include "confdefs.h"

main(){return(0);}


H.J.
---
20000-05-22  H.J. Lu  (hjl@gnu.org)

	* Makefile.in (CC_FOR_TARGET): Make sure as/ld in the gcc
	directory are used if they exist. Make sure
	$(build_tooldir)/include is searched for header files,
	$(build_tooldir)/lib/ for library files.
	(GCC_FOR_TARGET): Likewise.
	(CXX_FOR_TARGET): Likewise.

--- Makefile.in.tool	Wed May 17 14:47:52 2000
+++ Makefile.in	Wed May 17 16:37:27 2000
@@ -226,7 +226,7 @@ CC_FOR_TARGET = ` \
 	  ;; \
       esac \
     else \
-      echo $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/bin/; \
+      echo $$r/gcc/xgcc -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$$r/gcc/ -isystem $(build_tooldir)/include; \
     fi; \
   else \
     if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \
@@ -240,7 +240,7 @@ CC_FOR_TARGET = ` \
 # variable is passed down to the gcc Makefile, where it is used to
 # build libgcc2.a.  We define it here so that it can itself be
 # overridden on the command line.
-GCC_FOR_TARGET = $$r/gcc/xgcc -B$$r/gcc/ -B$(build_tooldir)/bin/ -I$(build_tooldir)/include
+GCC_FOR_TARGET = $$r/gcc/xgcc -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$$r/gcc/ -I$(build_tooldir)/include
 
 CHILL_FOR_TARGET = ` \
   if [ -f $$r/gcc/xgcc ] ; then \
@@ -269,7 +269,7 @@ CXX_FOR_TARGET = ` \
 	  ;; \
       esac \
     else \
-      echo $$r/gcc/g++ -B$$r/gcc/ -B$(build_tooldir)/bin/; \
+      echo $$r/gcc/g++ -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$$r/gcc/ -I$(build_tooldir)/include; \
     fi; \
   else \
     if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[Jim Wilson]

	lt-ld-new: cannot open crt1.o: No such file or directory

I've been building ia64 cross compilers for over a year, and have never seen
this problem.  Granted, I've mostly been using Cygnus sources not FSF sources,
so there might be some patch that we forgot to contribute.  However, I 
suspect the real problem is that you are somehow configuring the toolchain
wrong.  Unfortunately, you haven't given any explanation of what you are
doing.  All you've said is that whatever you are doing doesn't work, and the
only conclusion I can draw from that is that you must be doing something wrong.

I even think I know what you are doing wrong.  I suspect that you aren't
using the --with-headers and --with-libs configure options.

I suggest you start at the beginning, with a gcc-XXX.tar.gz file, and give a
complete explaination of what you do to reach the point where crt1.o is not
found.  This must be complete enough so that someone else can reproduce what
you are doing and get the same error.

Once we have that, we can decide how to fix the problem.  Perhaps we will
want to convince you to use the --with-headers/--with-libs options.  Or perhaps
we will want to make changes that allow your configure/build method to work.

Another thing here, it would be useful if you sent separate patches for
separate problems.  The -B ordering problem is obvious to me, and I am
willing to approve that patch.  But the patch you submitted fixes two
separate problems, and I do not accept the solution for the second problem,
and hence I can not approve the patch as submitted.

Jim

Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html

[H . J . Lu]

On Mon, May 22, 2000 at 06:47:24PM -0700, Jim Wilson wrote:
> 
> I even think I know what you are doing wrong.  I suspect that you aren't
> using the --with-headers and --with-libs configure options.
> 
> I suggest you start at the beginning, with a gcc-XXX.tar.gz file, and give a
> complete explaination of what you do to reach the point where crt1.o is not
> found.  This must be complete enough so that someone else can reproduce what
> you are doing and get the same error.
> 
> Once we have that, we can decide how to fix the problem.  Perhaps we will
> want to convince you to use the --with-headers/--with-libs options.  Or perhaps
> we will want to make changes that allow your configure/build method to work.

I have ia64 libraries and heade files under
/usr/ia64-cygnus-linux/ia64-cygnus-linux/

I configure the ia64 tool chain as

# /work/ia64/import/cygnus/20000501/src/configure --with-gcc-version-trigger=/work/ia64/import/cygnus/20000501/src/gcc/version.c --host=i686-pc-linux-gnu --target=ia64-cygnus-linux --enable-cpp --enable-shared --prefix=/usr/ia64-cygnus-linux --enable-languages=c,c++--with-local-prefix=/usr/ia64-cygnus-linux 

/usr is owned by root and I build it as myself. As for as I can tell,
--with-headers/--with-libs will try to copy things over to
/usr/ia64-cygnus-linux/ia64-cygnus-linux/ during configure. It
doesn't make much senses to me:

1. I am not root. I have no permission to write to /usr.
2. Those headers and libs are already under

/usr/ia64-cygnus-linux/ia64-cygnus-linux/

I don't know why I have to do it anyway.

Assuming --with-headers/--with-libs works for me, which doesn't, I
get exactly the same as before. I must have done something wrong.
Could you please tell me the correct way to build a ia64 cross
tool chain from Linux/ia32 using the existing GNU C library Linux/ia64
binaries?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

$(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

To resurrect a thread from May...

Jim Wilson <wilson@cygnus.com> writes:

> The part of H.J.'s patch that I don't understand is why he adds a
> -B option pointing to a library directory: -B$(build_tooldir)/lib/.
> There are no executables there, so adding a -B option for that directory
> seems wrong and unnecessary.

Presumably because -B also adds to startfile_prefixes; the same
unlibsubdir problem that caused us to define build_tooldir for
executables would also affect the libraries and startfiles.

But then why don't we also need a -L$(build_tooldir)/lib?

Jason

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Fri, Jul 21, 2000 at 01:17:02AM -0700, Jason Merrill wrote:
> To resurrect a thread from May...
> 
> Jim Wilson <wilson@cygnus.com> writes:
> 
> > The part of H.J.'s patch that I don't understand is why he adds a
> > -B option pointing to a library directory: -B$(build_tooldir)/lib/.
> > There are no executables there, so adding a -B option for that directory
> > seems wrong and unnecessary.
> 
> Presumably because -B also adds to startfile_prefixes; the same
> unlibsubdir problem that caused us to define build_tooldir for
> executables would also affect the libraries and startfiles.

Exactly. BTW, you won't see it if you use newlib. It is too bad not
many people use glibc for cross compiling instead of newlibc. At least,
they don't maintain gcc :-(. It is a fun to build a complete cross
compiler from Linux/ia32 to Linux/ia64 :-). You will see a few build
problems.

> 
> But then why don't we also need a -L$(build_tooldir)/lib?

Because -B$(build_tooldir)/lib/ also adds $(build_tooldir)/lib to
ld's library search path, why do I need to add it again by
-L$(build_tooldir)/lib?


H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Geoff Keating]

> Date: Fri, 21 Jul 2000 07:49:20 -0700
> From: "H . J . Lu" <hjl@lucon.org>

> Exactly. BTW, you won't see it if you use newlib. It is too bad not
> many people use glibc for cross compiling instead of newlibc. At least,
> they don't maintain gcc :-(. It is a fun to build a complete cross
> compiler from Linux/ia32 to Linux/ia64 :-). You will see a few build
> problems.

Actually, at Red Hat we cross-compile to various versions of linux all
the time, and our release engineering people don't see any particular
problems that would be fixed by this patch.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Fri, Jul 21, 2000 at 10:46:30AM -0700, Geoff Keating wrote:
> > Date: Fri, 21 Jul 2000 07:49:20 -0700
> > From: "H . J . Lu" <hjl@lucon.org>
> 
> > Exactly. BTW, you won't see it if you use newlib. It is too bad not
> > many people use glibc for cross compiling instead of newlibc. At least,
> > they don't maintain gcc :-(. It is a fun to build a complete cross
> > compiler from Linux/ia32 to Linux/ia64 :-). You will see a few build
> > problems.
> 
> Actually, at Red Hat we cross-compile to various versions of linux all
> the time, and our release engineering people don't see any particular
> problems that would be fixed by this patch.

Well, it starts all over again :-). When you build the Linux cross
compiling environment, which includes gcc, ld, as, libiberty and
libstdc++ in one pass, how do you find the crt files under
$(build_tooldir)/lib?  They are needed at least by the target version
of libiberty. Gcc finds them by

$(prefix)/lib/gcc-lib/cpu-vendor-os/version/../../../../cpu-vendor-os/lib

When you build the new verion of the compiler the first time,

$(prefix)/lib/gcc-lib/cpu-vendor-os/version

may not exist. Gcc won't find those crt files and the build will fail
at least in the target version of libiberty. That is what
-B$(build_tooldir)/lib/ is used for.



H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jim Wilson]

There are certainly differences in the build process.  HJ doesn't like to use
the --with-headers= and --with-libs= options that we recommend.  I believe he
prefers to build gcc and glibc at the same time, kind of like we do with
newlib, but a lot more complicated.

If we are to make any progress on this, H.J. has to document his build process
sufficiently for others to reproduce it.  The last time I asked this question,
H.J. reported what gcc configure command he was using, but didn't explain
where binutils came from, or where glibc came from.  I haven't tried using
his gcc configure command, but perhaps there was enough info there if someone
has time to try it.  See
    http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01291.html

I suspect that the real problem might be at configuration time.  HJ tends to
use a lot of configure options that we don't use.  HJ uses --enable-shared a
lot more often than we do.  Perhaps he built and installed a shared library in
$tooldir/lib and needs a -B option pointing there so that the shared library
will be found?

Jim

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Fri, Jul 21, 2000 at 11:54:04AM -0700, Jim Wilson wrote:
> H.J. reported what gcc configure command he was using, but didn't explain
> where binutils came from, or where glibc came from.  I haven't tried using
> his gcc configure command, but perhaps there was enough info there if someone
> has time to try it.  See
>     http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01291.html
> 

Thanks for taking it up again. I put my ia64 glibc at

http://ftp.valinux.com/pub/support/hjl/bugs/cross/ia64-cygnus-linux-glibc.tar.gz

If you untar it under /usr/ia64-cygnus-linux, you will get ia64 glibc
header and libraries under /usr/ia64-cygnus-linux/ia64-cygnus-linux.
I used

# ../configure --target=ia64-cygnus-linux
	--enable-shared \
	--enable-cpp \
	--prefix=/usr/ia64-cygnus-linux \
	--enable-languages=c,c++ \
	--with-local-prefix=/usr/ia64-cygnus-linux

to configure the 20000501 ia64 toolkit snapshot. I tried 
--with-headers/--with-libs. I couldn't get it to work.

Thanks.


H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

>>>>> Jim Wilson <wilson@cygnus.com> writes:

 > There are certainly differences in the build process.  HJ doesn't like
 > to use the --with-headers= and --with-libs= options that we recommend.

I don't see how those options would help; as far as I can tell, all they do
is copy the headers and libs from the specified locations into $(tooldir)
and suppress newlib.  They don't seem to affect at all how the headers and
libs are found.

When you build an ia64 toolchain, where does your crt0.o live?  How does
the compiler find it?

Jason

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Geoff Keating]

> Cc: Geoff Keating <geoffk@cygnus.com>, hjl@lucon.org, aoliva@cygnus.com,
>         gcc-patches@gcc.gnu.org, binutils@sourceware.cygnus.com
> From: Jason Merrill <jason@redhat.com>
> Date: 21 Jul 2000 14:19:27 -0700
> 
> >>>>> Jim Wilson <wilson@cygnus.com> writes:
> 
>  > There are certainly differences in the build process.  HJ doesn't like
>  > to use the --with-headers= and --with-libs= options that we recommend.
> 
> I don't see how those options would help; as far as I can tell, all they do
> is copy the headers and libs from the specified locations into $(tooldir)
> and suppress newlib.  They don't seem to affect at all how the headers and
> libs are found.
> 
> When you build an ia64 toolchain, where does your crt0.o live?  How does
> the compiler find it?

I wouldn't try to do much work in this area for a bit.  Red Hat is
working on some major changes to how hostXhost toolchains work.  Under
the new scheme, you'll find crt0.o in

$prefix/sys-root/lib/crt0.o
or
$prefix/sys-root/usr/lib/crt0.o

depending on whether it'd be in /lib or /usr/lib in a native
environment.

(The current status is that it's all done but for linker issues---the
ideal would be that you could just copy /lib and /usr/lib and
/usr/include and whatever else, but on linux /usr/lib/libc.so is a ld
script file, with absolute pathnames, and so we want to reinterpret
the absolute pathnames relative to $prefix/sys-root, and probably for
other linker scripts too so that if they work on the native they'll
work in a cross envirnment.  Unfortunately the engineer involved is
swamped with other stuff right now.  Feedback would probably be
interesting.)
-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Fri, Jul 21, 2000 at 02:48:46PM -0700, Geoff Keating wrote:
> > Cc: Geoff Keating <geoffk@cygnus.com>, hjl@lucon.org, aoliva@cygnus.com,
> >         gcc-patches@gcc.gnu.org, binutils@sourceware.cygnus.com
> > From: Jason Merrill <jason@redhat.com>
> > Date: 21 Jul 2000 14:19:27 -0700
> > 
> > >>>>> Jim Wilson <wilson@cygnus.com> writes:
> > 
> >  > There are certainly differences in the build process.  HJ doesn't like
> >  > to use the --with-headers= and --with-libs= options that we recommend.
> > 
> > I don't see how those options would help; as far as I can tell, all they do
> > is copy the headers and libs from the specified locations into $(tooldir)
> > and suppress newlib.  They don't seem to affect at all how the headers and
> > libs are found.
> > 
> > When you build an ia64 toolchain, where does your crt0.o live?  How does
> > the compiler find it?
> 
> I wouldn't try to do much work in this area for a bit.  Red Hat is
> working on some major changes to how hostXhost toolchains work.  Under
> the new scheme, you'll find crt0.o in
> 
> $prefix/sys-root/lib/crt0.o
> or
> $prefix/sys-root/usr/lib/crt0.o
> 
> depending on whether it'd be in /lib or /usr/lib in a native
> environment.
> 
> (The current status is that it's all done but for linker issues---the
> ideal would be that you could just copy /lib and /usr/lib and
> /usr/include and whatever else, but on linux /usr/lib/libc.so is a ld
> script file, with absolute pathnames, and so we want to reinterpret
> the absolute pathnames relative to $prefix/sys-root, and probably for
> other linker scripts too so that if they work on the native they'll
> work in a cross envirnment.  Unfortunately the engineer involved is
> swamped with other stuff right now.  Feedback would probably be
> interesting.)

Here is my feedback. Given that we don't know when the new scheme
will be good enough for real use and my patch is very small, unless
my patch breaks something, I don't see why not give it a try.


H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jim Wilson]

	I wouldn't try to do much work in this area for a bit.  Red Hat is
	working on some major changes to how hostXhost toolchains work.

Presumably this is the stuff that Brendan Kehoe started?  He did post a patch
	   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00641.html
but the current stuff might be a bit different as that was 6 months ago.
It would be useful to know if this mechanism works for H.J. as he has his
own contraints that are rather different from ours.

Jim

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Fri, Jul 21, 2000 at 03:05:49PM -0700, Jim Wilson wrote:
> 	I wouldn't try to do much work in this area for a bit.  Red Hat is
> 	working on some major changes to how hostXhost toolchains work.
> 
> Presumably this is the stuff that Brendan Kehoe started?  He did post a patch
> 	   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00641.html
> but the current stuff might be a bit different as that was 6 months ago.
> It would be useful to know if this mechanism works for H.J. as he has his
> own contraints that are rather different from ours.
> 

Thanks for the pointer. But I prefer my small patch for my own use.
It is easy to maintain and works for me.

BTW, Jim, does your patch

2000-07-05  Jim Wilson  <wilson@cygnus.com>

        * Makefile.in (CXX_FOR_TARGET): Add libstdc++ to the library
        search path for a g++ extracted from the build tree.  This
        will allow link tests run by configure scripts in
        subdirectories to succeed.

work with libstdc++ v3 enabled? When libstdc++ v3 is is enabled, there
is no $(TARGET_SUBDIR)/libstdc++, but $(TARGET_SUBDIR)/libstdc++-v3
with totally different directory layout for header files and libraries.


H.J.

H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Geoff Keating]

> cc: jason@redhat.com, hjl@lucon.org, aoliva@cygnus.com,
>         gcc-patches@gcc.gnu.org, binutils@sourceware.cygnus.com,
>         angela@cygnus.com
> Date: Fri, 21 Jul 2000 15:05:49 -0700
> From: Jim Wilson <wilson@cygnus.com>
> 
> 	I wouldn't try to do much work in this area for a bit.  Red Hat is
> 	working on some major changes to how hostXhost toolchains work.
> 
> Presumably this is the stuff that Brendan Kehoe started?  He did post a patch
> 	   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00641.html
> but the current stuff might be a bit different as that was 6 months ago.
> It would be useful to know if this mechanism works for H.J. as he has his
> own contraints that are rather different from ours.

It's quite a bit changed from Brendan's work.  I don't know what HJ's
constraints are, so I don't know if it will suit HJ.  If I was trying
to develop a single-tree cross environment, I wouldn't do it the way
HJ seems to be doing it.  Perhaps HJ can explain more?

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Fri, Jul 21, 2000 at 03:12:39PM -0700, Geoff Keating wrote:
> > cc: jason@redhat.com, hjl@lucon.org, aoliva@cygnus.com,
> >         gcc-patches@gcc.gnu.org, binutils@sourceware.cygnus.com,
> >         angela@cygnus.com
> > Date: Fri, 21 Jul 2000 15:05:49 -0700
> > From: Jim Wilson <wilson@cygnus.com>
> > 
> > 	I wouldn't try to do much work in this area for a bit.  Red Hat is
> > 	working on some major changes to how hostXhost toolchains work.
> > 
> > Presumably this is the stuff that Brendan Kehoe started?  He did post a patch
> > 	   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00641.html
> > but the current stuff might be a bit different as that was 6 months ago.
> > It would be useful to know if this mechanism works for H.J. as he has his
> > own contraints that are rather different from ours.
> 
> It's quite a bit changed from Brendan's work.  I don't know what HJ's
> constraints are, so I don't know if it will suit HJ.  If I was trying
> to develop a single-tree cross environment, I wouldn't do it the way
> HJ seems to be doing it.  Perhaps HJ can explain more?

1. I want to be able to build it as a normal user.
2. It shouldn't fail in the middle of a 3 hour build just because I am 
not root. I can live with an error message during configure if root is
really required. But it should tell me what to do in order to build it
as a normal user.
3. It shouldn't require $(build_tooldir)/sys-include has to exist. I
only have $(build_tooldir)/include and $(build_tooldir)/lib, similar
to my native glibc setup.


H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Angela Marie Thomas]

> 	I wouldn't try to do much work in this area for a bit.  Red Hat is
> 	working on some major changes to how hostXhost toolchains work.
> 
> Presumably this is the stuff that Brendan Kehoe started?  He did post a patch
> 	   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00641.html
> but the current stuff might be a bit different as that was 6 months ago.
> It would be useful to know if this mechanism works for H.J. as he has his
> own contraints that are rather different from ours.
> 
> Jim

It's a subset of Brendan's patch plus cleaner configury plus location
independence.  It will work for anyone who wishes to build a properly
working cross compiler targeting what we would call a native host and
is also being tested against vxworks, the only RTOS there is any serious
support for in gcc and which uses the current --with-headers/--with-libs
configury (eCos doesn't count as it does not use a specially configured
compiler).

The intent is for the usage of the cross compiler to be identical to
that of the native compiler equivalent.  A user who has a Makefile which
works for the native compiler equivalent should be able to prepend the
target triple (i.e. sparc-sun-solaris2.5, powerpc-unknown-linux) to the
tools used and produce the same binaries as the native build.

The changes obsolete --with-headers and --with-libs and isolate all of
the potentially proprietary target-specifc files to a single location
(exec-prefix/target/sys-root) which can be updated independently of the
tools modulo rerunning fixincludes in the case of header file updates.

I'm testing against a variety of hosts and so far it's worked extremely
well and solved many of the cross compiler issues we've had in the past.
I'm also planning to test it against the newest ia64 sources to compare
against the behavior of the previous cross compilers we built and tested.

I do not know what constraings H.J. could have which would conflict
with creating a cross compiler which behaves identically to the native
equivalent.  I'd be very interested in hearing what those might be as
I have a great deal of experience working with these compilers as you
well know.

--Angela

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jim Wilson]

	When you build an ia64 toolchain, where does your crt0.o live?  How does
	the compiler find it?

The libraries are copied to $prefix/$target/lib (aka $tooldir/lib) at
configure time.  That is one of the paths that gcc searches by default.
That happens in gcc.c when it adds tooldir_prefix/lib to startfile_prefixes.

Looking at H.J. messages, he says this doesn't work because tooldir is
really $prefix/lib/gcc-lib/$target/$version/../../../../$target/lib
and $prefix/lib/gcc-lib/$target/$version doesn't exist at build time.
But it does.  We deliberately create it so that $tooldir/lib and
$tooldir/sys-include will work.  See the code in the stmp-fixinc rule in the
Makefile.  Nothing needs $libsubdir before then.  If something does need it,
then we should create it earlier.

I believe one of H.J.'s other comments was that he defines prefix to point
somewhere in /usr, and since he isn't root when he is building the toolchain,
the creation of $libsubdir fails.  I think that is a little weak.  But if
this is a concern, then the new scheme doesn't help fix it, because it is
still installing stuff in $prefix at configure/build time.

Jim

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

>>>>> Jim Wilson <wilson@cygnus.com> writes:

 > Looking at H.J. messages, he says this doesn't work because tooldir is
 > really $prefix/lib/gcc-lib/$target/$version/../../../../$target/lib
 > and $prefix/lib/gcc-lib/$target/$version doesn't exist at build time.
 > But it does.  We deliberately create it so that $tooldir/lib and
 > $tooldir/sys-include will work.  See the code in the stmp-fixinc rule in the
 > Makefile.

Hmm.  Then why did we need build_tooldir in the first place?  Alexandre?

Jason

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jim Wilson]

	Hmm.  Then why did we need build_tooldir in the first place?  Alexandre?

If you are doing a one-source build like we do, then you don't need
build_tooldir.  If you build and install binutils first, then you probably
need build_tooldir so that the cross gcc can find the cross as, etc.
The creation of the libsubdir directories in the stmp-fixinc rule probably
doesn't happen soon enough to avoid this problem.  On the other hand, if we
do have the -B/-L/-I options, then we don't need the stuff in the stmp-fixinc
rule anymore, and you don't have to worry about ordering problems, so that
may make the Makefile dependencies simpler.

Jim

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

>>>>> Jim Wilson <wilson@cygnus.com> writes:

 > On the other hand, if we do have the -B/-L/-I options, then we don't
 > need the stuff in the stmp-fixinc rule anymore, and you don't have to
 > worry about ordering problems, so that may make the Makefile
 > dependencies simpler.

I think that would be my preference; creating stuff in $(prefix) as part of
the build seems pretty ugly to me.

Jason

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Alexandre Oliva]

On Jul 21, 2000, Jason Merrill <jason@redhat.com> wrote:

>>>>>> Jim Wilson <wilson@cygnus.com> writes:
>> On the other hand, if we do have the -B/-L/-I options, then we don't
>> need the stuff in the stmp-fixinc rule anymore, and you don't have to
>> worry about ordering problems, so that may make the Makefile
>> dependencies simpler.

> I think that would be my preference; creating stuff in $(prefix) as
> part of the build seems pretty ugly to me.

Agreed.  But it may (re-)open a can of worms for all other projects
built in the same build tree.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

>>>>> Alexandre Oliva <aoliva@redhat.com> writes:

 > On Jul 21, 2000, Jason Merrill <jason@redhat.com> wrote:
 >>>>>>> Jim Wilson <wilson@cygnus.com> writes:
 >>> On the other hand, if we do have the -B/-L/-I options, then we don't
 >>> need the stuff in the stmp-fixinc rule anymore, and you don't have to
 >>> worry about ordering problems, so that may make the Makefile
 >>> dependencies simpler.

 >> I think that would be my preference; creating stuff in $(prefix) as
 >> part of the build seems pretty ugly to me.

 > Agreed.  But it may (re-)open a can of worms for all other projects
 > built in the same build tree.

Do any other projects use unlibsubdir?

Jason

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Alexandre Oliva]

On Jul 21, 2000, Jason Merrill <jason@redhat.com> wrote:

> Do any other projects use unlibsubdir?

I don't think so.  It's GCC that does.  GCC creates the directory so
that other projects don't have to care about it: a yet-to-be-installed
GCC will just find libraries that have already been installed.  If GCC
refrains from creating the directory so that it can find pre-installed
libraries and headers, other projects that depend on it finding them
will have to be taught to tell GCC to look for them there.


H.J., I'm willing to play a bit with cross-building GCC, glibc and
maybe even the kernel itself.  Would you be willing to hand-hold me a
little bit, so that I could understand better the issues you're
talking about, then we'll come back to the list with a joint proposal?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[H . J . Lu]

On Sat, Jul 22, 2000 at 12:08:45AM -0300, Alexandre Oliva wrote:
> 
> 
> H.J., I'm willing to play a bit with cross-building GCC, glibc and
> maybe even the kernel itself.  Would you be willing to hand-hold me a
> little bit, so that I could understand better the issues you're
> talking about, then we'll come back to the list with a joint proposal?

Sure. I guess it has to take someone to build a Linux cross compiler
to see the problems. I have been doing it for almost 10 years. I may
have taken many knowledges by granted.

BTW, I have, ia64-linux, ppc-linux and arm-linux cross compilers on
my ia32 machine.


H.J.

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

>>>>> Alexandre Oliva <aoliva@redhat.com> writes:

 > On Jul 21, 2000, Jason Merrill <jason@redhat.com> wrote:
 >> Do any other projects use unlibsubdir?

 > I don't think so.  It's GCC that does.  GCC creates the directory so
 > that other projects don't have to care about it: a yet-to-be-installed
 > GCC will just find libraries that have already been installed.  If GCC
 > refrains from creating the directory so that it can find pre-installed
 > libraries and headers, other projects that depend on it finding them
 > will have to be taught to tell GCC to look for them there.

...by adding -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include to
CC_FOR_TARGET, perhaps?  :)

Jason

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Alexandre Oliva]

On Jul 22, 2000, Jason Merrill <jason@redhat.com> wrote:

> ...by adding -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include to
> CC_FOR_TARGET, perhaps?  :)

Yep.  CC_FOR_TARGET, CXX_FOR_TARGET and any other
<compiler>_FOR_TARGET.  Isn't that what H.J.'s patch does?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html)

[Jason Merrill]

>>>>> Alexandre Oliva <aoliva@redhat.com> writes:

 > On Jul 22, 2000, Jason Merrill <jason@redhat.com> wrote:
 >> ...by adding -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include to
 >> CC_FOR_TARGET, perhaps?  :)

 > Yep.  CC_FOR_TARGET, CXX_FOR_TARGET and any other
 > <compiler>_FOR_TARGET.  Isn't that what H.J.'s patch does?

Yes.  So I'm installing it, along with a whole raft of other changes
brought over from the binutils tree.

Jason