emscripten icon indicating copy to clipboard operation
emscripten copied to clipboard

Allow JS files to be executable

Open vicapow opened this issue 1 year ago • 4 comments

Here's a quick comparison of behavior before and after:

Before:

# emcc main.c -o main
# ls -alh main
-rw-r--r-- 1 root root  54K Sep 20 06:41 main # NOTE the missing `x` executable flag

After:

# emcc main.c -o main
# ls -alh main
-rwxr--r-- 1 root root 54K Sep 20 06:37 main

For comparison to gcc:

gcc main.c -o main
# ls -alh main
-rwxr-xr-x 1 root root 9.1K Sep 20 06:42 main

I was noticing some projects I tried to compile to web assembly were failing because they generated intermediary utilities that were then used as part of the build process in later stages. it was non-trivial to modify the original build scripts so this was a way to solve it in my case.

Personally, I think it's better to match the behavior of GCC more closely, in generally, thus the pull request. It looks like a previous workaround for this was added just for conftest.c for automake. see: https://github.com/emscripten-core/emscripten/blob/b435a7c46f38750e6c4490d4c0f726f452b67c82/tools/link.py#L652

Related issue: https://github.com/emscripten-core/emscripten/issues/12707

vicapow avatar Sep 19 '24 21:09 vicapow

I'm generally supportive of this idea. However, I think there are several issues here:

  1. The #! line only works on unix, not on windows
  2. Not all folks will want this the #! line. Perhaps we can works around this by skipping it if folks don't include node in -sENVIRONMENT?
  3. If the goal is to actually run the build-time binaries, I'm not sure that will work. For example, by default, unless you also add NODDERAWFS then the program won't have any access the host filesystem, likely making it useless. It might be better to teach the build system that these intermediate binaries need to be built for the host.
  4. I think there may be some situations in which the #! line doesn't actually work... for example if the program is not in your current working directory. I think this effects pthreaded programs, for example. So we would want to fix that too.

sbc100 avatar Sep 19 '24 23:09 sbc100

One approach I've thought of is that maybe we can infer that a #! is desirable if the output file has no extension at all.

We might also want to make the default output file a.out instead of a.out.js?

sbc100 avatar Sep 19 '24 23:09 sbc100

  1. Good point. Will the presence of it break windows? I don't have a windows computer to try it on.
  2. True. I like your idea of potentially inferring this based on the lack of an extension.
  3. True. For my use case, I also had to add the -sNODERAWFS=1
  4. You mean like this example? It seems to work:
# ./main
Hello, World!
# cd foo/
# ../main
Hello, World!

That all said, maybe an easy, first option, is to add it as a flag? something like --executable

vicapow avatar Sep 20 '24 03:09 vicapow

  1. Good point. Will the presence of it break windows? I don't have a windows computer to try it on.
  2. True. I like your idea of potentially inferring this based on the lack of an extension.
  3. True. For my use case, I also had to add the -sNODERAWFS=1
  4. You mean like this example? It seems to work:
# ./main
Hello, World!
# cd foo/
# ../main
Hello, World!

That all said, maybe an easy, first option, is to add it as a flag? something like --executable

Yes, I agree, exposing some kind of --executable or -sEXECUTABLE might make the most sense.

sbc100 avatar Sep 20 '24 13:09 sbc100