This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
bootstrap/3216: buildir == srcdir setup fails at make install time
- To: gcc-gnats at gcc dot gnu dot org
- Subject: bootstrap/3216: buildir == srcdir setup fails at make install time
- From: jason-gccbug at molenda dot com
- Date: 18 Jun 2001 07:19:21 -0000
- Reply-To: jason-gccbug at molenda dot com
>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