When trying to compile a project including newest Spasm (DUB package) using the newest LDC via DUB, the result is:
```
lld: error: unknown argument: --no-as-needed
```

I then ran DUB with -v switch and it turned out the invocation contained `-L--no-as-needed` as first of all the -L arguments. The trouble is, how do I know what causes DUB to add that argument to the invocation? I could find no reason in `dub.<json/sdl>` files of either my package, Spasm or any package in Spasm dependency tree.

On Tuesday, 12 November 2019 at 16:44:06 UTC, Dukc wrote:
> When trying to compile a project including newest Spasm (DUB package) using the newest LDC via DUB, the result is:
> ```
> lld: error: unknown argument: --no-as-needed
> ```
>
> I then ran DUB with -v switch and it turned out the invocation contained `-L--no-as-needed` as first of all the -L arguments. The trouble is, how do I know what causes DUB to add that argument to the invocation? I could find no reason in `dub.<json/sdl>` files of either my package, Spasm or any package in Spasm dependency tree.

Dub is open-source, so you can grep the source. - Dub uses it for all 3 compilers (e.g., https://github.com/dlang/dub/blob/f87302dd206b0e5871b39704e694b2194e294aa5/source/dub/compilers/ldc.d#L249), and I'm not sure it's really needed. Anyway, you can also use another linker that supports this flag (e.g., via `-linker=gold`).

On Tuesday, 12 November 2019 at 18:32:32 UTC, kinke wrote:
>
> Dub is open-source, so you can grep the source. - Dub uses it for all 3 compilers (e.g., https://github.com/dlang/dub/blob/f87302dd206b0e5871b39704e694b2194e294aa5/source/dub/compilers/ldc.d#L249), and I'm not sure it's really needed. Anyway, you can also use another linker that supports this flag (e.g., via `-linker=gold`).

Thanks. At first it didn't seem to work. Then I realized that the `--link-internally` flag that's specified in `ldc.conf` prevents changing the linker. Took it off, and the gold linker understood the flag in question, but had problems with others. I tried removing some, but there were still more to remove. Getting WASM code to link tends to be trial and error in my experience, so I decided best not to stray far from what Spasm does.

I also tried LDC 1.18, but the dub also added that unwanted flag here. I don't wan't to use older LDC than that.

However, extracting the LDC invocation and manually calling it without `--no-as-needed` appears to work. Solution? I'm going to write my `build.d` to do just that automatically.

Is there an issue about that already, or should I open one?

On Tuesday, 12 November 2019 at 16:44:06 UTC, Dukc wrote:
> When trying to compile a project including newest Spasm (DUB package) using the newest LDC via DUB, the result is:
> ```
> lld: error: unknown argument: --no-as-needed
> ```
>
> I then ran DUB with -v switch and it turned out the invocation contained `-L--no-as-needed` as first of all the -L arguments. The trouble is, how do I know what causes DUB to add that argument to the invocation? I could find no reason in `dub.<json/sdl>` files of either my package, Spasm or any package in Spasm dependency tree.

I have seen this error as well. I actually test a few ldc versions on the CI, and I always test latest.

Currently anything higher than 1.17 is not supported, although it would probably require a small change.

Except for the fact that -mtriple gets propagated starting from 1.18 to all dependencies (which is a good thing). This causes issues for some of the dependencies since they have no idea what wasm is.

It has been on the back of my mind since 1.18-beta came out. I am going to reserve a little time tomorrow to work on it.

Thanks for digging as far as you have.

On Wednesday, 13 November 2019 at 15:41:01 UTC, Sebastiaan Koppe wrote:
> It has been on the back of my mind since 1.18-beta came out. I am going to reserve a little time tomorrow to work on it.

Regarding that, perhaps I can save you a bit trouble if you also try to get 1.19 working: if you get compile errors related to SortedRange, the fix is https://github.com/dlang/phobos/pull/7266.

On Wednesday, 13 November 2019 at 18:10:15 UTC, Dukc wrote:
> On Wednesday, 13 November 2019 at 15:41:01 UTC, Sebastiaan Koppe wrote:
>> It has been on the back of my mind since 1.18-beta came out. I am going to reserve a little time tomorrow to work on it.
>
> Regarding that, perhaps I can save you a bit trouble if you also try to get 1.19 working: if you get compile errors related to SortedRange, the fix is https://github.com/dlang/phobos/pull/7266.

I have had some time today to look into this. About the --no-as-needed:

TL;DR: add `--build-mode=allAtOnce` to the dub command.

Kinke made some changes in dub to facilitate separate linking for ldc. I am not aware of all the details but the major benefit is that it allows cross compilation with dub and ldc.

Because of the separate linking the --no-as-needed turned up. As far as I can see it is only needed when compiling for linux.

Which brings up the question, why linux? Aren't we compiling for wasm?

Well yes. But that is just the way things worked up until now, ldc and dub just pick the host machine.

Luckily there is the new dub `--arch` argument that can take a llvm triple, in our case wasm32-unknown-unknown-wasm. This causes dub not to add the `--no-as-needed`.

Except, that it also passes the triple upwards the dependency tree. Now all the dependencies of spasm get compiled targeting wasm. This is a good thing, except that the optional package which spasm depends on fails to compile with it. There is a newer version that fixes the configuration, but that one fails because of the `from.std` import idiom (it imports the std package from phobos which doesn't recognise wasm and fails with "Unknown OS").

In the end it is all caused by phobos and druntime not knowing anything about wasm. Which I am currently working on behind the scenes to fix.

In the meantime I am going to make a PR for the optional package to avoid the `from.std` idiom. Although I might end up playing whack-a-mole here, as there might be more dependencies that need a fix now.

Another workaround that you can use right now is by adding the `--build-mode=allAtOnce` argument to dub. It effectively gets you the old behaviour. It is what I am using in my CI to get it to go green again.

On Monday, 18 November 2019 at 19:35:13 UTC, Sebastiaan Koppe wrote:
> Kinke made some changes in dub to facilitate separate linking for ldc. I am not aware of all the details but the major benefit is that it allows cross compilation with dub and ldc.
>

Yeah, definitely useful if you want to link in, say, a C-borne wasm
binary.

> Because of the separate linking the --no-as-needed turned up. As far as I can see it is only needed when compiling for linux.
>
> Which brings up the question, why linux? Aren't we compiling for wasm?
>
> Well yes. But that is just the way things worked up until now, ldc and dub just pick the host machine.
>
> Luckily there is the new dub `--arch` argument that can take a llvm triple, in our case wasm32-unknown-unknown-wasm. This causes dub not to add the `--no-as-needed`.

That was news to me - I thought everything was always being compiled to WASM.

>
> Except, that it also passes the triple upwards the dependency tree. Now all the dependencies of spasm get compiled targeting wasm. This is a good thing, except that the optional package which spasm depends on fails to compile with it. There is a newer version that fixes the configuration, but that one fails because of the `from.std` import idiom (it imports the std package from phobos which doesn't recognise wasm and fails with "Unknown OS").

I have sometimes thought that perhaps a static assert isn't the best thing to use for unimplemented features in Phobos, precisely because of this issue. A @disabled function stub would serve better, unless I'm missing something.

>
> In the meantime I am going to make a PR for the optional package to avoid the `from.std` idiom. Although I might end up playing whack-a-mole here, as there might be more dependencies that need a fix now.

"ending up"? If it's like what getting Phobos to work has been for me, you're continuing the game, not ending up playing it ;D.

>
> Another workaround that you can use right now is by adding the `--build-mode=allAtOnce` argument to dub. It effectively gets you the old behaviour. It is what I am using in my CI to get it to go green again.

Do not hurry more than you want -I already got my extract-dub-failure workaround working.

On Tuesday, 19 November 2019 at 12:06:36 UTC, Dukc wrote:
> On Monday, 18 November 2019 at 19:35:13 UTC, Sebastiaan Koppe wrote:
>> Well yes. But that is just the way things worked up until now, ldc and dub just pick the host machine.
>>
>> Luckily there is the new dub `--arch` argument that can take a llvm triple, in our case wasm32-unknown-unknown-wasm. This causes dub not to add the `--no-as-needed`.
>
> That was news to me - I thought everything was always being compiled to WASM.

Well it is, but some versions from the host were still set. E.g. version(linux).

>> Except, that it also passes the triple upwards the dependency tree. Now all the dependencies of spasm get compiled targeting wasm. This is a good thing, except that the optional package which spasm depends on fails to compile with it. There is a newer version that fixes the configuration, but that one fails because of the `from.std` import idiom (it imports the std package from phobos which doesn't recognise wasm and fails with "Unknown OS").
>
> I have sometimes thought that perhaps a static assert isn't the best thing to use for unimplemented features in Phobos, precisely because of this issue. A @disabled function stub would serve better, unless I'm missing something.

Either way, as long as there is a clear way to debug why it ended up there. Unlike what we have now where you need to dig endlessly.

> "ending up"? If it's like what getting Phobos to work has been for me, you're continuing the game, not ending up playing it ;D.

Yeah it is a pain, and since wasm/betterc isn't tested (or barely), anyone is free to break it. E.g. the recent change to the std.range.chain function, which suddenly wasn't betterC anymore...

>> Another workaround that you can use right now is by adding the `--build-mode=allAtOnce` argument to dub. It effectively gets you the old behaviour. It is what I am using in my CI to get it to go green again.
>
> Do not hurry more than you want -I already got my extract-dub-failure workaround working.

Sure, but stuff just needs to work. I updated the BUILDING.md file in spasm as well.

On Tuesday, 19 November 2019 at 13:41:32 UTC, Sebastiaan Koppe wrote:
>> A @disabled function stub would serve better, unless I'm missing something.
>
> Either way, as long as there is a clear way to debug why it ended up there. Unlike what we have now where you need to dig endlessly.

But the @disabled function stub (if my thinking is sound) would have the advantage that it'd prevent compilation only if called -not if only imported.