This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
From: Roland McGrath <roland@redhat.com> Date: Fri, 24 Feb 2006 17:41:43 -0800 (PST) > > From: Roland McGrath <roland@redhat.com> > > Date: Fri, 24 Feb 2006 16:47:08 -0800 (PST) > > > > > I don't think ought to be necessary. If it is, I'd like to fix the > > > configure magic so it's not. Those Implies files from the main source > > > should cause those add-on directories to be searched too. > > > > This doesn't happen in the top-level either, that's why we need > > sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9b/Implies and friends > > eventhough we have sysdeps/sparc/sparc32/sparcv9b/Implies. > > I'm not following you. The main tree tree has > sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9b/Implies already. > Another one should not be required in the add-on too. > The one would not be required either if we used sparcv9/sparcv9b instead. I guess I don't understand how the "machine=" specification in the configure scripts work... They look like file path names that the build machinery tries one by one like this: machine=a/b/c/d step 1) try $(foo)/a/b/c/d step 2) try $(foo)/a/b/c step 3) try $(foo)/a/b step 4) try $(foo)/a You seem to be suggesting that it works another way.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |