On Tue, 26 Feb 2019, Tom de Vries wrote:
>>> Specifically I am now seeing
>>>
>>> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
>>> needed by 'b3test_dwz_buildid.log'.
> The only way of reproducing it was to deinstall dwz.
:
> Fixed in patch below, committed as trivial.
Great, th
On 25-02-19 21:03, Tom de Vries wrote:
> On 25-02-19 15:12, Gerald Pfeifer wrote:
>> Specifically I am now seeing
>>
>> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
>> needed by 'b3test_dwz_buildid.log'.
>>
>> in my build/test logs. (Note, this is GNU make 4.2.1, so might reprod
On 25-02-19 15:12, Gerald Pfeifer wrote:
> Specifically I am now seeing
>
> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
> needed by 'b3test_dwz_buildid.log'.
>
> in my build/test logs. (Note, this is GNU make 4.2.1, so might reproduce
> on your SUSE systems as well?)
Hi Ger
Hi Tom,
I'm afraid this triggers on my (FreeBSD-based) testers:
2019-01-29 Tom de Vries
* install-debuginfo-for-buildid.sh.in: New script.
* Makefile.am (check_PROGRAMS): Add b2test and b3test.
(TESTS): Add b2test_buildid and b3test_dwz_buildid.
* Makefile.in
On Tue, Jan 29, 2019 at 3:17 PM Segher Boessenkool
wrote:
>
> On Sun, Jan 27, 2019 at 01:53:18PM -0800, Ian Lance Taylor wrote:
> > You need to use a temporary file, such as $@.tmp, for the final sed
> > command, followed by a mv to $@. Otherwise a failure in the sed will
> > leave what appears t
On Sun, Jan 27, 2019 at 01:53:18PM -0800, Ian Lance Taylor wrote:
> You need to use a temporary file, such as $@.tmp, for the final sed
> command, followed by a mv to $@. Otherwise a failure in the sed will
> leave what appears to be an up to date file.
Or you just set .DELETE_ON_ERROR, we requir
On Tue, Jan 29, 2019 at 12:24 AM Tom de Vries wrote:
>
> On 27-01-19 22:53, Ian Lance Taylor wrote:
> > On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries wrote:
> >>
> >> On 25-01-19 18:15, Nathan Sidwell wrote:
> >>> On 1/25/19 5:28 AM, Tom de Vries wrote:
>
> This patch fixes it by passing
On 27-01-19 22:53, Ian Lance Taylor wrote:
> On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries wrote:
>>
>> On 25-01-19 18:15, Nathan Sidwell wrote:
>>> On 1/25/19 5:28 AM, Tom de Vries wrote:
This patch fixes it by passing "" instead of NULL, in the call to
elf_add at line 3083 (for .gn
On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries wrote:
>
> On 25-01-19 18:15, Nathan Sidwell wrote:
> > On 1/25/19 5:28 AM, Tom de Vries wrote:
> >>
> >> This patch fixes it by passing "" instead of NULL, in the call to
> >> elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> >
On 25-01-19 18:15, Nathan Sidwell wrote:
> On 1/25/19 5:28 AM, Tom de Vries wrote:
>>
>> This patch fixes it by passing "" instead of NULL, in the call to
>> elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
>> line 3044 (for .gnu_debuglink) mentioned above.
>>
>> Nathan, doe
On Fri, Jan 25, 2019 at 12:15:28PM -0500, Nathan Sidwell wrote:
> On 1/25/19 5:28 AM, Tom de Vries wrote:
> >
> > This patch fixes it by passing "" instead of NULL, in the call to
> > elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> > line 3044 (for .gnu_debuglink) mentio
On 1/25/19 5:28 AM, Tom de Vries wrote:
This patch fixes it by passing "" instead of NULL, in the call to
elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
line 3044 (for .gnu_debuglink) mentioned above.
Nathan, does this fix the problem for you? If not, can you provide a
On Fri, Jan 25, 2019 at 5:27 AM Tom de Vries wrote:
>
> On 25-01-19 14:17, Tom de Vries wrote:
> > On 25-01-19 01:51, Ian Lance Taylor wrote:
> >> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
> >>>
> >>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> >>> possibl
On Fri, Jan 25, 2019 at 5:17 AM Tom de Vries wrote:
>
> On 25-01-19 01:51, Ian Lance Taylor wrote:
> > On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
> >>
> >> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> >> possibly NULL filename, with predictable results when
On 25-01-19 14:17, Tom de Vries wrote:
> On 25-01-19 01:51, Ian Lance Taylor wrote:
>> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>>>
>>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
>>> possibly NULL filename, with predictable results when it is.
>>>
>>> elf.c
On 25-01-19 01:51, Ian Lance Taylor wrote:
> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>>
>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
>> possibly NULL filename, with predictable results when it is.
>>
>> elf.c:3044 passes NULL as the filename parm:
>>
On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>
> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> possibly NULL filename, with predictable results when it is.
>
> elf.c:3044 passes NULL as the filename parm:
> ret = elf_add (state, NULL, d, base_address,
17 matches
Mail list logo