fix Issue 22568 - -target option does nothing in compilation

[WalterBright]

At least it can now generate a Windows 64 object file.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	22568	major	-target option does nothing in compilation

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#13484"

[WalterBright]

****** FAIL debug64 std.experimental.allocator
core.exception.AssertError@std/experimental/allocator/package.d(3738): Assertion failure

This randomly shows up on diverse PRs. Sigh.

[WalterBright]

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

[WalterBright]

It appears to be impossible to get the autotester to not add -fPIC.

[WalterBright]

Filed this one on the test runner for blocking attempts to test Windows cross-compilation:

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

[WalterBright]

Parallels isolation failed: failed to create VM cloned from "monterey-xcode-13.2": Parallels VM operation failed: failed to clone VM "cirrus-b70e6248-edd9-4834-82ee-e84ba2dce3b9": Parallels command returned non-zero exit code: "Failed to clone the VM: Unable to perform the operation because "monterey-xcode-13.2" is in the intermediate state. Unpacking "/Users/administrator/Parallels/monterey-xcode-13.2.pvmi/config.pvsp" has been started but not finished yet. Please finish unpacking."

[WalterBright]

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

macOS 12.x x64, DMD (latest)

Can someone who knows how these tests work please address the heisenbugs?

[maxhaton]

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

macOS 12.x x64, DMD (latest)

Can someone who knows how these tests work please address the heisenbugs?

As far as I can tell this one is the CI provider fucking it up

I've just rerun it. if you sign into the ci provider you should have a button to rerun it also, you just need to sign in with your github account so it knows you have rights to the repository.

[WalterBright]

I've just rerun it.

Can we please find another way? I push the rerun button all the time, nothing happens. These heisenbugs now seem to prevent passing 75% of the time. This is just a terrible waste of time.

[WalterBright]

And ANOTHER one pops up:

Run (macOS-10.15, clang-13.0.0)

4s
Run dlang-community/setup-dlang@v1
Error: unrecognized DMD version: 
    at dmd (/Users/runner/work/_actions/dlang-community/setup-dlang/v1/dist/index.js:1:127324)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Object.compiler (/Users/runner/work/_actions/dlang-community/setup-dlang/v1/dist/index.js:1:126504)
    at async run (/Users/runner/work/_actions/dlang-community/setup-dlang/v1/dist/index.js:1:133006)
Error: unrecognized DMD version: 

[12345swordy]

All green here walter.

[PetarKirov]

Typo?

[WalterBright]

Nope. The test runner has a buggy parser in it, and will recognize PERMUTE_ARGS if it is embedded in another identifier.

[ibuclaw]

That should be addressed by #13478.

[MoonlightSentinel]

Filed this one on the test runner for blocking attempts to test Windows cross-compilation:

This is can easily be fixed in the test runner. But note that this will also be a pain for actual linux users which have -fPIC enabled by default in their dmd.conf.

[WalterBright]

this will also be a pain for actual linux users which have -fPIC enabled by default in their dmd.conf.

It will indeed. Users will need to use a different dmd.conf for cross compiling.

[PetarKirov]

Users will need to use a different dmd.conf for cross compiling.

I think the way LDC's configuration (based on libconfig) handles this is better: It allows multiple sections (e.g. one per target triple, or one section covering a family of triples idefied by a glob-like syntax (IIRC)), each of which can specify its own set of compiler arguments.

• Example: https://github.com/ldc-developers/ldc/blob/master/ldc2.conf.in
• libconfig: https://www.hyperrealm.com/libconfig/libconfig_manual.html
• LDC implementation: https://github.com/ldc-developers/ldc/blob/v1.28.0/driver/config.d#L119-L159

Perhaps DMD should adopt LDC's configuration format? One advantage for end users would be that they can put not only configuration for each target triple that they need in a single file, but they can also have configuration for both LDC and DMD in one place (perhaps GDC too, but I don't know if that's compatible with the GCC way of doing things). Also a user of the language would need to learn and maintain one configuration file instead of 2 (or more).

That said, users that care about cross-compilation are likely to handle this on the build-system level and they can simply pass -conf= to indicate that no config file should be used, so they can specify everything explicitly (that would otherwise be inside dmd.conf.

[RazvanN7]

I think we can close this now since we the -os switch.