This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] fix PR 26165
- From: Nathan Froyd <froydnj at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 12 Aug 2008 08:15:54 -0700
- Subject: [PATCH] fix PR 26165
The patch below fixes PR 26165. The bug was that when GCC was
configured with --disable-multilib on x86_64-unknown-linux-gnu, the
proper place for startfiles and such is lib64/. libgomp, in particular,
places libgomp.spec here, which is read during the linking process.
However, the 'include' directive didn't search through multilib
directories and since lib64 is the multilib_os_dir, lib64/ wasn't getting
searched. I think the reason this worked in the --enable-multilib case
was that there was always a copy in lib/ and the include directive would
pick that up always.
I don't pretend to understand specs, but everywhere else in gcc.c that
find_a_file (&startfile_prefixes, ...) is called, do_multi is set to
true. This patch simply copies that behavior for processing 'include'
directives in specs.
Tested on x86_64-unknown-linux-gnu. OK to commit for trunk and 4.3
(since the PR was reported against 4.2)?
-Nathan
2008-08-12 Nathan Froyd <froydnj@codesourcery.com>
PR libgomp/26165
* gcc.c (include_spec_function): Tweak call to find_a_file.
Index: gcc.c
===================================================================
--- gcc.c (revision 138957)
+++ gcc.c (working copy)
@@ -8044,7 +8044,7 @@ include_spec_function (int argc, const c
if (argc != 1)
abort ();
- file = find_a_file (&startfile_prefixes, argv[0], R_OK, 0);
+ file = find_a_file (&startfile_prefixes, argv[0], R_OK, true);
read_specs (file ? file : argv[0], FALSE);
return NULL;