[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2024-08-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #14 from Andrew Pinski  ---
Fixed for GCC 15.

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2024-08-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #13 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:3fb90724cec7e76b60fb910fa98b4ebec9912a31

commit r15-3321-g3fb90724cec7e76b60fb910fa98b4ebec9912a31
Author: Andrew Pinski 
Date:   Tue Apr 16 12:06:51 2024 -0700

Don't remove /usr/lib and /lib from when passing to the linker
[PR97304/104707]

With newer ld, the default search library path does not include /usr/lib
nor /lib
but the driver decides to not pass -L down to the link for these and then
in some/most
cases libc is not found.
This code dates from at least 1992 and it is done in a way which is not
safe and
does not make sense. So let's remove it.

Bootstrapped and tested on x86_64-linux-gnu (which defaults to being a
multilib).

gcc/ChangeLog:

PR driver/104707
PR driver/97304

* gcc.cc (is_directory): Don't not include /usr/lib and /lib
for library directory pathes. Remove library argument.
(add_to_obstack): Update call to is_directory.
(driver_handle_option): Likewise.
(spec_path): Likewise.

Signed-off-by: Andrew Pinski 

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2024-08-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> Testing removal of this part from the driver.

Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2024-04-16 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-04-16

--- Comment #11 from Andrew Pinski  ---
Testing removal of this part from the driver.

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2024-04-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #10 from Andrew Pinski  ---
Note multilib is not the issue. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304#c14 for more analysis of the
issue (I think there might be another bug report talking about this too).

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2023-04-03 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #9 from Andrew Pinski  ---
(In reply to rvalue from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > > since all modern operating systems have a large enough parameter space 
> > > (all of them have 262k at least).
> > 
> > Windows still does not 
> 
> I don't think this code will make anything better or worse in Windows since
> it simply compares the path with "/lib/" and "/usr/lib/", which never exist
> in Windows.

Cross compilers ...

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

2023-04-02 Thread i at rvalue dot moe via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

rvalue  changed:

   What|Removed |Added

 CC||i at rvalue dot moe

--- Comment #8 from rvalue  ---
(In reply to Andrew Pinski from comment #7)
> > since all modern operating systems have a large enough parameter space (all 
> > of them have 262k at least).
> 
> Windows still does not 

I don't think this code will make anything better or worse in Windows since it
simply compares the path with "/lib/" and "/usr/lib/", which never exist in
Windows.