On 06/23/2016 02:23 AM, Martin Liška wrote:
On 06/23/2016 06:57 AM, Jeff Law wrote:
Is this still something you want to pursue? It looks pretty reasonable and one
could make an argument that it's a good idea in and of itself.
jeff
Yeah, I would like to install the patch :) Can I take your
On 06/23/2016 06:57 AM, Jeff Law wrote:
> Is this still something you want to pursue? It looks pretty reasonable and
> one could make an argument that it's a good idea in and of itself.
>
> jeff
Yeah, I would like to install the patch :) Can I take your reply as signal that
it's accepted?
?
Thanks,
Martin
0001-Prevent-LTO-wrappers-to-process-a-recursive-executio.patch
From dfe0486ad7babe3d6de349001d4790684dc94bfb Mon Sep 17 00:00:00 2001
From: marxin <mli...@suse.cz>
Date: Fri, 22 Apr 2016 17:57:23 +0200
Subject: [PATCH] Prevent LTO wrappers to process a recursive executio
On 04/25/2016 09:30 PM, Andi Kleen wrote:
> Does that really work? When the executable is found in $PATH
> av[0] does not contain the full path name. But you seem to assume
> it does?
>
> -Andi
Hi.
Well, it should be resolved by lrealpath. There's usage from my machine:
marxin@marxinbox:~>
Martin Liška writes:
> #endif
> + /* Do not search original location in the same folder. */
> + char *exe_folder = lrealpath (av[0]);
> + exe_folder[strlen (exe_folder) - strlen (lbasename (exe_folder))] =
> '\0';
> + char *location = concat (exe_folder,
rom dfe0486ad7babe3d6de349001d4790684dc94bfb Mon Sep 17 00:00:00 2001
From: marxin <mli...@suse.cz>
Date: Fri, 22 Apr 2016 17:57:23 +0200
Subject: [PATCH] Prevent LTO wrappers to process a recursive execution
gcc/ChangeLog:
2016-04-22 Martin Liska <mli...@suse.cz>
* file-find.c (remove_prefix): New function.