From mboxrd@z Thu Jan  1 00:00:00 1970
From: jason-gccbug@molenda.com
To: gcc-gnats@gcc.gnu.org
Subject: bootstrap/3216: buildir == srcdir setup fails at make install time
Date: Mon, 18 Jun 2001 00:26:00 -0000
Message-id: <20010618071921.726.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-06/msg00723.html
List-Id: <gcc-prs.sourceware.org>

>Number:         3216
>Category:       bootstrap
>Synopsis:       buildir == srcdir setup fails at make install time
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 18 00:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Jason Molenda
>Release:        gcc-3.0
>Organization:
>Environment:
i686-pc-linux-gnu, RH 7.1, host==build==target.
>Description:
This is may be similar to bootstrap/3075.  If you run

   ./configure
   make bootstrap
   make install

The 'make install' will fail in the runtime libraries directory
($srcdir/i686-pc-linux-gnu/DIRNAME in my case) when one of
the Makefiles tries to run mkinstalldirs as $src_topdir/../mkinstalldirs
and mkinstalldirs is actually at $src_topdir/../../mkinstalldirs in
this case.

The problem is that a directory like 'libjava' exists as both
$srcdir/libjava and $srcdir/i686-pc-linux-gnu/libjava when someone
configures as I have.  The latter of these two is a set of symlinks
to the real sources.  The Makefile in libjava assumes that 
mkinstalldirs can be found at $src_topdir/../mkinstalldirs -- a
valid assumption for the first location, but not the second.
When someone configures with srcdir != builddir, $src_topdir is
probably a full pathname, and so mkinstalldirs is found in
both cases.  But when srcdir==builddir, $src_topdir is ".",
and when make descends into i686-pc-linux-gnu/libjava, 
mkinstalldirs gets set to "./../mkinstalldirs", which is
incorrect.

My brain is too sleep deprived just now to provide a 
patch, I wanted to get the problem in the DB in a (hopefully
clear) report in case someone more familiar with this bit of
the build system wants to look into it.

This problem pops up in the following directories:

libjava/libltdl
libjava/gcj
libjava/include
libjava
zlib
boehm-gc

I'll attach the make output from one of the failed make
installs.
>How-To-Repeat:
Unpack gcc-3.0.  
./configure; make bootstrap; make install.
>Fix:
At first blush, I think this problem is in the same vein
as 3075, although that's a slightly different problem.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="pr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pr"

TWFraW5nIGluc3RhbGwgaW4gbGlibHRkbApnbWFrZVsyXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAv
aG9tZS9qYXNvbi90bXAvZ2NjLTMuMC9pNjg2LXBjLWxpbnV4LWdudS9saWJqYXZhL2xpYmx0ZGwn
CmdtYWtlWzNdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9ob21lL2phc29uL3RtcC9nY2MtMy4wL2k2
ODYtcGMtbGludXgtZ251L2xpYmphdmEvbGlibHRkbCcKL2Jpbi9zaCAuLy4uLy4uL21raW5zdGFs
bGRpcnMgL2hvbWUvamFzb24vdG1wL2ctaS9saWIKLi8uLi8uLi9ta2luc3RhbGxkaXJzOiAuLy4u
Ly4uL21raW5zdGFsbGRpcnM6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKZ21ha2VbM106ICoq
KiBbaW5zdGFsbC1saWJMVExJQlJBUklFU10gRXJyb3IgMTI3CmdtYWtlWzNdOiBMZWF2aW5nIGRp
cmVjdG9yeSBgL2hvbWUvamFzb24vdG1wL2djYy0zLjAvaTY4Ni1wYy1saW51eC1nbnUvbGliamF2
YS9saWJsdGRsJwpnbWFrZVsyXTogKioqIFtpbnN0YWxsLWFtXSBFcnJvciAyCmdtYWtlWzJdOiBM
ZWF2aW5nIGRpcmVjdG9yeSBgL2hvbWUvamFzb24vdG1wL2djYy0zLjAvaTY4Ni1wYy1saW51eC1n
bnUvbGliamF2YS9saWJsdGRsJwpnbWFrZVsxXTogKioqIFtpbnN0YWxsLXJlY3Vyc2l2ZV0gRXJy
b3IgMQpnbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL2phc29uL3RtcC9nY2MtMy4w
L2k2ODYtcGMtbGludXgtZ251L2xpYmphdmEnCmdtYWtlOiAqKiogW2luc3RhbGwtdGFyZ2V0LWxp
YmphdmFdIEVycm9yIDIK