[Bug c/53529] New: assembler errors while building a cross compiler if . (dot) is in your PATH

[Bug c/53529] New: assembler errors while building a cross compiler if . (dot) is in your PATH

[bernard.van.duijnen at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529

             Bug #: 53529
           Summary: assembler errors while building a cross compiler if .
                    (dot) is in your PATH
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bernard.van.duijnen@oracle.com


If you have . (current directory) in your PATH in front of the location of
the system assembler (typically /usr/bin/as) then while building the
cross compiler the wrong assembler is called, resulting in errors about an
unrecognized option or bad opcodes. The mixup is with the generated
shell script as in the gcc sub directory of the build tree. This shell
script points to the target-as and at this stage the host-as is needed.

Took me quit a while to diagnose the root cause as this is not so easy to find.

[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-30 15:35:18 UTC ---
Don't do it then?  Having . in $PATH is a severe security issue anyway.

[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH

[bernard.van.duijnen at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529

--- Comment #2 from Bernard van Duijnen <bernard.van.duijnen at oracle dot com> 2012-05-30 15:49:43 UTC ---
(In reply to comment #1)
> Don't do it then?  Having . in $PATH is a severe security issue anyway.

Typically it is unsecure yes, but not always. For instance on my ubuntu
laptop where I am the one and only user I do not think that is an issue.

Its easy to fix your PATH to solve it, but only once you know that is
the issue, just a check to catch the situation and give a warning is a
sufficient solution.

[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH

[karlson2k at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529

Evgeny Grin <karlson2k at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |karlson2k at gmail dot com

--- Comment #3 from Evgeny Grin <karlson2k at gmail dot com> 2013-02-09 20:30:33 UTC ---
Similar error is always on MinGW hosts. MinGW has '.' in front of PATH by
default.
So if try to build GCC with language that require C++ or to build GCC by C++,
you'll always get 

g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found

when building inside sources/gcc/gcc subdirectory.

When building GCC using C, there no such problem as temporal GCC renamed to
xgcc.exe . But when building GCC using C++, temporal g++.exe is placed in gcc
subdirectory and erroneously called instead of host g++ if PATH variable is
prefixed by '.:'

That's the reason because all MinGW GCC builds are failed when building using
C++.
Tried with GCC 4.7.2

[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-02-09 23:00:37 UTC ---
(In reply to comment #3)
> Similar error is always on MinGW hosts. MinGW has '.' in front of PATH by
> default.
> So if try to build GCC with language that require C++ or to build GCC by C++,
> you'll always get 

I fixed that issue in 4.8, see PR 54279.  The original issue of as/ld in the
PATH is recorded here.