* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html [not found] ` <20000520095133R.mitchell@codesourcery.com> @ 2000-05-20 22:10 ` H . J . Lu 2000-05-21 16:44 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Alexandre Oliva 0 siblings, 1 reply; 32+ messages in thread From: H . J . Lu @ 2000-05-20 22:10 UTC (permalink / raw) To: Mark Mitchell; +Cc: aoliva, gcc-patches, binutils 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 \ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html 2000-05-20 22:10 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu @ 2000-05-21 16:44 ` Alexandre Oliva 2000-05-21 16:51 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 2000-05-22 15:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson 0 siblings, 2 replies; 32+ messages in thread From: Alexandre Oliva @ 2000-05-21 16:44 UTC (permalink / raw) To: H . J . Lu; +Cc: Mark Mitchell, gcc-patches, binutils [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html 2000-05-21 16:44 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Alexandre Oliva @ 2000-05-21 16:51 ` H . J . Lu 2000-05-22 15:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson 1 sibling, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-05-21 16:51 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Mark Mitchell, gcc-patches, binutils 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html 2000-05-21 16:44 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Alexandre Oliva 2000-05-21 16:51 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu @ 2000-05-22 15:54 ` Jim Wilson 2000-05-22 17:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 2000-07-21 1:17 ` $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) Jason Merrill 1 sibling, 2 replies; 32+ messages in thread From: Jim Wilson @ 2000-05-22 15:54 UTC (permalink / raw) To: aoliva; +Cc: H . J . Lu, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html 2000-05-22 15:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson @ 2000-05-22 17:54 ` H . J . Lu 2000-05-22 18:47 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson 2000-07-21 1:17 ` $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) Jason Merrill 1 sibling, 1 reply; 32+ messages in thread From: H . J . Lu @ 2000-05-22 17:54 UTC (permalink / raw) To: Jim Wilson; +Cc: aoliva, gcc-patches, binutils 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 \ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html 2000-05-22 17:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu @ 2000-05-22 18:47 ` Jim Wilson 2000-05-22 20:06 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 0 siblings, 1 reply; 32+ messages in thread From: Jim Wilson @ 2000-05-22 18:47 UTC (permalink / raw) To: H . J . Lu; +Cc: aoliva, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html 2000-05-22 18:47 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson @ 2000-05-22 20:06 ` H . J . Lu 0 siblings, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-05-22 20:06 UTC (permalink / raw) To: Jim Wilson; +Cc: aoliva, gcc-patches, binutils 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) ^ permalink raw reply [flat|nested] 32+ messages in thread
* $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-05-22 15:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson 2000-05-22 17:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu @ 2000-07-21 1:17 ` Jason Merrill 2000-07-21 7:49 ` H . J . Lu 1 sibling, 1 reply; 32+ messages in thread From: Jason Merrill @ 2000-07-21 1:17 UTC (permalink / raw) To: Jim Wilson; +Cc: aoliva, H . J . Lu, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 1:17 ` $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) Jason Merrill @ 2000-07-21 7:49 ` H . J . Lu 2000-07-21 10:38 ` Geoff Keating 0 siblings, 1 reply; 32+ messages in thread From: H . J . Lu @ 2000-07-21 7:49 UTC (permalink / raw) To: Jason Merrill; +Cc: Jim Wilson, aoliva, gcc-patches, binutils 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 7:49 ` H . J . Lu @ 2000-07-21 10:38 ` Geoff Keating 2000-07-21 10:54 ` H . J . Lu 2000-07-21 11:54 ` Jim Wilson 0 siblings, 2 replies; 32+ messages in thread From: Geoff Keating @ 2000-07-21 10:38 UTC (permalink / raw) To: hjl; +Cc: jason, wilson, aoliva, gcc-patches, binutils > 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 10:38 ` Geoff Keating @ 2000-07-21 10:54 ` H . J . Lu 2000-07-21 11:54 ` Jim Wilson 1 sibling, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-07-21 10:54 UTC (permalink / raw) To: Geoff Keating; +Cc: jason, wilson, aoliva, gcc-patches, binutils 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 10:38 ` Geoff Keating 2000-07-21 10:54 ` H . J . Lu @ 2000-07-21 11:54 ` Jim Wilson 2000-07-21 12:12 ` H . J . Lu 2000-07-21 14:19 ` Jason Merrill 1 sibling, 2 replies; 32+ messages in thread From: Jim Wilson @ 2000-07-21 11:54 UTC (permalink / raw) To: Geoff Keating; +Cc: hjl, jason, wilson, aoliva, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 11:54 ` Jim Wilson @ 2000-07-21 12:12 ` H . J . Lu 2000-07-21 14:19 ` Jason Merrill 1 sibling, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-07-21 12:12 UTC (permalink / raw) To: Jim Wilson; +Cc: Geoff Keating, jason, aoliva, gcc-patches, binutils 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 11:54 ` Jim Wilson 2000-07-21 12:12 ` H . J . Lu @ 2000-07-21 14:19 ` Jason Merrill 2000-07-21 14:48 ` Geoff Keating 2000-07-21 15:28 ` Jim Wilson 1 sibling, 2 replies; 32+ messages in thread From: Jason Merrill @ 2000-07-21 14:19 UTC (permalink / raw) To: Jim Wilson; +Cc: Geoff Keating, hjl, aoliva, gcc-patches, binutils >>>>> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 14:19 ` Jason Merrill @ 2000-07-21 14:48 ` Geoff Keating 2000-07-21 14:53 ` H . J . Lu 2000-07-21 15:05 ` Jim Wilson 2000-07-21 15:28 ` Jim Wilson 1 sibling, 2 replies; 32+ messages in thread From: Geoff Keating @ 2000-07-21 14:48 UTC (permalink / raw) To: jason; +Cc: wilson, hjl, aoliva, gcc-patches, binutils, angela > 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 14:48 ` Geoff Keating @ 2000-07-21 14:53 ` H . J . Lu 2000-07-21 15:05 ` Jim Wilson 1 sibling, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-07-21 14:53 UTC (permalink / raw) To: Geoff Keating; +Cc: jason, wilson, aoliva, gcc-patches, binutils, angela 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 14:48 ` Geoff Keating 2000-07-21 14:53 ` H . J . Lu @ 2000-07-21 15:05 ` Jim Wilson 2000-07-21 15:12 ` H . J . Lu ` (2 more replies) 1 sibling, 3 replies; 32+ messages in thread From: Jim Wilson @ 2000-07-21 15:05 UTC (permalink / raw) To: Geoff Keating; +Cc: jason, hjl, aoliva, gcc-patches, binutils, angela 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 15:05 ` Jim Wilson @ 2000-07-21 15:12 ` H . J . Lu 2000-07-21 15:12 ` Geoff Keating 2000-07-21 15:33 ` Angela Marie Thomas 2 siblings, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-07-21 15:12 UTC (permalink / raw) To: Jim Wilson; +Cc: Geoff Keating, jason, aoliva, gcc-patches, binutils, angela 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 15:05 ` Jim Wilson 2000-07-21 15:12 ` H . J . Lu @ 2000-07-21 15:12 ` Geoff Keating 2000-07-21 15:49 ` H . J . Lu 2000-07-21 15:33 ` Angela Marie Thomas 2 siblings, 1 reply; 32+ messages in thread From: Geoff Keating @ 2000-07-21 15:12 UTC (permalink / raw) To: wilson; +Cc: jason, hjl, aoliva, gcc-patches, binutils, angela > 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> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 15:12 ` Geoff Keating @ 2000-07-21 15:49 ` H . J . Lu 0 siblings, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-07-21 15:49 UTC (permalink / raw) To: Geoff Keating; +Cc: wilson, jason, aoliva, gcc-patches, binutils, angela 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 15:05 ` Jim Wilson 2000-07-21 15:12 ` H . J . Lu 2000-07-21 15:12 ` Geoff Keating @ 2000-07-21 15:33 ` Angela Marie Thomas 2 siblings, 0 replies; 32+ messages in thread From: Angela Marie Thomas @ 2000-07-21 15:33 UTC (permalink / raw) To: Jim Wilson; +Cc: Geoff Keating, jason, hjl, aoliva, gcc-patches, binutils > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 14:19 ` Jason Merrill 2000-07-21 14:48 ` Geoff Keating @ 2000-07-21 15:28 ` Jim Wilson 2000-07-21 17:15 ` Jason Merrill 1 sibling, 1 reply; 32+ messages in thread From: Jim Wilson @ 2000-07-21 15:28 UTC (permalink / raw) To: Jason Merrill; +Cc: Geoff Keating, hjl, aoliva, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 15:28 ` Jim Wilson @ 2000-07-21 17:15 ` Jason Merrill 2000-07-21 17:41 ` Jim Wilson 0 siblings, 1 reply; 32+ messages in thread From: Jason Merrill @ 2000-07-21 17:15 UTC (permalink / raw) To: Jim Wilson; +Cc: Geoff Keating, hjl, aoliva, gcc-patches, binutils >>>>> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 17:15 ` Jason Merrill @ 2000-07-21 17:41 ` Jim Wilson 2000-07-21 18:01 ` Jason Merrill 0 siblings, 1 reply; 32+ messages in thread From: Jim Wilson @ 2000-07-21 17:41 UTC (permalink / raw) To: Jason Merrill; +Cc: Geoff Keating, hjl, aoliva, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 17:41 ` Jim Wilson @ 2000-07-21 18:01 ` Jason Merrill 2000-07-21 19:15 ` Alexandre Oliva 0 siblings, 1 reply; 32+ messages in thread From: Jason Merrill @ 2000-07-21 18:01 UTC (permalink / raw) To: Jim Wilson; +Cc: Geoff Keating, hjl, aoliva, gcc-patches, binutils >>>>> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 18:01 ` Jason Merrill @ 2000-07-21 19:15 ` Alexandre Oliva 2000-07-21 19:20 ` Jason Merrill 0 siblings, 1 reply; 32+ messages in thread From: Alexandre Oliva @ 2000-07-21 19:15 UTC (permalink / raw) To: Jason Merrill; +Cc: Jim Wilson, Geoff Keating, hjl, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 19:15 ` Alexandre Oliva @ 2000-07-21 19:20 ` Jason Merrill 2000-07-21 20:08 ` Alexandre Oliva 0 siblings, 1 reply; 32+ messages in thread From: Jason Merrill @ 2000-07-21 19:20 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Jim Wilson, Geoff Keating, hjl, gcc-patches, binutils >>>>> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 19:20 ` Jason Merrill @ 2000-07-21 20:08 ` Alexandre Oliva 2000-07-21 20:26 ` H . J . Lu 2000-07-21 21:53 ` Jason Merrill 0 siblings, 2 replies; 32+ messages in thread From: Alexandre Oliva @ 2000-07-21 20:08 UTC (permalink / raw) To: Jason Merrill; +Cc: Jim Wilson, Geoff Keating, hjl, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 20:08 ` Alexandre Oliva @ 2000-07-21 20:26 ` H . J . Lu 2000-07-21 21:53 ` Jason Merrill 1 sibling, 0 replies; 32+ messages in thread From: H . J . Lu @ 2000-07-21 20:26 UTC (permalink / raw) To: Alexandre Oliva Cc: Jason Merrill, Jim Wilson, Geoff Keating, gcc-patches, binutils 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 20:08 ` Alexandre Oliva 2000-07-21 20:26 ` H . J . Lu @ 2000-07-21 21:53 ` Jason Merrill 2000-07-21 22:29 ` Alexandre Oliva 1 sibling, 1 reply; 32+ messages in thread From: Jason Merrill @ 2000-07-21 21:53 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Jim Wilson, Geoff Keating, hjl, gcc-patches, binutils >>>>> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 21:53 ` Jason Merrill @ 2000-07-21 22:29 ` Alexandre Oliva 2000-07-22 0:58 ` Jason Merrill 0 siblings, 1 reply; 32+ messages in thread From: Alexandre Oliva @ 2000-07-21 22:29 UTC (permalink / raw) To: Jason Merrill; +Cc: Jim Wilson, Geoff Keating, hjl, gcc-patches, binutils 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) 2000-07-21 22:29 ` Alexandre Oliva @ 2000-07-22 0:58 ` Jason Merrill 0 siblings, 0 replies; 32+ messages in thread From: Jason Merrill @ 2000-07-22 0:58 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Jim Wilson, Geoff Keating, hjl, gcc-patches, binutils >>>>> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2000-07-22 0:58 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20000520093135A.mitchell@codesourcery.com> [not found] ` <orhfbt9nwh.fsf@tamanduatei.dcc.unicamp.br> [not found] ` <20000520095133R.mitchell@codesourcery.com> 2000-05-20 22:10 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 2000-05-21 16:44 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Alexandre Oliva 2000-05-21 16:51 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 2000-05-22 15:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson 2000-05-22 17:54 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 2000-05-22 18:47 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html Jim Wilson 2000-05-22 20:06 ` http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html H . J . Lu 2000-07-21 1:17 ` $(build_tooldir)/lib (was Re: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01104.html) Jason Merrill 2000-07-21 7:49 ` H . J . Lu 2000-07-21 10:38 ` Geoff Keating 2000-07-21 10:54 ` H . J . Lu 2000-07-21 11:54 ` Jim Wilson 2000-07-21 12:12 ` H . J . Lu 2000-07-21 14:19 ` Jason Merrill 2000-07-21 14:48 ` Geoff Keating 2000-07-21 14:53 ` H . J . Lu 2000-07-21 15:05 ` Jim Wilson 2000-07-21 15:12 ` H . J . Lu 2000-07-21 15:12 ` Geoff Keating 2000-07-21 15:49 ` H . J . Lu 2000-07-21 15:33 ` Angela Marie Thomas 2000-07-21 15:28 ` Jim Wilson 2000-07-21 17:15 ` Jason Merrill 2000-07-21 17:41 ` Jim Wilson 2000-07-21 18:01 ` Jason Merrill 2000-07-21 19:15 ` Alexandre Oliva 2000-07-21 19:20 ` Jason Merrill 2000-07-21 20:08 ` Alexandre Oliva 2000-07-21 20:26 ` H . J . Lu 2000-07-21 21:53 ` Jason Merrill 2000-07-21 22:29 ` Alexandre Oliva 2000-07-22 0:58 ` Jason Merrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).