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

port-javascript: prevent clang as a parser to use host headers #4875

Open
wants to merge 26 commits into
base: master
from

Conversation

@pmp-p
Copy link
Contributor

commented Jun 25, 2019

because emcc looks by itself into that ports folders cache but clang -E cannot.

This way if a header is missing clang used as preprocessor won't tap by default in /usr/include.

It will break build and will force user to explicitly add
-I$(EM_CACHE)/asmjs/ports-builds/somelib*/include for his libs.

port-javascript: prevent clang as a parser to use host headers
because emcc looks by itself into that ports folders cache but clang -E cannot.

This way if a header is missing clang used as preprocessor won't tap by default in /usr/include.

It will break build and will force user to explicitly add 
-I$(EM_CACHE)/asmjs/ports-builds/****somelib*****/include for his libs.
@dpgeorge

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

As an alternative to this, I tried defining CPP = emcc -E but this doesn't like multiple input files, so I then concat'd all files in to one and ran that through emcc -E, and it seemed to work. I don't know if that would be preferred (using emcc -E instead of clang -E) but it would need a modification to py/mkrules.mk to do the concat'ing.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2019

emcc sure does ** a lot ** of things clang alone cannot, including ... downloading ports source code, patching and building them on the fly for the selected targets. and i maybe wrong but think prepro is run before emcc giving no chances to do all that.

also there's all vital -s FLAGS clang will not undesrtand.

+1 for emcc everywhere it could be used, or building modules will be hotline hell added to loss of control for debugging / ram settings / library switches.

@embeddedt

This comment has been minimized.

Copy link

commented Jun 26, 2019

+1 for emcc everywhere it could be used, or building modules will be hotline hell added to loss of control for debugging / ram settings / library switches.

By no means am I a MicroPython expert, but when I was fiddling with this to get LittlevGL working with JavaScript, I found that the clang -E hack was only necessary at the beginning of the build process, for QSTR generation. emcc was used everywhere else.

That means that debugging settings and extra libraries shouldn't be affected.

The issue with clang -E is that it requires you to have compiled SDL2 in advance.

The proper solution, I think, is for emcc -E to behave the way clang -E does.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2019

That means that debugging settings and extra libraries shouldn't be affected.

indeed debugging flags seem harmless, but extra libraries have an influence with modules building system because eg -s USE_SDL=2 or -s SOCKET_WEBRTC=0/1 would get passed via the CFLAGS_EXTRA and breaks clang.

in that case i think clang cannot be used as an emcc replacement at all. it would complicate things too much for user module creation. What if emscripten changes some vars or the undocumented cache path or use a relative path in EM_CACHE ?

@embeddedt

This comment has been minimized.

Copy link

commented Jun 26, 2019

What if emscripten changes some vars or the undocumented cache path or use a relative path in EM_CACHE ?

In that case, EM_CACHE could quickly be updated.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2019

@embeddedt i see trouble handling a bunch of modules vs system emscripten / emsdk git that would use different path ....

@dpgeorge

This comment has been minimized.

Copy link
Member

commented Jul 1, 2019

I tried to use emcc -E instead of clang -E but it just cannot work, because:

  • emcc -E must only be passed .c files, not .h files (and also cannot read from stdin)
  • concatenating all required inputs to emcc -E into another temporary file and then passing that to emcc -E doesn't work because it can't find header includes (which are sometimes relative to the source file being processed, and if everything is combined into a single .c file then it's impossible to know where the relative headers are)

It seems the only way to fix it properly would be to patch emcc (which is really out of scope here).

So I guess the fix in this PR is the only way forward.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jul 1, 2019

then maybe fix this + find a normalized way to add @embeddedt 's method for settings includes for modules, maybe CPPFLAGS_USERMOD along with - but instead - of CFLAGS_USERMOD which should keep emcc specifics.

Maybe a prefilled list of CPPFLAGS_USERMOD with expected standard emscripten paths : there's not so much ports after all.

@embeddedt

This comment has been minimized.

Copy link

commented Jul 6, 2019

@pmp-p

downloading ports source code, patching and building them on the fly for the selected targets. and i maybe wrong but think prepro is run before emcc giving no chances to do all that.

Correct, but have you heard of embuilder.py? It can be run separately from emcc and could be used to fetch ports before clang is invoked manually.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2019

@embeddedt thanks that would seem very usefull to easy preload things for user modules

$ embuilder.py build --lto --pic sdl2
embuilder:INFO: building and verifying sdl2
embuilder:INFO: ...success

sadly there's nothing like pkg-config to give proper headers paths

@embeddedt

This comment has been minimized.

Copy link

commented on ports/javascript/Makefile in 4ef776d Jul 7, 2019

On lv_micropython you also defined a CPP macro, right?

@dpgeorge

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

@pmp-p I see you made some more additions. Is this good to go in?

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

@dpgeorge i succeed to build micropython+lvgl based on those options, so i think it's quite ok for a start.

Still there's the problem to get something readable for user mods flags but that can come later, as @embeddedt is working actively on that too. i think later settings CPPFLAGS and calling embuild from an emsripten.mk ( ie could be cheerp.mk there's not only emscripten around ) , as it is very compiler specific will be next step.

@embeddedt the __CPP__ macro was for testing purposes, i don't think it would be required for normal use

@embeddedt

This comment has been minimized.

Copy link

commented Jul 8, 2019

@dpgeorge

Is this good to go in?

At the moment, sadly, I see little choice but to merge this, even though it's quite non-portable (i.e. assumes that the cache is in ~/.emscripten_cache and that ports are built).

I'm thinking that someone should raise an issue on the Emscripten end at some point to point out this flaw with emcc. Ideally we shouldn't need to invoke clang directly at all.

@pmp-p

@embeddedt is working actively on that too

I am?

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

@embeddedt , sorry maybe i mistook some comments but i had vaguely the idea that you would have integrated LittleVGL as a module via the user mod build system if it wasn't for the root pointer problem.

@embeddedt

This comment has been minimized.

Copy link

commented Jul 8, 2019

@pmp-p You would have to discuss that with @amirgon - I wasn't the one who implemented LittlevGL's integration in the first place. I'm just making it work with JavaScript/Emscripten.

CPP += -D__EMSCRIPTEN__
CPP += --sysroot $(EMSCRIPTEN)/system
CPP += -isystem $(EMSCRIPTEN)/system/include/libc
CPP += -cxx-isystem $(EMSCRIPTEN)/system/include/libcxx

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 8, 2019

@dpgeorge @pmp-p

I've finally discovered that there is a slightly better way of handling these :

CPP += $(addprefix -isystem, $(shell $(CC) -E -x c++ /dev/null -v 2>&1 |sed -e '/^\#include <...>/,/^End of search/{ //!b };d'))

By parsing the verbose output of emcc it's possible to retrieve the include paths.

This still doesn't bring in all of the predefined macros, but it's a start.

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 8, 2019

Author Contributor

Very nice ! i like that it's a very complete output,

@embeddedt one thing though : it seems SDL include folder looks like a -s USE_SDL=1 (1.3.0) instead of a 2

also maybe add LC_ALL=C just in case End of search gets a localized version ?

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 8, 2019

To fix the first issue I think the JSFLAGS line should be moved above CC = emcc -g4 and the second issue can be fixed by changing the line to this:

$(addprefix -isystem, $(shell env LC_ALL=C $(CC) -E -x c++ /dev/null -v 2>&1 |sed -e '/^\#include <...>/,/^End of search/{ //!b };d'))

In fact this brings in .emscripten_cache automatically so the hack on lv_micropython should no longer be necessary (testing now).

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 8, 2019

Confirmed that the hack is not needed.

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 8, 2019

Author Contributor

it works very well when adding specific -s USE_flags that are normally in CFLAGS but should not be passed to clang -E.

i see a reason for user mod to have separate CFLAGS and CPPFLAGS
or some more magic in the makefile to remove the -s * pattern from the user mod flags ?

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 8, 2019

What is the problem? It is compiling fine without any errors about unknown options.

The idea is to generate QSTR with as identical parameters as possible to what emcc actually compiles with.

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 8, 2019

Author Contributor

@embeddedt you're right, i missed that user flags include will get translated to -isystem ones too

i'll try to enhance that PR for user mod system !

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 9, 2019

Ideally we also want to pass proper predefined macros to clang as well; I'm working on another one of these parsing hacks that should do that. That way we can avoid this ugliness (which will fall apart on a different architecture):

https://github.com/littlevgl/lv_micropython/blob/1381be71fb2f11c6e0841b2beebf1f3aa84bcba2/ports/javascript/Makefile#L26

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 9, 2019

Alright, I can now pass macros to clang; see my latest comments on the Makefile (near CPP = clang -E).

embeddedt added a commit to littlevgl/lv_micropython that referenced this pull request Jul 8, 2019

@@ -16,7 +16,10 @@ INC += -I$(BUILD)
CPP = clang -E

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 9, 2019

To pass macros manually this needs to be:

Suggested change
CPP = clang -E
CPP = clang -E -undef

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 9, 2019

For some reason, GitHub refuses to let me comment on the remaining lines of the file.

-SRC_QSTR += $(SRC_C)
+SRC_QSTR += $(BUILD)/clang_predefs.h $(SRC_C)
+
+$(BUILD)/clang_predefs.h:
+       @emcc $(JSFLAGS) -E -x c /dev/null -dM > $@
get includes via idea of @embeddedt
imho good start, as it can be upgraded later to support user mods requirements.
And is far better than stopping build on GNU/Linux systems.

Though i'm not sure that solution will work on some emsdk platforms if they lack decent shell.

Somebody would need to test mac/win
CPP += --sysroot $(EMSCRIPTEN)/system
CPP += $(addprefix -isystem, $(shell env LC_ALL=C $(CC) $(CFLAGS_EXTRA) -E -x c++ /dev/null -v 2>&1 |sed -e '/^\#include <...>/,/^End of search/{ //!b };d'))
# Act like 'emcc'
CPP += -U__i386 -U__i386 -Ui386 -U__SSE -U__SSE_MATH -U__SSE2 -U__SSE2_MATH -U__MMX__ -U__SSE__ -U__SSE_MATH__ -U__SSE2__ -U__SSE2_MATH__

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 19, 2019

The manual undefining of macros should be replaced by the trick I described here: #4875 (review)

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 19, 2019

Author Contributor

@embeddedt maybe push the all the tricks at once first here https://github.com/littlevgl/lv_micropython/blob/pmpp_test/ports/javascript/Makefile so i can try them with child modules ?

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 20, 2019

They were already there: littlevgl@3bd1eab

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 21, 2019

Author Contributor

iirc i tried those but i had a problem with macro redef, but adding -Wno-macro-redefined to $(CPP) seems to fix it

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 21, 2019

Disabling that warning is not necessarily a good solution to the problem (it might just hide it). What macros are you getting the warning on?

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 21, 2019

CPP has to be clang -E -undef.

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 21, 2019

Author Contributor

indeed, seems better

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 21, 2019

Author Contributor

hmm on my port i get that with -undef , while -Wno-macro-redefined pass the build

../../extmod/moductypes.c:747:19: error: use of undeclared identifier 'MP_QSTR_SHORT'
    { MP_ROM_QSTR(MP_QSTR_SHORT), MP_ROM_INT(TYPE2SMALLINT(INT16, 4)) },
                  ^
../../extmod/moductypes.c:748:19: error: use of undeclared identifier 'MP_QSTR_USHORT'
    { MP_ROM_QSTR(MP_QSTR_USHORT), MP_ROM_INT(TYPE2SMALLINT(UINT16, 4)) },
                  ^
../../extmod/moductypes.c:751:19: error: use of undeclared identifier 'MP_QSTR_INT'; did you mean 'MP_QSTR_INT8'?
    { MP_ROM_QSTR(MP_QSTR_INT), MP_ROM_INT(TYPE2SMALLINT(INT32, 4)) },
                  ^~~~~~~~~~~
                  MP_QSTR_INT8
../../py/obj.h:248:40: note: expanded from macro 'MP_ROM_QSTR'
#define MP_ROM_QSTR(q) MP_OBJ_NEW_QSTR(q)
                                       ^
../../py/obj.h:92:56: note: expanded from macro 'MP_OBJ_NEW_QSTR'
#define MP_OBJ_NEW_QSTR(qst) ((mp_obj_t)((((mp_uint_t)(qst)) << 2) | 2))
                                                       ^
build/genhdr/qstrdefs.generated.h:297:6: note: 'MP_QSTR_INT8' declared here
QDEF(MP_QSTR_INT8, (const byte*)"\xce\x04" "INT8")
     ^
../../extmod/moductypes.c:752:19: error: use of undeclared identifier 'MP_QSTR_UINT'; did you mean 'MP_QSTR_UINT8'?
    { MP_ROM_QSTR(MP_QSTR_UINT), MP_ROM_INT(TYPE2SMALLINT(UINT32, 4)) },
                  ^~~~~~~~~~~~
                  MP_QSTR_UINT8
../../py/obj.h:248:40: note: expanded from macro 'MP_ROM_QSTR'
#define MP_ROM_QSTR(q) MP_OBJ_NEW_QSTR(q)
                                       ^
../../py/obj.h:92:56: note: expanded from macro 'MP_OBJ_NEW_QSTR'
#define MP_OBJ_NEW_QSTR(qst) ((mp_obj_t)((((mp_uint_t)(qst)) << 2) | 2))
                                                       ^
build/genhdr/qstrdefs.generated.h:309:6: note: 'MP_QSTR_UINT8' declared here
QDEF(MP_QSTR_UINT8, (const byte*)"\xbb\x05" "UINT8")
     ^
../../extmod/moductypes.c:755:19: error: use of undeclared identifier 'MP_QSTR_LONG'; did you mean 'MP_QSTR_VOID'?
    { MP_ROM_QSTR(MP_QSTR_LONG), MP_ROM_INT(TYPE2SMALLINT(INT32, 4)) },
                  ^~~~~~~~~~~~
                  MP_QSTR_VOID
../../py/obj.h:248:40: note: expanded from macro 'MP_ROM_QSTR'
#define MP_ROM_QSTR(q) MP_OBJ_NEW_QSTR(q)
                                       ^
../../py/obj.h:92:56: note: expanded from macro 'MP_OBJ_NEW_QSTR'
#define MP_OBJ_NEW_QSTR(qst) ((mp_obj_t)((((mp_uint_t)(qst)) << 2) | 2))
                                                       ^
build/genhdr/qstrdefs.generated.h:310:6: note: 'MP_QSTR_VOID' declared here
QDEF(MP_QSTR_VOID, (const byte*)"\x31\x04" "VOID")
     ^
../../extmod/moductypes.c:756:19: error: use of undeclared identifier 'MP_QSTR_ULONG'
    { MP_ROM_QSTR(MP_QSTR_ULONG), MP_ROM_INT(TYPE2SMALLINT(UINT32, 4)) },
                  ^
../../extmod/moductypes.c:762:19: error: use of undeclared identifier 'MP_QSTR_LONGLONG'
    { MP_ROM_QSTR(MP_QSTR_LONGLONG), MP_ROM_INT(TYPE2SMALLINT(INT64, 4)) },
                  ^
../../extmod/moductypes.c:763:19: error: use of undeclared identifier 'MP_QSTR_ULONGLONG'; did you mean
      'MP_QSTR_ENOTCONN'?
    { MP_ROM_QSTR(MP_QSTR_ULONGLONG), MP_ROM_INT(TYPE2SMALLINT(UINT64, 4)) },
                  ^~~~~~~~~~~~~~~~~
                  MP_QSTR_ENOTCONN
../../py/obj.h:248:40: note: expanded from macro 'MP_ROM_QSTR'
#define MP_ROM_QSTR(q) MP_OBJ_NEW_QSTR(q)
                                       ^
../../py/obj.h:92:56: note: expanded from macro 'MP_OBJ_NEW_QSTR'
#define MP_OBJ_NEW_QSTR(qst) ((mp_obj_t)((((mp_uint_t)(qst)) << 2) | 2))
                                                       ^
build/genhdr/qstrdefs.generated.h:287:6: note: 'MP_QSTR_ENOTCONN' declared here
QDEF(MP_QSTR_ENOTCONN, (const byte*)"\x79\x08" "ENOTCONN")
     ^
../../extmod/moductypes.c:771:8: error: invalid application of 'sizeof' to an incomplete type
      'const mp_rom_map_elem_t []'
STATIC MP_DEFINE_CONST_DICT(mp_module_uctypes_globals, mp_module_uctypes_globals_table);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../py/obj.h:314:21: note: expanded from macro 'MP_DEFINE_CONST_DICT'
            .used = MP_ARRAY_SIZE(table_name), \
                    ^~~~~~~~~~~~~~~~~~~~~~~~~
../../py/misc.h:111:33: note: expanded from macro 'MP_ARRAY_SIZE'
#define MP_ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
                                ^~~
../../extmod/moductypes.c:771:8: error: invalid application of 'sizeof' to an incomplete type
      'const mp_rom_map_elem_t []'
STATIC MP_DEFINE_CONST_DICT(mp_module_uctypes_globals, mp_module_uctypes_globals_table);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../py/obj.h:315:22: note: expanded from macro 'MP_DEFINE_CONST_DICT'
            .alloc = MP_ARRAY_SIZE(table_name), \
                     ^~~~~~~~~~~~~~~~~~~~~~~~~
../../py/misc.h:111:33: note: expanded from macro 'MP_ARRAY_SIZE'
#define MP_ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
                                ^~~
10 errors generated.
shared:ERROR: compiler frontend failed to generate LLVM bitcode, halting
../../py/mkrules.mk:47: recipe for target 'build/extmod/moductypes.o' failed
make: *** [build/extmod/moductypes.o] Error 1

This comment has been minimized.

Copy link
@embeddedt

embeddedt Jul 21, 2019

-Wno-macro-redefined is just hiding the issue because we don't want any predefined macros coming from clang.

Can you clean and rebuild?

This comment has been minimized.

Copy link
@pmp-p

pmp-p Jul 21, 2019

Author Contributor

my clang was missing some macro cleared by -undef eg __SIZEOF_SHORT__, but -include $(BUILD)/clang_predefs.h can re add them.

@embeddedt

This comment has been minimized.

Copy link

commented on d07dbff Jul 19, 2019

It definitely won't work on stock Windows without modification because sed isn't installed, and it uses a redirect (2>&1). But who uses cmd to run make anyways?

pmp-p added some commits Jul 21, 2019

@embeddedt

This comment has been minimized.

Copy link

commented Jul 22, 2019

@pmp-p I have two questions:

  • Why is the else clause necessary on the ifdef EMSCRIPTEN clause? I don't see a case where someone would want to compile the JavaScript port without Emscripten. If anything I would think that that should produce an error with something like $(error Cannot find Emscripten SDK) rather than choosing the host clang or gcc.
  • Is the ASYNC part of the Makefile relevant to this PR?

Also, reading through [past comments]((#4875 (comment)):

sadly there's nothing like pkg-config to give proper headers paths

Hypothetically, we could abuse my hack still further, and check the delta between the include paths that emcc spits out:

$ emcc -x c++ -E -v
<stuff>
$ emcc -s USE_SDL=2 -x c++ -E -V
<stuff> -I/home/user/.emscripten_cache/ports/sdl2/include

But that might be overkill.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Jul 22, 2019

Primary goal of this PR is to have a decent building process for people with user modules. and prevent emscripten from doing stupid things not in one but in all its use case :

  1. emscripten can be used or not.
  • There's not only emscripten available around for compiling to asm.js or wasm.
  • Compiling to native/cross the javascript port can help testing code validity for other ports and that the emscripten specific blocks are correcly isolated via ifdef so it should be possible to use plain gcc or clang to build.
  1. if emscripten is used, it can be used async or not.
  • async is relevant - even if crippled on purpose here - because it can help some people stuck with some issues already open around. emterpreter can't be Ignored but I certainly would not open a PR for that because i think it's not a solution, i don't even want to advertise it because it prevents people from searching solutions and upstream them (or at least try to).

Of course anyone can feel free to remove any feature or put comments in front, or reject the whole PR because it's GNU/Linux or mac only,
But i don't think javascript port has any future if it stays crippled or uncared for ( once heat wave is passed you won't see me for a while ).

But that might be overkill.

emscripten is imho difficult, anything that can ease porting code would be welcome for people who would like to try in order to demonstrate their work.

embeddedt and others added some commits Jul 28, 2019

Merge pull request #1 from embeddedt/patch-1
Ensure `clang_predefs.h` is included in QSTR extraction
@embeddedt

This comment has been minimized.

Copy link

commented Jul 31, 2019

@dpgeorge I think this one is ready to be merged. We've been using it for quite a while on lv_micropython and I haven't seen any new issues.

@dpgeorge

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

I think this one is ready to be merged.

Ok, but it has changed a lot (added a lot) since the first review and seems now to do a few unrelated things. So I'll need to rereview it in detail.

@embeddedt

This comment has been minimized.

Copy link

commented Jul 31, 2019

Ok, but it has changed a lot (added a lot) since the first review and seems now to do a few unrelated things. So I'll need to rereview it in detail.

That's fine.

The new stuff essentially extracts the Emscripten predefined macros and include paths automatically and passes them to clang instead of the previous method where we had to use hardcoded include paths.

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Aug 7, 2019

meanwhile a problem arose with the new upstreaming emscripten branch

emsdk install 1.38.40-upstream
emsdk activate 1.38.40-upstream

will lead to

CC main.c
CC mphalport.c
CC modutime.c
LINK build/firmware.js
shared:ERROR: BINARYEN_TRAP_MODE is not supported by the LLVM wasm backend
Makefile:59: recipe for target 'build/micropython.js' failed
make: *** [build/micropython.js] Error 1

in addition the LDFLAG -Wl,-Map=$@.map,--cref -Wl,--gc-sections is unsupported by clang 10 wasm-ld linker.

the difference beetween both fastcomp and upstream branch can be detected from EMMAKEN_COMPILER EMSCRIPTEN_TOOL EMSCRIPTEN env vars since /fastcomp/ becomes /upstream/ in them

also a new option made it in emscripten for coroutines with a lot less performance loss than emterpreting see https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html

@embeddedt

This comment has been minimized.

Copy link

commented Aug 7, 2019

meanwhile a problem arose with the new upstreaming emscripten branch

Cursory research suggests that this shouldn't be (too) difficult to fix. I'll have a look.

in addition the LDFLAG -Wl,-Map=$@.map,--cref -Wl,--gc-sections is unsupported by clang 10 wasm-ld linker.

This is just for generating binary maps and doesn't affect the compiled output at all, so it can safely be removed or replaced with the correct flags.

#check if not using emscripten-upstream branch
ifeq (,$(findstring upstream/bin, $(EMMAKEN_COMPILER)))
JSFLAGS += -s "BINARYEN_TRAP_MODE='clamp'"
LDFLAGS = -m32 -Wl,-Map=$@.map,--cref -Wl,--gc-sections

This comment has been minimized.

Copy link
@embeddedt

embeddedt Aug 7, 2019

Why not += on LDFLAGS in order to pick up the -m32 from line 18?

@pmp-p

This comment has been minimized.

Copy link
Contributor Author

commented Aug 7, 2019

@embeddedt , removing seems ok, please have a look

pmp-p and others added some commits Aug 7, 2019

Merge pull request #2 from littlevgl/pmpp_6_fix
Fix issues with Makefile
add shared so emscripten people have a look at setjmp error
```emmake make SHARED=1```
should lead to
```Fatal: GOT.func entry with no import/export: $emscripten_longjmp_jmpbuf```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.