Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unrecognized file extension lib #15

Closed
dukc opened this issue Mar 7, 2019 · 51 comments
Closed

Unrecognized file extension lib #15

dukc opened this issue Mar 7, 2019 · 51 comments

Comments

@dukc
Copy link
Contributor

dukc commented Mar 7, 2019

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
Copy link
Owner

skoppe commented Mar 7, 2019

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
Copy link
Contributor Author

dukc commented Mar 7, 2019

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
Copy link
Owner

skoppe commented Mar 8, 2019

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

@dukc
Copy link
Contributor Author

dukc commented Mar 8, 2019

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
Copy link
Owner

skoppe commented Mar 8, 2019

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

@dukc
Copy link
Contributor Author

dukc commented Mar 8, 2019

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

@skoppe
Copy link
Owner

skoppe commented Mar 9, 2019

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
Copy link
Contributor

Beyarz commented Mar 10, 2019

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
Copy link
Contributor Author

dukc commented Mar 10, 2019

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
Copy link
Contributor Author

dukc commented Mar 10, 2019

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
Copy link
Owner

skoppe commented Mar 10, 2019

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
Copy link
Contributor Author

dukc commented Mar 10, 2019

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
Copy link
Contributor Author

dukc commented Mar 11, 2019

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
Copy link
Owner

skoppe commented Mar 11, 2019

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
Copy link
Contributor Author

dukc commented Mar 12, 2019

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
Copy link
Owner

skoppe commented Mar 12, 2019

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
Copy link
Contributor Author

dukc commented Mar 14, 2019

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
Copy link
Owner

skoppe commented Mar 14, 2019

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
Copy link
Contributor Author

dukc commented Mar 15, 2019

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
Copy link
Contributor Author

dukc commented Mar 15, 2019

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
Copy link
Contributor Author

dukc commented Mar 15, 2019

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

@dukc dukc closed this as completed Mar 15, 2019
@skoppe
Copy link
Owner

skoppe commented Mar 18, 2019

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
Copy link
Contributor Author

dukc commented Mar 21, 2019

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
Copy link
Contributor Author

dukc commented Mar 28, 2019

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
Copy link
Owner

skoppe commented Mar 28, 2019

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
Copy link
Contributor Author

dukc commented Mar 28, 2019

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
Copy link
Owner

skoppe commented Mar 28, 2019

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
Copy link

kinke commented Aug 6, 2019

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
Copy link
Owner

skoppe commented Aug 7, 2019

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

@skoppe skoppe reopened this Aug 7, 2019
@dukc
Copy link
Contributor Author

dukc commented Aug 7, 2019

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
Copy link

aferust commented Dec 27, 2019

Same problem here. Is there any solution yet?

@skoppe
Copy link
Owner

skoppe commented Dec 27, 2019

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

@skoppe
Copy link
Owner

skoppe commented Dec 27, 2019

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
Copy link

aferust commented Dec 27, 2019

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
Copy link
Owner

skoppe commented Dec 27, 2019

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
Copy link

kinke commented Dec 28, 2019

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
Copy link

aferust commented Dec 28, 2019

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
Copy link

aferust commented Dec 28, 2019

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
Copy link

kinke commented Dec 28, 2019

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

@skoppe
Copy link
Owner

skoppe commented Dec 29, 2019

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
Copy link

aferust commented Dec 29, 2019

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-x86_64/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-x86_64/bin/../import/core/stdc/wchar_.d(131,5): Error: undefined identifier FILE
/home/user/dprojects/ldc2-1.19.0-linux-x86_64/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-x86_64/bin/../import/core/stdc/wchar_.d(133,5): Error: undefined identifier FILE
/home/user/dprojects/ldc2-1.19.0-linux-x86_64/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-x86_64/bin/../import/core/stdc/wchar_.d(135,5): Error: undefined identifier wchar_t, did you mean dchar?

@skoppe
Copy link
Owner

skoppe commented Dec 29, 2019

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
Copy link

aferust commented Dec 29, 2019

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

@dukc
Copy link
Contributor Author

dukc commented Jan 3, 2020

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
Copy link

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

@kinke
Copy link

kinke commented Aug 1, 2020

The dub issue should have been fixed almost a year ago with dlang/dub#1755, which has landed in dub v1.18.

@skoppe
Copy link
Owner

skoppe commented Aug 1, 2020

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

@skoppe skoppe closed this as completed Aug 1, 2020
@dukc
Copy link
Contributor Author

dukc commented Aug 1, 2020

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

@helikopterodaktyl
Copy link

Looks like these errors still show up on Windows: #15 (comment)

@skoppe
Copy link
Owner

skoppe commented Aug 2, 2020

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.

@helikopterodaktyl
Copy link

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.

I will do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants