Final end of the `never ending story'? (was: Re: Patch for configuring/building in ${srcdir} (was: Re: Does it work now with my patch? (was: Re: egcs-980221: build fails for shared libstdc++ on HP-UX 10.20)) )

[Manfred Hollstein]

On Wed, 4 March 1998, 23:31:30, law@hurl.cygnus.com wrote:

 > 
 >   In message < 199803031850.TAA02124@saturn.s-direktnet.de >you write:
 >   > $ ll libraries/pentium/libiberty:
 >   > total 23
 >   > drwxr-xr-x   4 manfred  users        3072 Mar  3 18:04 .
 >   > drwxr-xr-x   5 manfred  users        1024 Mar  3 18:18 ..
 >   > lrwxrwxrwx   1 manfred  users          30 Mar  3 18:03 COPYING.LIB -> ../..
 >   > /../libiberty/COPYING.LIB
 >   > lrwxrwxrwx   1 manfred  users          28 Mar  3 18:03 ChangeLog -> ../../.
 >   > ./libiberty/ChangeLog
 >   > -rw-r--r--   1 manfred  users       11785 Mar  3 18:03 Makefile
 >   > lrwxrwxrwx   1 manfred  users          30 Mar  3 18:03 Makefile.in -> ../..
 >   > /../libiberty/Makefile.in
 >   > lrwxrwxrwx   1 manfred  users          25 Mar  3 18:03 README -> ../../../l
 >   > ibiberty/README
 >   > lrwxrwxrwx   1 manfred  users          33 Mar  3 18:03 alloca-botch.h -> ..
 >   > /../../libiberty/alloca-botch.h
 >   > lrwxrwxrwx   1 manfred  users          15 Mar  3 18:03 alloca-conf.h -> ./a
 >   > lloca-norm.h
 >   > lrwxrwxrwx   1 manfred  users          32 Mar  3 18:03 alloca-norm.h -> ../
 >   > ../../libiberty/alloca-norm.h
 >   > lrwxrwxrwx   1 manfred  users          27 Mar  3 18:03 alloca.c -> ../../..
 >   > /libiberty/alloca.c
 >   > lrwxrwxrwx   1 manfred  users          25 Mar  3 18:03 argv.c -> ../../../l
 >   > ibiberty/argv.c
 >   > lrwxrwxrwx   1 manfred  users          25 Mar  3 18:03 argv.o -> ../../../l
 >   > ibiberty/argv.o
 >   > 
 >   > Look at argv.o, it's a symbolic link !-(
 > OK.  So what created the symbolic link?  It seems to me that your patch
 > just papers over the problem -- we should find out where/why that
 > link is created and decide if it's better to fix the problem by
 > avoiding the bogus links in the first place. 
 > 
 > 
 > jeff

It's caused  by  using libiberty twice.  First it's  used to build the
native  lib (in  the libiberty dir  itself);  later on, this libiberty
directory - configured  and  built! - will  then  be linked into   the
libraries/libiberty one; then,  make  distclean will be  called, which
removes the .o links.  I had expected, this would be done in the other
multilib dirs, too, but, somehow make distclean doesn't get called for
them.

>From looking at toplevel Makefile.in:

		if $(SHELL) $$s/symlink-tree $${topdir}/$${dir} "no-such-file" ; then \
		  if [ -f Makefile ]; then \
		    if $(MAKE) distclean; then \
		      true; \

it looks too me like no Makefile  is found in that subdirectory, hence
make believes   `this must be either   a virgin or  a properly cleaned
directory', calls configure  at leaves the .o links  lying around.  My
patch now simply  corrects this by calling  make clean after configure
ran.

Perhaps, you're  right it's only papering over  the real  problem (why
isn't there a Makefile?), but it's not  wrong anyway. I'll dig further
into it (when I'll find some spare time ;-).

manfred