On Feb 23, 2024, Jason Merrill wrote:
> The problem, as you say, comes when you want to both bootstrap and
> build tools that aren't involved in the bootstrap process.
It's more visible there, because those don't actively refrain from
linking dynamically with libstdc++. But even bootstrapped
Iain Sandoe writes:
> Hi Gaius,
>
>> On 22 Feb 2024, at 18:06, Gaius Mulley wrote:
>>
>> Iain Sandoe writes:
>>
>>> Right now, AFAIK the only target runtimes used by host tools are
>>> libstdc++, libgcc and libgnat. I agree that might change with rust -
>>> since the rust folks are talking
On 2/23/24 06:23, Alexandre Oliva wrote:
I'm not so worried about bootstrap itself as I am about post-bootstrap
host tools. Those are unusual in that, after native bootstraps, they're
built using the just-built (last-stage) compiler and target libraries,
rather than the host compiler and
On Feb 21, 2024, Jason Merrill wrote:
> So indeed I guess we still
> want both prev and current libgcc directories in RPATH to handle the
> case where we've removed the previous stage, as below.
*nod*, thanks
> I can't think of why we would need to depend on the current stage
> target
> On 21 Feb 2024, at 23:36, Iain Sandoe wrote:
>
>> On 21 Feb 2024, at 23:06, Jason Merrill wrote:
>>
>> On 2/20/24 00:45, Alexandre Oliva wrote:
>>> On Feb 16, 2024, Jason Merrill wrote:
So, for stage2+, let's add just prev- libgcc.
>>> I'm pretty sure this will break bootstrap-lean
Hi Gaius,
> On 22 Feb 2024, at 18:06, Gaius Mulley wrote:
>
> Iain Sandoe writes:
>
>> Right now, AFAIK the only target runtimes used by host tools are
>> libstdc++, libgcc and libgnat. I agree that might change with rust -
>> since the rust folks are talking about using one of the runtimes
Iain Sandoe writes:
> Right now, AFAIK the only target runtimes used by host tools are
> libstdc++, libgcc and libgnat. I agree that might change with rust -
> since the rust folks are talking about using one of the runtimes in
> the FE, I am not aware of other language FEs requiring their
> On 21 Feb 2024, at 23:06, Jason Merrill wrote:
>
> On 2/20/24 00:45, Alexandre Oliva wrote:
>> On Feb 16, 2024, Jason Merrill wrote:
>>> So, for stage2+, let's add just prev- libgcc.
>> I'm pretty sure this will break bootstrap-lean where libgcc_s isn't a
>> system library, and we're
On 2/20/24 00:45, Alexandre Oliva wrote:
On Feb 16, 2024, Jason Merrill wrote:
So, for stage2+, let's add just prev- libgcc.
I'm pretty sure this will break bootstrap-lean where libgcc_s isn't a
system library, and we're building post-bootstrap host tools :-(
We need the current stage lib
On Feb 16, 2024, Jason Merrill wrote:
> So, for stage2+, let's add just prev- libgcc.
I'm pretty sure this will break bootstrap-lean where libgcc_s isn't a
system library, and we're building post-bootstrap host tools :-(
We need the current stage lib after the prev stage is removed.
I also
> On 16 Feb 2024, at 21:05, Jason Merrill wrote:
>
> On 2/14/24 18:33, Iain Sandoe wrote:
>>> On 14 Feb 2024, at 22:59, Iain Sandoe wrote:
On 12 Feb 2024, at 19:59, Jason Merrill wrote:
On 2/10/24 07:30, Iain Sandoe wrote:
>> On 10 Feb 2024, at 12:07, Jason Merrill
On 2/14/24 18:33, Iain Sandoe wrote:
On 14 Feb 2024, at 22:59, Iain Sandoe wrote:
On 12 Feb 2024, at 19:59, Jason Merrill wrote:
On 2/10/24 07:30, Iain Sandoe wrote:
On 10 Feb 2024, at 12:07, Jason Merrill wrote:
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain
> On 14 Feb 2024, at 22:59, Iain Sandoe wrote:
>> On 12 Feb 2024, at 19:59, Jason Merrill wrote:
>>
>> On 2/10/24 07:30, Iain Sandoe wrote:
On 10 Feb 2024, at 12:07, Jason Merrill wrote:
On 2/10/24 05:46, Iain Sandoe wrote:
>> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
> On 12 Feb 2024, at 19:59, Jason Merrill wrote:
>
> On 2/10/24 07:30, Iain Sandoe wrote:
>>> On 10 Feb 2024, at 12:07, Jason Merrill wrote:
>>>
>>> On 2/10/24 05:46, Iain Sandoe wrote:
> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
>
>
>
>> On 9 Feb 2024, at 10:56,
On 2/10/24 07:30, Iain Sandoe wrote:
On 10 Feb 2024, at 12:07, Jason Merrill wrote:
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
On 8 Feb 2024, at 21:44, Jason Merrill wrote:
On 2/8/24 12:55, Paolo
> On 10 Feb 2024, at 12:07, Jason Merrill wrote:
>
> On 2/10/24 05:46, Iain Sandoe wrote:
>>> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
>>>
>>>
>>>
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>
> On 2/8/24 12:55, Paolo
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
On 8 Feb 2024, at 21:44, Jason Merrill wrote:
On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build
> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
>
>
>
>> On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
>>> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>>>
>>> On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
>>>
>>
>> Hmm. In stage 1, when we
> On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
>> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>>
>> On 2/8/24 12:55, Paolo Bonzini wrote:
>>> On 2/8/24 18:16, Jason Merrill wrote:
>>
>
> Hmm. In stage 1, when we build with the system gcc, I'd think we want
> the
> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>
> On 2/8/24 12:55, Paolo Bonzini wrote:
>> On 2/8/24 18:16, Jason Merrill wrote:
>
Hmm. In stage 1, when we build with the system gcc, I'd think we want the
just-built gnat1 to find the system libgcc.
In stage
On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build with the system gcc, I'd think we
want the just-built gnat1 to find the system libgcc.
In stage 2, when we build with the stage 1 gcc, we want the
just-built gnat1 to find the
> On 8 Feb 2024, at 19:25, Jason Merrill wrote:
>
> On 2/8/24 12:51, Iain Sandoe wrote:
>>> On 8 Feb 2024, at 17:16, Jason Merrill wrote:
>>>
>>> On 2/8/24 12:12, Jason Merrill wrote:
On 2/8/24 10:04, Iain Sandoe wrote:
> Hi Jason,
>
> I have tested this on modern Darwin
On 2/8/24 12:51, Iain Sandoe wrote:
On 8 Feb 2024, at 17:16, Jason Merrill wrote:
On 2/8/24 12:12, Jason Merrill wrote:
On 2/8/24 10:04, Iain Sandoe wrote:
Hi Jason,
I have tested this on modern Darwin (with libc++ as the system library) and on
older Darwin, where we do see the issue -
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build with the system gcc, I'd think we want
the just-built gnat1 to find the system libgcc.
In stage 2, when we build with the stage 1 gcc, we want the just-built
gnat1 to find the stage 1 libgcc.
In neither case do we
> On 8 Feb 2024, at 17:16, Jason Merrill wrote:
>
> On 2/8/24 12:12, Jason Merrill wrote:
>> On 2/8/24 10:04, Iain Sandoe wrote:
>>> Hi Jason,
>>>
>>> I have tested this on modern Darwin (with libc++ as the system library) and
>>> on
>>> older Darwin, where we do see the issue - because the
On 2/8/24 12:12, Jason Merrill wrote:
On 2/8/24 10:04, Iain Sandoe wrote:
Hi Jason,
I have tested this on modern Darwin (with libc++ as the system
library) and on
older Darwin, where we do see the issue - because the system linker is
written
in C++ and links with libstdc++ (so sometimes we
On 2/8/24 10:04, Iain Sandoe wrote:
Hi Jason,
I have tested this on modern Darwin (with libc++ as the system library) and on
older Darwin, where we do see the issue - because the system linker is written
in C++ and links with libstdc++ (so sometimes we get a crash, or worse
unpredictable
Hi Jason,
I have tested this on modern Darwin (with libc++ as the system library) and on
older Darwin, where we do see the issue - because the system linker is written
in C++ and links with libstdc++ (so sometimes we get a crash, or worse
unpredictable
beahviour).
-
For modern Darwin [ >
On Feb 6, 2024, Jason Merrill wrote:
> Reverting that hunk of the change fixed my problem with bubblestrapping GCC
> 12 with ccache on a host with a newer system libstdc++.
Did you have libcc1, gnattools and gotools enabled in your testing?
Those non-bootstrapped tools are most likely to be
On Tue, Feb 6, 2024 at 6:08 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. Any thoughts?
It still makes sense to me, for what that's worth.
Ian
> -- 8< --
>
> The patch for PR22340 (r104978) moved the adding of TARGET_LIB_PATH to
> RPATH_ENVVAR from POSTSTAGE1_HOST_EXPORTS to
Tested x86_64-pc-linux-gnu. Any thoughts?
-- 8< --
The patch for PR22340 (r104978) moved the adding of TARGET_LIB_PATH to
RPATH_ENVVAR from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS, but didn't
mention that in the ChangeLog; it also wasn't part of the patch that was
sent to gcc-patches. I
31 matches
Mail list logo
