Unrecognized file extension lib

[dukc]

When I try to build the dom example (in the dub cache, without moving it away), using dub build --compiler=ldc2, dub will complain

Error: unrecognized file extension lib
ldc2 failed with exit code 1.

I have had dub to run the bootstrap-webassembly subpackage, and there is a spasm.lib in the spasm project root directory. Operating system is Windows 10, compiler is LDC2 v.1.14.0 and dub version is 1.13.0.

ldc2 invocation dub tries is:

ldc2 -mtriple=wasm32-unknown-unknown-wasm -Oz -fvisibility=hidden -mtriple=wasm32-unknown-unknown-wasm -fvisibility=hidden -of.dub\build\application-debug-windows-x86_64-ldc_2084-03121F16D317F7774395673E07F6EC3A\dom.exe -d-debug -g -w -betterC -oq -od=.dub/obj -d-version=Have_dom -d-version=Have_spasm -d-version=Have_optional -d-version=Have_stdx_allocator -d-version=Have_silly -d-version=Have_bolts -Isource -I..\..\source -I..\..\..\..\optional-0.10.0\optional\source -I..\..\..\..\optional-0.10.0\optional\tests -I..\..\..\..\silly-0.8.0\silly -I..\..\..\..\bolts-0.11.1\bolts\source -I..\..\..\..\stdx-allocator-2.77.3\stdx-allocator\source source\app.d ..\..\.dub\build\library-debug-windows-x86_64-ldc_2084-978B389E93B753EFE6FA68C331E24002\spasm.lib ..\..\..\..\optional-0.10.0\optional\.dub\build\unittest-debug-windows-x86_64-ldc_2084-1EE5AD555BBB99C6F59EAF0349008D03\optional.lib ..\..\..\..\bolts-0.11.1\bolts\.dub\build\library-debug-windows-x86_64-ldc_2084-F3E97C00E271D52EA5BD1AB8B90FC84F\bolts.lib ..\..\..\..\stdx-allocator-2.77.3\stdx-allocator\.dub\build\library-debug-windows-x86_64-ldc_2084-E39B62569AB1854B8E161FAE2671AB92\stdx-allocator.lib -L=-strip-all -L=-allow-undefined -L=-import-memory -L=--export-table -vcolumns

Has anybody else here experienced this error? Thanks.

[skoppe]

Can you try with dub build --build=release --compiler=ldc2?

I have never tried to run spasm on windows to be honest. But I don't see why it shouldn't work.

[dukc]

Can you try with dub build --build=release --compiler=ldc2?

Same result.

I'm not sure if it's about spasm or dub. Can be either one.

[skoppe]

I will spin up my Windows machine this weekend to try to see what is going on.

[dukc]

Adding --combined flag appears to avoid that .lib problem, but now it complains:

C:\D\ldc2\bin\..\import\core\stdc\time.d(151,14): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(151,14): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(153,17): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(153,17): Error: undefined identifier tm
C:\D\ldc2\bin\..\import\core\stdc\time.d(155,9): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(155,9): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(158,17): Error: undefined identifier tm
C:\D\ldc2\bin\..\import\core\stdc\time.d(160,17): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(162,17): Error: undefined identifier tm
C:\D\ldc2\bin\..\import\core\stdc\time.d(162,17): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(164,17): Error: undefined identifier tm
C:\D\ldc2\bin\..\import\core\stdc\time.d(164,17): Error: undefined identifier time_t, did you mean function time?
C:\D\ldc2\bin\..\import\core\stdc\time.d(166,17): Error: undefined identifier tm
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(86,14): Error: undefined identifier wchar_t, did you mean dchar?
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(89,5): Error: undefined identifier FILE
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(89,5): Error: undefined identifier wchar_t, did you mean dchar?
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(91,5): Error: undefined identifier FILE
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(91,5): Error: undefined identifier wchar_t, did you mean dchar?
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(93,5): Error: undefined identifier wchar_t, did you mean dchar?
C:\D\ldc2\bin\..\import\core\stdc\wchar_.d(93,5): Error: undefined identifier wchar_t, did you mean dchar?

I wonder why the compiler tries to import those?

[skoppe]

It could be that you forgot to add -betterC to the dflags in dub.sdl/json

[dukc]

Nope. Its the examples/dom of this repo which already contains that flag.

[skoppe]

I tried on my windows box, but got the same errors. I suggest to make a minimal test case (preferably without spasm, just betterC), and then ask the ldc or probably druntime folks whats going on.

[Beyarz]

Performing "release" build using ldc2 for x86_64.
bolts 0.11.1: target for configuration "library" is up to date.
optional 0.10.1: target for configuration "unittest" is up to date.
stdx-allocator 2.77.3: target for configuration "library" is up to date.
spasm 0.1.9: target for configuration "library" is up to date.
spasm2 ~master: building configuration "application"...
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(151,14): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(151,14): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(153,17): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(153,17): Error: undefined identifier tm
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(155,9): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(155,9): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(158,17): Error: undefined identifier tm
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(160,17): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(162,17): Error: undefined identifier tm
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(162,17): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(164,17): Error: undefined identifier tm
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(164,17): Error: undefined identifier time_t, did you mean function time?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/time.d(166,17): Error: undefined identifier tm
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(86,14): Error: undefined identifier wchar_t, did you mean dchar?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(89,5): Error: undefined identifier FILE
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(89,5): Error: undefined identifier wchar_t, did you mean dchar?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(91,5): Error: undefined identifier FILE
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(91,5): Error: undefined identifier wchar_t, did you mean dchar?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(93,5): Error: undefined identifier wchar_t, did you mean dchar?
/Users/beyar/dlang/ldc-1.14.0/bin/../import/core/stdc/wchar_.d(93,5): Error: undefined identifier wchar_t, did you mean dchar?
ldc2 failed with exit code 1.

I receive the same error when running dub build --compiler=ldc2 --build=release

[dukc]

I tried on my windows box, but got the same errors. I suggest to make a minimal test case (preferably without spasm, just betterC), and then ask the ldc or probably druntime folks whats going on.

Of course, should have occured on me to do already.

[dukc]

Building a minimalistic wasm binary revealed that DUB appends .exe to the object binary name instead of .wasm. By taking the ldc2 invocation of DUB, replacing -of parameter with app.wasm and running that command manually produces a correctly working WASM binary.

However, doing the same to the dom example won't remove the errors. Something is importing different stuff on Windows than on other platforms.

[skoppe]

Interesting. So the dom example complains about core/stdc/time.d, but a -betterC minimalistic wasm doesn't?

Hmm.. I will have to look into this some more.

[dukc]

Interesting. So the dom example complains about core/stdc/time.d, but a -betterC minimalistic wasm doesn't?

That's correct

Hmm.. I will have to look into this some more.

Of course, it can be some of the dependecies, not spasm itself.

[dukc]

I think I got a bit forward. It seems that two changes are needed:

1: For some reason, DUB imports modules from dependency packages needlessly. I got around this by commenting out global imports and classes on optional\tests and removing all files from stdx-allocator except building_blocks\null_allocator.d and internal.d

2: My LDC did not like your declaration of _d_array_slice_copy. I changed it to take and use one more parameter size_t elemsz so it's signature matches that of official LDC runtime, and LDC stopped complaining.

After these changes, the dom example compiled. I am not yet sure if it works, because my browser won't let me to just import the autogenerated entry.js without a fight. I think I'll get there, but that's a task for tomorrow.

[skoppe]

That is great! I hope to find some time later this week to try to incorporate your changes,

The entry.js cannot be served up as is. It first needs to be bundled. spasm:bootstrap-webpack comes with a dev-server included. Just run npm install && npm run start in the workdir to start a webpack dev-server. It will bundle the javascript glue code and serve it up, as well as the wasm file.

Although now that you set the extension to .wasm it won't find it (well, it won't find the .exe either). You'll need to manually change the filename in ./spasm/modules/spasm.js @ line 32.

[dukc]

I think I'll get there, but that's a task for tomorrow.

Didn't finish today. (I'm not trying anymore to get the example working, but my production code. It's more onerous because I have many functions in D that I need to call from JavaScript.)

[skoppe]

Let me know if you need some pointers calling D from Javascript. It's pretty straightforward, but when you are dealing with strings, D structs or float arrays I have some experience with that.

[dukc]

What I'm going to ask may be a canditate for thedailywtf.com, but here goes anyway.

So I got the idea that I want to avoid using npm/npx, to avoid having to learn a new program. So I copied contents of the autogenerated spasm.js among my other JavaScript code, which is directly included in HTML, in a non-modular manner. A function that's called before any WASM calls spasm.init()

Because of that, the spasm.init JavaScript function got MIME type errors (without aborting, I had to debug for some time before figuring them out). So I rewrote the function (another reason is avoiding importing modules variable from index.js).

    init: () => {
        fetch("dmodule.wasm")
        .then(response => response.arrayBuffer())
        .then(buffer => WebAssembly.instantiate(buffer, { imports: jsExports }))
        .then(obj =>
        {   spasm.instance = obj.instance;
            obj.instance.exports._start();
            window.alert("spasm ready");
        })
        .catch(error => {window.alert(error);})
    }

LATER NOTE: { imports: jsExports } needs to be { env: jsExports } instead

Now it apparently finds and loads the WebAssembly, but it does not work: CompileError: wasm validation error: at offset 4: failed to match magic number. Does this prove that dmodule.wasm still does not compile correctly, or could have I screwed up with something else?

[skoppe]

So I got the idea that I want to avoid using npm/npx, to avoid having to learn a new program.

By avoiding npm you are only making it more difficult for yourself. I would really suggest to go with npm. You can include your own code in entry.js, or just add it to the index.html.

It would be nice to have alternative bootstraps, but it is at the bottom of the backlog. (e.g. https://pax.js.org/)

I can still give you some tips on getting something to run, but you are pretty much on your own.

Mdn has some good docs on WebAssembly and some good examples. See https://developer.mozilla.org/en-US/docs/WebAssembly

So I rewrote the function

Looks good to me. For performance you could use instantiateStreaming instead.

another reason is avoiding importing modules variable from index.js

Depending on what you want to do with spasm you might need those modules. I understand that you are trying to run the code directly in the browser and are thus avoiding JS ES6 modules. But it is like a bit like going against the grain.

Does this prove that dmodule.wasm still does not compile correctly, or could have I screwed up with something else?

The code looks ok. From the compile error you get I can only conclude that the dmodule.wasm isn't a valid wasm file. You can drag'n-drop your wasm file in https://webassembly.studio/ (press cancel on create new project dialog) and see if it is valid. (or use tooling from the binaryen project). If it does happen to be a valid file then you might have some mime issues. The server you are serving the wasm file needs to return content-type: application/wasm.

[dukc]

Webassembly studio binaryen entered infinite loop. So I decided to compare dmodule.wasm with WASM files at spasm/docs/examples with a hex editor. They look different, meaning that there is still something wrong either in the way DUB called ldc, or ldc itself :-(. TBH my dmodule.wasm was generated by dub, with the .exe extension changed afterwards. However, I don't think invoking ldc with -ofdmodule.wasm will change that, as I do recall that it didn't change executable size compared to using ldc via dub.

[dukc]

However, the dom example .wasm (and .exe) I also compiled were valid. It's something else that causes dmodule to target wrong arch. Perhaps because dub tries to build it as a library. I have to test more.

[dukc]

Indeed, the problem was DUB trying to build a library configuration. I now managed to get the first D function call verifiably to work.

[skoppe]

Great. Any tips that I can update the README.md with, for fellow windows users?

If I read the thread correctly it would be to add --combined and to avoid having dub include optional/test files?

[dukc]

Great. Any tips that I can update the README.md with, for fellow windows users?

If I read the thread correctly it would be to add --combined and to avoid having dub include optional/test files?

For the --combined flag, correct. For changes on optional/tests and stdx-allocatior, as hackish as it is, I just made the changes in the packages where DUB imported them.

And also, I don't know if this is Windows specific but you need to make sure DUB is building an application, never a library. Otherwise it won't be valid wasm.

[dukc]

BTW in case you want to know: today, I have finished porting all the parts of my application that formerly ran on Emscripten, and merged the result to master. Your library will very soon be in commercial "production".

[skoppe]

That is awesome! I am a little curious, any change of showing the source? Or maybe you could describe what parts of spasm you are using?

[dukc]

I cannot show the source as a whole, since it's a propietary piece, but the work in general is no secret so I can freely talk about it, and I don't think anybody will mind if I include some snippets. A small company and I'm the only programmer so no rigid rules.

It is a product preview program for salesmen, that runs in a browser. Only locally, currently, but the idea is to put it in the Internet someday, so we want to embed the program in HTML. I did not like the idea about doing a major application in JavaScript, so I use Bridge.Net (that compiles C# into JS) instead. If you were wondering how can I be so bad at JavaScript development, now you know why.

In summer 2018, I took a major effort to embed D code in the application, fairly much just because I wanted to. I used https://github.com/cosinus2/dlang-emscripten-demo as my base example, which meant fooling LDC to think it was compiling to X86 but only compiling to LLVM bytecode and feeding that to Emscripten. I had to copy every std import I used and also compile them, and manually link them together before invoking Emscripten. LDC and Emscripten linker often seemed to just disagree what was needed in the program and what was not, which meant a lot of trial and error and ugly hacks to get stuff to compile and link. Afterwards, I discovered that LDC and Emscripten represented different versions of LLVM! LDC was 6.x.x while Emscripten was 5.x.x. When LDC was upgraded to 7.x.x, it stopped working. I could have probably compiled LDC myself to an older LLVM, but didn't get that far.

Porting the D code to Spasm should cut down the overall number of problems like those I described. Now at least I can use a more up-to-date LDC, and it knows it's compiling to WASM. Plus, there's potential to command JavaScript classes from D code. I haven't done that yet, since with my lack of JavaScript skills and lack of an existing library to help with interfacing, writing JS bindings just for Emscripten D didn't seem worthwhile. But with this library that as both examples and code to take as a base, it may be relevant in the future.

One thing that consumed a big deal of time was that unlike Emscripten, Spasm does not have malloc/free, so I wrote up my own (I did want to free memory after use):

enum memPageAmount = 0x200u;
enum memSizeClasses = 13u;
enum pageSize = 1u << memSizeClasses-1;
__gshared ushort[memSizeClasses] lastMemoryPages;
__gshared uint[memPageAmount] heapMap;
__gshared void[pageSize][memPageAmount] heap = void;

export extern(C) void* malloc(size_t amount)
{   if (amount == 0) return null;
    foreach(allocSize; memSizeClasses.iota)
        if (amount <= (1u << allocSize))
        foreach(pageI; lastMemoryPages[allocSize].iota(lastMemoryPages[allocSize] + memPageAmount).map!(i => cast(short)i))
    {   pageI %= memPageAmount;

        void* result;
        if
        (   heapMap[pageI] >= 0x0100_0000u >>> allocSize * 2
            &&  heapMap[pageI] <  0x0300_0000u >>> allocSize * 2
            && ~heapMap[pageI] &  0x0000_0FFFu >>> allocSize
        )
        {   result = &heap[pageI][0] + ((heapMap[pageI] & 0xFFF >>> allocSize) + 1) * (1u << allocSize);
            //merkitsee muistikarttaan lohkon käyttöönoton.
            heapMap[pageI]++;
        } else if (heapMap[pageI] == 0)
        // varaamaton sivu. Eiköhän oteta käyttöön.
        {   heapMap[pageI] = 0x0100_0000u >>> allocSize * 2;
            result = heap[pageI].ptr;
        }
        else continue;

        assert(result >= heap.ptr && result < heap.ptr + memPageAmount);
        lastMemoryPages[allocSize] = pageI;
        assert(heapMap[pageI] != 0);
        return result;
    }

    auto pagesNeeded = (amount - 1) / pageSize + 1;
    //yli muistisivun kokoisen alueen varaus
    size_t result = 0;
    foreach (canditate; heapMap[].slide(pagesNeeded).filter!(potentialAlloc => potentialAlloc.all!(page => page == 0u)))
    {   if (canditate.all!(page => page == 0u)) goto foundArea;
        result++;
    }
    //muisti loppu
    return null;

    foundArea:
    heapMap[result] = 2u;
    foreach(ref pageMark; heapMap[].drop(result + 1).takeExactly(pagesNeeded-1))
    {   pageMark = 3u;
    }

    return heap[result].ptr;
}

export extern(C) void free(const(void)* cAllocation)
{   //Oletettavasti tälle funktiolle välitetty osoitin dumpataan jorpakkoon heti jälkeenpäin,
    //joten tämä tyyppimuunnos ei luultavasti aiheuta ongelmia.
    auto allocation = cast(void*) cAllocation;
    if (allocation == null) return;
    assert(allocation >= heap.ptr && allocation < heap.ptr + memPageAmount, "free() ei osoita kekoon!");

    ptrdiff_t allocAddr = allocation - &heap[0][0];
    size_t pageI = allocAddr / pageSize;
    size_t pageOffset = allocAddr % pageSize;

    assert (heapMap[pageI] != 0, "Yritetään vapauttaa jo valmiiksi varaamatonta muistia");
    assert (heapMap[pageI] != 3, "Muistin vapautus ei osoita varatun pätkän alkuun");

    foreach(allocSize; memSizeClasses.iota) if
    (   heapMap[pageI] >= 0x0100_0000u >>> allocSize * 2
        &&  heapMap[pageI] <  0x0300_0000u >>> allocSize * 2
    )
    {   /+assert
        (   heapMap[pageI] >= cast(ulong)pageOffset * pageSize + 0x0100_0000u >>> allocSize * 2,
            "Yritetään vapauttaa jo valmiiksi varaamatonta muistia"
        );+/
        assert (pageOffset % 1u << allocSize == 0, "Muistin vapautus ei osoita varatun pätkän alkuun");

        //kirjoitetaan muistiin: yksi vapautettu.
        heapMap[pageI] += pageSize >>> allocSize;
        if (heapMap[pageI] > 0x0200_0000u >>> allocSize * 2) heapMap[pageI] = 0;
        return;
    }

    assert (heapMap[pageI] == 2u);
    heapMap[pageI] = 0;
    foreach(ref pageMark; heapMap[pageI+1 .. $].until!(a => a!=3u)) pageMark = 0;
}

(Comments/Asserts are Finnish)

Example of function used by application logic:

// Tulkitsee päivämäärät kahdesta merkkijonosta, ja palauttaa tuloksessa niiden keskinäisen järjestyksen
// (negatiivinen = lukujärjestys, 0 = samankokoiset)
// Ei tällä hetkellä osaa käsitelä oikein lukuja, joissa on nolla merkitsevimpänä numerona
// (eikä tätä kirjoitettaessa ole tarvettakaan sille)
export extern (C) int cmpDates(Handle a, Handle b)
{   auto strings = [a, b].staticArray[].map!(jsStr => jsStr.spasm_get__string).staticArray!2;
    scope (exit) foreach(str; strings) str.ptr.free;

    auto numbers = strings[]
    .map!
    (   str => str
        .byCodeUnit
        .retro
        .splitter!((a, b) => a.isDigit == b.isDigit)(' ')
    );

    if (auto result = numbers[0].walkLength - numbers[1].walkLength) return result;

    for(;!numbers[0].empty;numbers[0].popFront, numbers[1].popFront)
    {   if (auto result = numbers[0].front.length - numbers[1].front.length) return result;
        if (auto result = numbers[0].front.cmp(numbers[1].front)) return result;
    }

    //samat luvut.
    return 0;
}

If you're wondering, I have rewired spasm_get__string to use my malloc instead of the Spasm heap -I don't even initialize it.

I let anybody to use these examples under Boost license, but except bugs if you do.

[skoppe]

Thats pretty cool. Glad to see that it simplified your toolchain.

If you're wondering, I have rewired spasm_get__string to use my malloc instead of the Spasm heap -I don't even initialize it.

Yes, I was about to comment on it :)

I really need to solve that memory management. But without GC and with things like RCString, its a little tough.

[kinke]

Wrt. the original issue that hasn't been resolved: the thing is that dub uses extensions .lib and .exe in the output paths specified via -of if run on Windows (and not when targeting Windows). It later feeds LDC the same wasm .lib in a linker cmdline, but LDC is picky and only recognizes the file extensions for the target (i.e., expects .a for static wasm libs).

I haven't checked whether LLD supports a normal .a archive after renaming it to .lib. If it does, we could make LDC less picky. Otherwise, dub may have to become target-aware.

[skoppe]

I favor making dub target aware. Besides the .lib windows issue, I don't get a .wasm file on linux either. I have opened a dub issue https://github.com/dlang/dub/issues/1749

[dukc]

I favor making dub target aware. Besides the .lib windows issue, I don't get a .wasm file on linux either. I have opened a dub issue dlang/dub#1749

I prefer doing both. If conflating .a and .lib won't cause issues, that is.

[aferust]

Same problem here. Is there any solution yet?

[skoppe]

On windows you'll need to use the --combined flag to dub.

[skoppe]

The proper solution would be to add the --arch=wasm32-unknown-unknown-wasm to dub. But this needs to be supported in spasm and (more so in) it's dependencies.

[aferust]

while compiling dom example with this command: dub build --compiler=ldc2 --build=release --arch=wasm32-unknown-unknown-wasm

I get this: Failed to apply the selected architecture wasm32-unknown-unknown-wasm. Got [].

And note that I am using the dub binary that I ve just compiled from the ~master branch since I saw that your issue dlang/dub#1749 ended up with some commits by @kinke

[skoppe]

If you run ldc2 --version you should see a list of supported targets. wasm32 needs to be in that list. On my mac it isn't so I run the dlang2/ldc-ubuntu:1.18.0 docker container.

[kinke]

I get this: Failed to apply the selected architecture wasm32-unknown-unknown-wasm. Got [].

That's a dub warning that can safely be ignored.

[aferust]

wasm32 is listed. Ok I am igroring that warning. But I am also getting this similar to dukc's error ... Error: module core.stdc.stddef import wchar_t not found Error: undefined identifier time_t, did you mean function time? ...

[aferust]

It must be a ldc issue since I am facing the same problems when I try to compile this example involving in emscripten also: https://theartofmachinery.com/2018/12/20/emscripten_d.html

[kinke]

That's something completely different, limited WebAssembly support in druntime (no C runtime yet), which @skoppe is working on.

[skoppe]

wasm32 is listed. Ok I am igroring that warning. But I am also getting this similar to dukc's error ... Error: module core.stdc.stddef import wchar_t not found Error: undefined identifier time_t, did you mean function time? ...

Those errors are because something is pulling in druntime, which doesn't support wasm yet. Spasm and the examples are building on linux with the latest ldc 1.19.0 as evidenced by the CI https://github.com/skoppe/spasm/runs/365457809 so I suppose there is an error in your setup.

What does your dub.[sdl|json] look like? And what is the exact command you use to invoke dub?

[aferust]

Ok. this is what I do now:

I boot into my ubuntu partition (16.04 64 bit) downloaded ldc2-1.19.0-linux-x86_64.tar.xz and extracted to home folder. added path of ldc's bin folder in .bashrc cloned spasm and cd into examples/dom run: dub build --compiler=ldc2 --build=release --arch=wasm32-unknown-unknown-wasm --combined

and I get: Failed to apply the selected architecture wasm32-unknown-unknown-wasm. Got []. Performing "release" build using ldc2 for . dom ~master: building configuration "application"... /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/std/stdio.d(16,8): Error: module core.stdc.stddef import wchar_t not found /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(151,14): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(151,14): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(153,17): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(153,17): Error: undefined identifier tm /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(155,9): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(155,9): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(158,17): Error: undefined identifier tm /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(160,17): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(162,17): Error: undefined identifier tm /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(162,17): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(164,17): Error: undefined identifier tm /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(164,17): Error: undefined identifier time_t, did you mean function time? /home/user/dprojects/ldc2-1.19.0-linux-x86_64/bin/../import/core/stdc/time.d(166,17): Error: undefined identifier tm /home/user/dprojects/ldc2-1.19.0-linux-x8664/bin/../import/core/stdc/wchar.d(128,14): Error: undefined identifier wchar_t, did you mean dchar? /home/user/dprojects/ldc2-1.19.0-linux-x8664/bin/../import/core/stdc/wchar.d(131,5): Error: undefined identifier FILE /home/user/dprojects/ldc2-1.19.0-linux-x8664/bin/../import/core/stdc/wchar.d(131,5): Error: undefined identifier wchar_t, did you mean dchar? /home/user/dprojects/ldc2-1.19.0-linux-x8664/bin/../import/core/stdc/wchar.d(133,5): Error: undefined identifier FILE /home/user/dprojects/ldc2-1.19.0-linux-x8664/bin/../import/core/stdc/wchar.d(133,5): Error: undefined identifier wchar_t, did you mean dchar? /home/user/dprojects/ldc2-1.19.0-linux-x8664/bin/../import/core/stdc/wchar.d(135,5): Error: undefined identifier wchar_t, did you mean dchar?

[skoppe]

Yeah, don't add --arch=wasm32-unknown-unknown-wasm just yet. It first needs to be supported in the runtime.

--combined is only needed on Windows.

You might need --build-mode=allAtOnce if you are getting the --no-as-needed error.

I am using dub build --compiler=ldc2 --build=release --build-mode=allAtOnce on ubuntu.

[aferust]

Hey thank you! dub build --compiler=ldc2 --build=release --build-mode=allAtOnce That one worked! It should be mentioned in readme.

[dukc]

wasm32 is listed. Ok I am igroring that warning. But I am also getting this similar to dukc's error ... Error: module core.stdc.stddef import wchar_t not found Error: undefined identifier time_t, did you mean function time? ...

For Spasm to work at Windows (until DRuntime port is finished) you need to patch dub dependencies for this to work. My comment from earlier:

I think I got a bit forward. It seems that two changes are needed:

1: For some reason, DUB imports modules from dependency packages needlessly. I got around this by commenting out global imports and classes on optional\tests and removing all files from stdx-allocator except building_blocks\null_allocator.d and internal.d

2: My LDC did not like your declaration of _d_array_slice_copy. I changed it to take and use one more parameter size_t elemsz so it's signature matches that of official LDC runtime, and LDC stopped complaining.

After these changes, the dom example compiled. I am not yet sure if it works, because my browser won't let me to just import the autogenerated entry.js without a fight. I think I'll get there, but that's a task for tomorrow.

You need only to do the first piece, as second is now merged into spasm. Also use the already mentioned --combined and make sure that dub builds an application. If it tries to build a library, you need to manually override it.

No quarantee these will work anymore though, as it's roughly six months since I last built on Windows.

[helikopterodaktyl]

Any news on this? I would love to give this library a spin on Windows.

[kinke]

The dub issue should have been fixed almost a year ago with https://github.com/dlang/dub/pull/1755, which has landed in dub v1.18.

[skoppe]

Yes, I was waiting for the OP to close this, but will do this now.

The instructions are in the readme, for build instructions it refers to https://github.com/skoppe/spasm/blob/master/BUILDING.md

[dukc]

Go ahead, I'm not in a position to decide when it's fixed since I don't code on Windows anymore.

[helikopterodaktyl]

Looks like these errors still show up on Windows: https://github.com/skoppe/spasm/issues/15#issuecomment-471235467

[skoppe]

The errors in that comment are unrelated to this issue. If you get them something is going wrong with betterC, as the compiler is trying to pull in druntime, which it shouldn't.

If you can paste your dub.sdl and show the output of dub build -v --compiler=ldc2 --build=release --build-mode=allAtOnce (added the -v) I can help you better. But please open a separate issue.