This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: pre-egcs 1.1 status for *-rtems


  In message <Pine.BSF.3.96.980714112126.10553H-100000@vespucci.advicom.net>you write:
  > Did it and learned that you are right.  gcc/configure is not finding the
  > gas/configure.in because of the way it is following the symlinks.   I have
  > a tree symlinked like the one-tree script does.  Here is enough of the
  > link stuff to show what is happening.
  > 
  >       rm -rf src
  >       mkdir src
  >       cd src
  >       for f in gcc libio libstdc++ texinfo xiberty
  >       do
  >           ln -s ../${GCC}/${f} . 
  >       done
  >       for f in bfd binutils gas gprof ld opcodes etc
  >       do
  >            ln -s ../${BINUTILS}/$f .
  >       done
  >       ln -s ../${NEWLIB}/newlib .
Ouch.  This is not going to work if you use relative pathnames when
configuring.  I believe it will work if you use absolute pathnames.

Consider carefully what happens with "src/gcc/../gas".

You go into src, then into gcc, then up -- at this point you're in
the parent of the *real* gcc directory.  You are not in the directory
with the symlinks.  This is expected symlink behavior (and is one of
my beef's with symlinks).


  > $ pwd
  > /usr1/rtems/work/tools/b/gcc
  > $ cd ../../src/gcc/../gas
  > $ pwd
  > /usr1/rtems/work/tools/src/gas
  > $ cd -
  > $ pwd
  > /usr1/rtems/work/tools/b/gcc
  > $ ls -l ../../src/gcc/../gas
  > ls: ../../src/gcc/../gas: No such file or directory
  > 
  > I am not a symlink expert but it looks like it is not being followed as
  > expected.
Presumably something is optimizing away "gcc/.." in the "cd" case
above since if you actually take each step one by one it will not
work.  

ie
cd ..
cd ..
cd src
cd gcc
cd ..
cd gas

Ought to fail.  What shell are you using?  It sounds like it's being
"overly helpful" and is confusing the issue in this case.

I believe if you use an absolute pathname for configure that this
will work.

The other possibility would be to change how configure.in finds the
assembler directory.

When you enter the code in configure.in, srcdir looks like

../../src/gcc

What would be the natural way to get to its parent?  "..", then we
descent down to the assembler via "gas".  That's how we end up with
../../src/gcc/../gas

We could instead use some kind of sed hack to strip off the last
component of the pathname, then append "/gas".  Presumably something
like :/gcc$:/gas: ought to work reliably.



jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]