• d-bugmail puremagic.com (49/49) Dec 05 2021 https://issues.dlang.org/show_bug.cgi?id=22571

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=22571

          Issue ID: 22571
           Summary: [internals] -target osMajor doesn't accurately reflect
                    actual OS version
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: ibuclaw gdcproject.org

The current implementation[1][2] works well for a typical FreeBSD target
triplet (version number is between 0..255), but falls flat for any other
BSD-based distribution (and maybe NT).

1. OpenBSD (i.e: powerpc64le-openbsd6.9)

Every OpenBSD release is a major release, so the parsed version number should
perhaps be `69` instead of `6`.

See: https://www.openbsd.org/plus.html


2. NetBSD (i.e: armv7-netbsd9.1)

NetBSD 9.0 is the 17th major release (other 9.x are feature releases), so they
obviously haven't always been following the convention of the first digit
meaning the major version number, but then again, probably no one will be
running NetBSD 1.5 any more, so this is just an observation.

See: https://netbsd.org/releases/formal-9/


3. Solaris (i.e: sparcv9-solaris2.11)

The '2' in solaris2 is not the major version number of the OS, rather it's a
legacy marker that came about by the jump from Solaris 2.6 to Solaris 7 - the
version triplet remained as solaris2.7 however.  So it is in the minor version
position that should determine what osMajor is set to.


4. MacOS (i.e: aarch64-darwin21)

There is no correlation between the darwin number and OSX version number (i.e:
darwin18 is 10.14, darwin19 is 10.15, darwin20 is 11.0, darwin21 is 12.0).  So
there may have to be some sort of associative array.  However it's likely
better to just ignore the darwin version number and allow users to specify the
(minimum) version they wish to support via another mechanism.

Similarly, version numbers in the __MAC_XX_YY macros use a six digit version
numbering scheme which would overflow a `ubyte` anyway i.e: 100500 (10.5),
101500 (10.15), 110000 (11.0).


5. Windows (i.e: x86_64-windows2015)

I have no idea what versioning scheme Windows uses, but using a year was
accepted as valid by clang, and that would obviously overflow the ubyte field.


[1]:
https://github.com/dlang/dmd/blob/943abe37fa475099714f3c652a8b64ea2cb40272/src/dmd/target.d#L110
[2]:
https://github.com/dlang/dmd/blob/943abe37fa475099714f3c652a8b64ea2cb40272/src/dmd/target.d#L1631-L1638

--