On 12 May 2013 11:39, John Colvin <john.loughran.colvin@gmail.com> wrote:

> On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
>
>> On 12 May 2013 10:39, Jacob Carlborg <doob@me.com> wrote:
>>
>>  On 2013-05-12 05:50, Jonathan M Davis wrote:
>>>
>>>  That helps considerably, though if the compiler is old enough, that
>>> won't
>>>
>>>> work
>>>> for Linux due to glibc changes and whatnot.
>>>>
>>>>
>>> My experience is the other way around. Binaries built on newer version of Linux doesn't work on older. But binaries built on older versions usually works on newer versions.
>>>
>>> --
>>> /Jacob Carlborg
>>>
>>>
>> Depends... statically linked binaries will probably always work on the latest version, dynamic link and then you've got yourself a 'this libstdc++v5 doesn't exist anymore' problem.
>>
>
> So surely we can just offer a full history of statically linked binaries, problem solved?
>

The historical quirk of binary compatibility on Linux is OT to the problem I questioned, so no.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:kmnk08$3qr$1@digitalmars.com...
> On 5/11/2013 10:25 PM, Daniel Murphy wrote:
>> My thought was that you ensure (for the foreseeable future) that all D versions of the compiler compile with the most recent C++ version of the compiler.
>
> That would likely mean the the D compiler sources must be compilable with 2.063.
>

Yes.  And anybody with a C++ compiler can build the latest release.

On Saturday, 11 May 2013 at 15:09:24 UTC, Iain Buclaw wrote:
> Actually, the more I sit down and think about it, the more I question
> whether or not it is a good idea for the D D front end to have a dependency
> on phobos.   Maybe I should stop thinking in general.  :)
>
> Regards

Let me restate the issues to be clear on what I think is being said, and the my opinion.

== On GDC:

There is an flag to have the compiler built without dependencies of druntime/phobos. Someone interested in a Phobos free compiler would the be required to have Phobos to build their compiler.

- While this is the same person, I don't see that they will require the same restriction when building the compiler. My guess is the environment used to build the compiler has fewer restrictions, such as the having gcc/ubuntu available. Thus it is reasonable to expect them to have the needed libraries to build their compiler.

- Similarly, even if we restrict to just using druntime, the one interested in a druntime free compiler still runs into the issue.

== On Compiling older Compilers:

Checkout compiler source for an older compiler and gcc will build it. By switching to D, not only do we locate the source for the compiler we are building we must have the version of D used to build that compiler (or within the some window)

- I think it would be positive to say, each dmd version compiles with the previous release and itself (possibly with -d). This gives a feel for what changes are happening, and the more Phobos used the better.

- We can't eliminate the problem, if we only rely on druntime, everything still applies there. Instead we just need a consistent and/or well documented statement of which compiler versions compile which compiler versions.

In conclusion, it is a real problem. But it is nothing we can eliminate. We should look at reducing the impact not through reducing the dependency, but instead through improvement of our processes for introducing breaking changes. Such concentration will not be limited to benefiting DMD, but instead every project which must deal with older code in some fashion.

On Thursday, 9 May 2013 at 10:15:42 UTC, Iain Buclaw wrote:
> I'll will very likely keep a branch with the C++ implemented front end for
> these purposes. But ideally we should get porting as soon as possible ahead
> of this move so that there are already D compilers available for said
> targets.
>
> Though it would be nice for the D implementation to be kept to a subset
> that is backwards compatible with 2.062 (or whatever version we decide to
> make the switch at), that is something I cannot guarantee.
>
>
> Regards

Could compiling the D compiler in D to llvm bytecode on a working platform and then compiling the bytecode on target platform solve the issue (at least a part of it)?