The compiler does not work on Linux-x64

[cyparu]

The v1.49.9 compiler blocks on Linux-x64 (while working fine on Windoes & Mac).

• --version shows the Dart SDK version: 2.16.1 (stable) (Tue Feb 8 12:02:33 2022 +0100) on "linux_x64" instead of compiler info
  • { "protocolVersion": "1.0.0", "compilerVersion": "1.49.9", "implementationVersion": "1.49.9", "implementationName": "Dart Sass", "id": 0 }
• I suspect the problem related to the new self-consistent packaging (possible related issue: Inconsistent packaging of linux-x64 in version 1.0.0-beta.7 #38 )

Simple test:

const sass = require('sass-embedded');
const result = sass.compile("test.scss"); // blocks here
console.log(result)

[johnfairh]

Just as a data point, I see the 1.49.9 dart-sass-embedded working fine for my (Swift) host on all the macOS and IA64 Linux systems I have to test on. I also don't see any problems with the --version output. Maybe better to raise your problem on Stackoverflow or the JS host project.

[cyparu]

Just as a data point, I see the 1.49.9 dart-sass-embedded working fine for my (Swift) host on all the macOS and IA64 Linux systems I have to test on. I also don't see any problems with the --version output. Maybe better to raise your problem on Stackoverflow or the JS host project.

Interestingly enough , on my Linux x64 system ,the behavior is different, so the issue relate to the Linux x64 binary, and is not related to the host/wrapper :

1 / executing ./dart-sass-embedded --version will output Dart SDK version: 2.16.1 (stable) (Tue Feb 8 12:02:33 2022 +0100)

2 / executing ./dart-sass-embedded will output the Dart SDK help, instead of waiting for the sysin commands

[nex3]

I'm on Linux x64, and I can't reproduce this:

$ wget https://github.com/sass/dart-sass-embedded/releases/download/1.49.9/sass_embedded-1.49.9-linux-x64.tar.gz
$ tar xzf sass_embedded-1.49.9-linux-x64.tar.gz 
$ ./sass_embedded/dart-sass-embedded --version
{
  "protocolVersion": "1.0.0",
  "compilerVersion": "1.49.9",
  "implementationVersion": "1.49.9",
  "implementationName": "Dart Sass",
  "id": 0
}

How did you download/install the executable?

[ntkme]

This can be reproduced by explicitly invoking dart-sass-embedded via ld-linux:

(ruby)root@78b24c21807a:/home/opc# /usr/local/bin/dart-sass-embedded --version
{
  "protocolVersion": "1.2.0",
  "compilerVersion": "1.57.1",
  "implementationVersion": "1.57.1",
  "implementationName": "Dart Sass",
  "id": 0
}
(ruby)root@78b24c21807a:/home/opc# /lib/ld-linux-aarch64.so.1 /usr/local/bin/dart-sass-embedded --version
Dart SDK version: 2.18.6 (stable) (Tue Dec 13 21:15:14 2022 +0000) on "linux_arm64"

Use patchelf to patch the interpreter path seems to cause the same issue as well.

[anna328p]

so far, i've figured out the following:

• dart standalone executables consist of an ELF image containing the runtime, with a snapshot containing the compiled code appended onto the end. there is a 16-byte footer (internally called an "appended header"???) the first 8 bytes are a little-endian uint64 containing the offset into the file at which the snapshot is located, the next 8 bytes are the magic value [0xdc, 0xdc, 0xf6, 0xf6, 0, 0, 0, 0].
• to locate the executable, dart's runtime calls readlink on /proc/self/exe. it then opens that file, seeks to the end of the file minus 16 bytes, reads two uint64_t values, ensures the first is little-endian, compares the second to the magic number, and if they match, mmaps the file and adds the offset to the address to get the location of the snapshot in memory.
• this has a few failure modes:
  • /proc/self/exe is not the standalone executable. this happens if you e.g. manually invoke the loader
  • the footer has been damaged, e.g. by patchelf

[ntkme]

Dart SDK issue: dart-lang/sdk#50926

[ntkme]

Before Dart SDK fixes the actual problem, I think for short term we should change the linux releases to have the dartaotruntime and aot-snapshot as two separate files, which avoids the SDK bug.

@nex3 What do you think?

[nex3]

I agree. The relative value of shipping a single executable isn't high enough to justify being confusingly broken on some systems.