November 02, 2017
On 11/2/2017 2:25 PM, Jonathan M Davis wrote:
> On Thursday, November 02, 2017 13:46:11 Walter Bright via Digitalmars-d
> wrote:
>> On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
>>> But we
>>> don't currently have a way to version code for a particular version of
>>> FreeBSD even if we wanted to.
>>
>> The FreeBSD version can be detected at runtime, and different code
>> executed.
> 
> Sure, but you can't actually compile different code based on the FreeBSD
> version, and if a type or function API changes, then that doesn't work.
> Wouldn't you get a linker error for the stuff that isn't actually defined on
> the C side of things? If so, then you can't really provide both the old and
> new versions of a function or type and switch between code that uses one or
> the other based on the version of the OS at runtime. You'd have to be able
> to have the source code differ depending on the FreeBSD version.

I know in Windows the imports can be dynamically loaded at runtime.
November 02, 2017
On Thursday, November 02, 2017 19:28:50 Walter Bright via Digitalmars-d wrote:
> On 11/2/2017 2:25 PM, Jonathan M Davis wrote:
> > On Thursday, November 02, 2017 13:46:11 Walter Bright via Digitalmars-d
> >
> > wrote:
> >> On 11/1/2017 10:11 PM, Jonathan M Davis wrote:
> >>> But we
> >>> don't currently have a way to version code for a particular version of
> >>> FreeBSD even if we wanted to.
> >>
> >> The FreeBSD version can be detected at runtime, and different code executed.
> >
> > Sure, but you can't actually compile different code based on the FreeBSD version, and if a type or function API changes, then that doesn't work. Wouldn't you get a linker error for the stuff that isn't actually defined on the C side of things? If so, then you can't really provide both the old and new versions of a function or type and switch between code that uses one or the other based on the version of the OS at runtime. You'd have to be able to have the source code differ depending on the FreeBSD version.
> I know in Windows the imports can be dynamically loaded at runtime.

I thought that that was just when explicitly loading a .dll or .so file via something like dlopen or LoadLibrary instead of linking against it, and you normally link against system libraries rather than dlopening them. But Windows is pretty weird about how it dynamically links stuff, so I could be misunderstanding something in Windows' case. Regardless, it wouldn't be the case with static linking, and there are cases where it's definitely preferable to statically link.

So, I fully expect that there are times when being able to version the source code based on the OS version (or the libc version if you're talking about Linux) would be needed. However, I don't know if it's needed often enough for the compiler to directly support it rather than using custom version specifiers for those code bases that do. Technically, I think that the versioning that they do in C/C++ for this sort of thing with #includes is more or less equivalent to using custom version specifiers rather than actually doing anything special with the compiler.

Regardless, it would be nice if we could avoid the need to statically version any code in dmd, druntime, or Phobos based on OS version.

- Jonathan M Davis

November 03, 2017
On 2017-11-03 03:43, Jonathan M Davis wrote:

> So, I fully expect that there are times when being able to version the
> source code based on the OS version (or the libc version if you're talking
> about Linux) would be needed. However, I don't know if it's needed often
> enough for the compiler to directly support it rather than using custom
> version specifiers for those code bases that do. Technically, I think that
> the versioning that they do in C/C++ for this sort of thing with #includes
> is more or less equivalent to using custom version specifiers rather than
> actually doing anything special with the compiler.
> 
> Regardless, it would be nice if we could avoid the need to statically
> version any code in dmd, druntime, or Phobos based on OS version.

I don't know all the details, just throwing some ideas out there:

* macOS went through a similar transition, perhaps have a look at how Apple did that. There some information here [1], scroll down to the documentation for the _DARWIN_FEATURE_64_BIT_INODE macro

* Fully statically link the binaries, including the C standard library. Might work assuming the kernel did not change

* Do something similar to what AppImage [2] is doing on Linux. AppImage works by creating a binary with an executable header and a disk image that holds the payload. In the case of AppImage the payload would be the application including all the files necessary to run it. Perhaps we could instead build something like universal binaries on macOS. Embed two separate executables and run one of the depending on the current system

[1] https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/stat.2.html

[2] https://appimage.org

-- 
/Jacob Carlborg
November 03, 2017
On 11/2/2017 7:43 PM, Jonathan M Davis wrote:
> I thought that that was just when explicitly loading a .dll or .so file via
> something like dlopen or LoadLibrary instead of linking against it,

That's right.

But given our resource limitations, I suggest the most pragmatic thing to do is support the latest FreeBSD, and leave older versions enabled in Druntime with `version` statements. That way the user could recompile Phobos for earlier versions if he needed it, but it wouldn't be officially supported.

Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
November 03, 2017
On Friday, 3 November 2017 at 09:40:01 UTC, Walter Bright wrote:
> Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(

Please keep it that way ;-)

btw. dmd runs just fine on FreeBSD 12 too, as I just tested it.

Mind you, I just compile my own stuff, and that's all.

I don't have extensive unit tests, so some things may well not work.

November 03, 2017
On Friday, November 03, 2017 09:50:37 codephantom via Digitalmars-d wrote:
> On Friday, 3 November 2017 at 09:40:01 UTC, Walter Bright wrote:
> > Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
>
> Please keep it that way ;-)

I think that there's a decent chance that some of Phobos won't work with XP though. A lot of API calls were added in Vista, some of which were major improvements. Plenty of stuff will probably continue to work on XP, but we don't support it, and as time goes by, the odds of stuff not working on it are going to increase. So, feel free to use XP if you want to, but you're using it at your own risk, and if something doesn't work, then you're just going to be out of luck.

> btw. dmd runs just fine on FreeBSD 12 too, as I just tested it.
>
> Mind you, I just compile my own stuff, and that's all.
>
> I don't have extensive unit tests, so some things may well not work.

It definitely crashed the last time I tested it, and the aforementioned bug report has someone testing it, and it crashing. So, either they've changed something that somehow magically made our stuff work as-is, or you just got lucky.

But regardless of whether it currently crashes, it's clear that we're going to need to make stat and friends work with 64-bit inodes rather than simply using the 32-bit inodes, even if they still happen to work for the moment, since at some point, the 32-bit inodes are going to be going away (though I'm sure not until at least FreeBSD 13).

- Jonathan M Davis

November 03, 2017
On Friday, 3 November 2017 at 10:26:42 UTC, Jonathan M Davis wrote:
> So, feel free to use XP if you want to, but you're using it at your own risk, and if something doesn't work, then you're just going to be out of luck.

that's ok, if it works great, if not, oh well.
at least it executes ;-)

e.g clang etc won't even execute on xp.


> It definitely crashed the last time I tested it, and the aforementioned bug report has someone testing it, and it crashing. So, either they've changed something that somehow magically made our stuff work as-is, or you just got lucky.

Yes, **do** your own testing, as my concept of testing is at best, dodgy...

i.e. I just grabbed all my .d files off FreeBSD 11, put them on FreeBSD 12, and executed this: for f in *.d; do echo $f;dmd $f; done

;-)

November 03, 2017
On Friday, 3 November 2017 at 10:26:42 UTC, Jonathan M Davis wrote:
> I think that there's a decent chance that some of Phobos won't work with XP though....

Same for FreeBSD ;-)

e.g: below compile fine on Windows, but on FreeBSD (11 and 12), I get a compile time error: Error: template instance to!string to is not a template declaration, it is a module. I've come across a few others too.... so Phobos developers need to test on FreeBSD too.

------------------
import std.stdio;
import std.conv;

void main()
{
    auto i = to!string(55);
    writeln("i is a ", typeof(i).stringof);
}
-----------------------
November 03, 2017

On 03.11.2017 10:40, Walter Bright wrote:
> On 11/2/2017 7:43 PM, Jonathan M Davis wrote:
>> I thought that that was just when explicitly loading a .dll or .so file via
>> something like dlopen or LoadLibrary instead of linking against it,
> 
> That's right.
> 
> But given our resource limitations, I suggest the most pragmatic thing to do is support the latest FreeBSD, and leave older versions enabled in Druntime with `version` statements. That way the user could recompile Phobos for earlier versions if he needed it, but it wouldn't be officially supported.
> 
> Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(

to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
November 03, 2017
On Friday, November 03, 2017 11:04:12 codephantom via Digitalmars-d wrote:
> On Friday, 3 November 2017 at 10:26:42 UTC, Jonathan M Davis
>
> wrote:
> > I think that there's a decent chance that some of Phobos won't work with XP though....
>
> Same for FreeBSD ;-)
>
> e.g: below compile fine on Windows, but on FreeBSD (11 and 12), I get a compile time error: Error: template instance to!string to is not a template declaration, it is a module. I've come across a few others too.... so Phobos developers need to test on FreeBSD too.
>
> ------------------
> import std.stdio;
> import std.conv;
>
> void main()
> {
>      auto i = to!string(55);
>      writeln("i is a ", typeof(i).stringof);
> }
> -----------------------

Well, I won't deny that most of the core devs don't use FreeBSD, and the auto-tester situation with FreeBSD needs to be improved, but that code compiles just fine on my TrueOS system with dmd master, and that code is not the sort of thing that I would expect to have issues that depended on the OS it was on. What version of dmd are you running?

- Jonathan M Davis