Bug 54279 - [4.8 Regression] first stage build with g++ fails with "." as the first component of $PATH
Summary: [4.8 Regression] first stage build with g++ fails with "." as the first compo...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.8.0
: P1 normal
Target Milestone: 4.8.0
Assignee: Andrew Pinski
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords: build, patch
Depends on:
Blocks:
 
Reported: 2012-08-16 05:40 UTC by Gary Funck
Modified: 2022-01-08 04:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-08-16 00:00:00


Attachments
Patch which I am testing right now (1.69 KB, patch)
2012-11-15 02:51 UTC, Andrew Pinski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gary Funck 2012-08-16 05:40:36 UTC
Posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01032.html

This build failure is a likely result of the recent change to compile GCC with the C++ compiler during the first stage.

1. I have "." on $PATH.

2. In one build of the latest GCC trunk, I specify
   CC=/usr/bin/gcc and CXX=/usr/bin/g++ and everything
   works.

3. In another build, I don't specify CC or CXX.
   Therefore they default to 'gcc' and 'g++'.
   This fails:
   g++: error trying to exec 'cc1plus': execvp: No such file or directory

If I remove "." from $PATH then the configuration in 3 will build.

The problem is that there is a g++ executable under the
built gcc directory, but cc1plus and other g++ component
parts haven't been built yet.
Comment 1 Andrew Pinski 2012-08-16 05:46:52 UTC
This might be the reason why we create xgcc than gcc and then only do the namechange at install time.  We need to do the same thing for g++ now.
Comment 2 Andrew Pinski 2012-11-15 00:31:45 UTC
I am going to take a stab at fixing this.
Comment 3 Andrew Pinski 2012-11-15 02:51:15 UTC
Created attachment 28693 [details]
Patch which I am testing right now

Once my testing finishes (including installing), I will submit this.
Comment 4 Andrew Pinski 2012-11-15 03:40:18 UTC
(In reply to comment #3)
> Created attachment 28693 [details]
> Patch which I am testing right now
> 
> Once my testing finishes (including installing), I will submit this.

It had an issue while doing libstdc++ testing.  So fixing up that testsuite.
Comment 5 Andrew Pinski 2012-11-15 04:31:44 UTC
libmudflap has the similar issue.
Comment 6 Andrew Pinski 2012-11-15 20:29:12 UTC
(In reply to comment #5)
> libmudflap has the similar issue.

Actually the libmudflap is fixed by fixing libstdc++.  Anyways I have a full fix now.  I am retesting it again.
Comment 7 Andrew Pinski 2012-11-28 22:11:35 UTC
Author: pinskia
Date: Wed Nov 28 22:11:29 2012
New Revision: 193910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193910
Log:
2012-11-28  Andrew Pinski  <apinski@cavium.com>

        PR bootstrap/54279
        * configure.ac (CXX_FOR_TARGET): Change over to use xg++.
        * configure: Regenerate.
        * Makefile.tpl (POSTSTAGE1_CXX_EXPORT): Change over to use xg++.
        * Makefile.in: Regenerate.

2012-11-28  Andrew Pinski  <apinski@cavium.com>

        PR bootstrap/54279
        * Makefile.in (${QMTEST_DIR}/context): Use xg++ instead of g++.

2012-11-28  Andrew Pinski  <apinski@cavium.com>

        PR bootstrap/54279
        * Make-lang.in (g++$(exeext)): Rename to
        (xg++$(exeext)): This.
        (g++-cross$(exeext)): Use xg++$(exeext) instead of g++$(exeext).
        (c++.start.encap): Likewise.
        (c++.install-common): Likewise.

2012-11-28  Andrew Pinski  <apinski@cavium.com>

        PR bootstrap/54279
        * lib/g++.exp (g++_init): Search for xg++ instead of g++ in the build
        directories.
        * lib/obj-c++.exp (obj-c++_init): Likewise.

2012-11-28  Andrew Pinski  <apinski@cavium.com>

        PR bootstrap/54279
        * scripts/testsuite_flags.in (--build-cxx): Use xg++ instead of g++.
        * testsuite/lib/libstdc++.exp (libstdc++_init): Likewise.




Modified:
    trunk/ChangeLog
    trunk/Makefile.in
    trunk/Makefile.tpl
    trunk/configure
    trunk/configure.ac
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/Make-lang.in
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/lib/g++.exp
    trunk/gcc/testsuite/lib/obj-c++.exp
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/scripts/testsuite_flags.in
    trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
Comment 8 Andrew Pinski 2012-11-28 22:15:48 UTC
Fixed.  Thanks for your report.
Comment 9 Karlson2k 2013-02-10 12:28:13 UTC
(In reply to comment #8)
> Fixed.  Thanks for your report.

Nice!
Shouldn't we do the same for other tools/languages? Like ada, java?
Comment 10 Andrew Pinski 2022-01-08 04:08:54 UTC
(In reply to Karlson2k from comment #9)
> (In reply to comment #8)
> > Fixed.  Thanks for your report.
> 
> Nice!
> Shouldn't we do the same for other tools/languages? Like ada, java?

Java has seen been removed and was never affected. The problem only shows up while building of the front-ends only. I have to double check but I think ada is fine as they use xgcc as the driver while building the front-end and I think D might be ok too (it was recently moved over to compiling D code).