sandstorm

sandstorm copied to clipboard

Hi team,

When cloning from head, Sandstorm currently is failing to build for me. I installed all the dependencies recommended for Fedora in the docs.

Here's the (long) stdout buffer from my console when building it (with some warnings printed since I had -Wall set). The more interesting bits are here:

Ending the make process is this error about failing to build compile: node-capnp/capnp.cc because it can't find node.h:

✔ test: capnp/fuzz-test
✘ compile: node-capnp/capnp.cc
    /ekam-provider/canonical/node-capnp/capnp.cc:29:10: fatal error: 'node.h' file not found
    #include <node.h>
             ^~~~~~~~
    1 error generated.
✘ install: node-capnp/node-capnp.ekam-manifest
    node-capnp/capnp.node: not found
✘ jstest: node-capnp/capnp-test.js
    full log: tmp/node-capnp/capnp-test.js.log
make: *** [Makefile:269: tmp/.ekam-run] Error 1

I do have nodejs-devel installed via DNF, but using mlocate, I can't seem to find node.h.

The log file mentioned in the error above is here; it's brief.

Earlier when linking, I get some DWARF errors from ld:

  link: sandstorm/sandstorm-http-bridge.o
    /usr/bin/ld: /usr/bin/ld: DWARF error: could not find variable specification at offset 613
    /usr/bin/ld: DWARF error: could not find variable specification at offset 14d1
       [ ...repeated a bunch of times for a bunch of offsets... ]
    /usr/bin/ld: DWARF error: could not find variable specification at offset 5451
    ...(log truncated; use -l to increase log limit)...
  install: sandstorm/sandstorm.ekam-manifest
✔ test: sandstorm/util-test

If it helps, I'm running Fedora 34 with:

> uname -a
Linux catbox 5.15.4-101.fc34.x86_64 #1 SMP Tue Nov 23 18:58:50 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

> node --version
v17.1.0

> gcc --version
gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)
[...copyright info...]

> clang --version
clang version 12.0.1 (Fedora 12.0.1-1.fc34)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

> git log -n 1
commit c0dca1064106ece86adc174f457bb9b6b66cabb4 (HEAD -> master, origin/master, origin/HEAD)
Merge: a8f6075f ea1e3ded
Author: Jacob Weisz <[email protected]>
Date:   Mon Nov 22 11:07:35 2021 -0600
[...commit msg...]

Please let me know if you have any ideas! I'll keep poking at it and post here if I work things out.

Are you sure you're building the latest master? We were seeing this in CI, but #3576 and #3588 (merged less than a week ago) should have fixed it. Note that you may have to do the meteor install again if you previously installed 1.8.2 as the (now changed) instructions indicated prior to that patch.

Hi @zenhack , just double-checked, can confirm that I'm on commit c0dca1064106ece86adc174f457bb9b6b66cabb4 with #3588 merged.

[23:18:50] cat@ /home/cat/src_/sandstorm  
> git log -n 1
commit c0dca1064106ece86adc174f457bb9b6b66cabb4 (HEAD -> master, origin/master, origin/HEAD)
Merge: a8f6075f ea1e3ded
Author: Jacob Weisz <[email protected]>
Date:   Mon Nov 22 11:07:35 2021 -0600

    Merge pull request #3588 from zenhack/install-current-meteor
    
    Stop installing a very old version of meteor

Likewise, it looks like I'm using Meteor 2.5.1:

[23:19:57] cat@ /home/cat/src_/sandstorm  
> ~/.meteor/meteor --version
Meteor 2.5.1

Hm. What happens if you run ./find-meteor-dev-bundle.sh? It should print out a path to the meteor dev bundle, with node.h found under include/node within that.

Quoting Cat Lee Ball (2021-11-28 02:22:21)

Hi @.*** , just double-checked, can confirm that I'm on commit [2]c0dca10 with [3]#3588 merged. [23:18:50] cat@ /home/cat/src_/sandstorm

git log -n 1 commit c0dca1064106ece86adc174f457bb9b6b66cabb4 (HEAD -> master, origin/master, origin/HEAD) Merge: a8f6075f ea1e3ded Author: Jacob Weisz @.***> Date: Mon Nov 22 11:07:35 2021 -0600

Merge pull request #3588 from zenhack/install-current-meteor

Stop installing a very old version of meteor

Likewise, it looks like I'm using Meteor 2.5.1: [23:19:57] cat@ /home/cat/src_/sandstorm

~/.meteor/meteor --version Meteor 2.5.1

-- You are receiving this because you were mentioned. Reply to this email directly, [4]view it on GitHub, or [5]unsubscribe. Triage notifications on the go with GitHub Mobile for [6]iOS or [7]Android.

Verweise

1. https://github.com/zenhack
2. https://github.com/sandstorm-io/sandstorm/commit/c0dca1064106ece86adc174f457bb9b6b66cabb4
3. https://github.com/sandstorm-io/sandstorm/pull/3588
4. https://github.com/sandstorm-io/sandstorm/issues/3590#issuecomment-980881595
5. https://github.com/notifications/unsubscribe-auth/AAGXYPSFLMNSAQGCKC4BP5TUOHKC3ANCNFSM5I45TIOA
6. https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
7. https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

As a data point, I am able to successfully compile the latest master on Fedora using the same Dockerfile that worked a few months ago, except now I have removed ?release=1.8.2 from the meteor install line.

That said, in my experience the business of finding of node.h can be finicky. As you'll notice in that Dockerfile, I have had to explicitly install meteor as a regular user, not root, to avoid that error. (It doesn't look like this, precisely, is your problem, though.)

@zenhack Hm. What happens if you run ./find-meteor-dev-bundle.sh? It should print out a path to the meteor dev bundle, with node.h found under include/node within that.

Oh! It seems that meteor isn't in my path, but only according to Fish shell. Bash seems aware of it with an out-of-the-box meteor installation:

> ./find-meteor-dev-bundle.sh 
Finding meteor-tool installation (can take a few seconds)..../find-meteor-dev-bundle.sh: line 56: meteor: command not found

$ ./find-meteor-dev-bundle.sh 
Finding meteor-tool installation (can take a few seconds)... [email protected]
/home/cat/.meteor/packages/meteor-tool/.2.3.5.1fimhsq.2t2l++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle

So I built it from inside a bash shell to see what would happen, and it failed at the same test, but without any output. Full console output here.

$ make clean
[...]
$ make
[...]
✔ test: capnp/fuzz-test
✘ jstest: node-capnp/capnp-test.js
make: *** [Makefile:269: tmp/.ekam-run] Error 1

$ echo $?
2

Then I checked the log file for the capnp-test.js.log and found it has a different error this time regarding path not found:

[cat@catbox sandstorm]$ cat tmp/node-capnp/capnp-test.js.log 
/mnt/hdd/cat/src/sandstorm/node-capnp/capnp.js:80
  module.exports = v8capnp.import(filename, filename, importPath);
                                 ^

Error: no such directory; path = mnt/hdd/cat/src/sandstorm/node-capnp/test.capnp
    at Object.require.extensions..capnp (/mnt/hdd/cat/src/sandstorm/node-capnp/capnp.js:80:34)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)
    at Module.require (internal/modules/cjs/loader.js:961:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at Object.<anonymous> (/mnt/hdd/cat/src/sandstorm/node-capnp/capnp-test.js:45:12)
    at Module._compile (internal/modules/cjs/loader.js:1072:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12) {
  cppFile: 'kj/filesystem.c++',
  line: 551,
  kjType: 'failed'
}

And it's true that node-capnp doesn't exist in my sandstorm source directory, at least after the build fails.

I'm imagining something is weird with my meteor install, or something else weird in my environment. I'll keep poking around and try reinstalling meteor. Let me know if any of you have ideas!

---

---

@garrison As a data point, I am able to successfully compile the latest master on Fedora using the same Dockerfile that worked a few months ago, except now I have removed ?release=1.8.2 from the meteor install line.

That said, in my experience the business of finding of node.h can be finicky. As you'll notice in that Dockerfile, I have had to explicitly install meteor as a regular user, not root, to avoid that error. (It doesn't look like this, precisely, is your problem, though.)

That's a good note! Maybe even more confusingly, when I ran the same dockerfile you linked, it failed to complete the build on a different step (full console output):

> docker build - < Dockerfile
[...]
Fetching sandstorm-171.tar.xz to extract a mongo 2.6...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 21.8M  100 21.8M    0     0  12.9M      0  0:00:01  0:00:01 --:--:-- 12.9M
hack/sandstorm-171.tar.xz: OK
	not a dynamic executable
[...repeated a bunch...]
	not a dynamic executable
make-bundle.sh: FAILED at line 180
make: *** [Makefile:380: bundle] Error 1
Error: error building at STEP "RUN make fast": error while running runtime: exit status 2
⏎   

I was originally thinking I just had a weird or broken environment, but it's super weird for the dockerfile to be unable to build on my machine! I'm a little clueless how that's breaking on my machine- if you have debugging tips, please let me know!

Also, I don't want to waste your cycles here! It's valid to simply say to me "your environment is extremely broken". However, if you think these symptoms indicate a bug that needs triage, I'm happy to continue debugging this with you all. :)

when I ran the same dockerfile you linked, it failed to complete the build on a different step

Line 180 runs strace. My guess is that it fails because you are using an older version of Docker than me.

Oh, I got it to build successfully! It seems that it may have been symlink being handled badly.

I have a symlink /home/cat/src_ that points to /mnt/hdd/cat/src. In the failing builds I entered the source directory with cd ~/src_/sandstorm, but when I enter the directory using cd /mnt/hdd/cat/src/sandstorm it builds correctly.

What made me think of this: Looking at the capnp-test.js.log with the directory not found error from my previous comment Error: no such directory; path = mnt/hdd/cat/src/sandstorm/node-capnp/test.capnp I was a little puzzled there was no leading slash.

I haven't tracked where in the source this is handled, but I'm imagining something is building a relative path based on the output of pwd or similar (since pwd will print the path as you traversed it, including the symlink dir), and is maybe being inconsistent with path handling elsewhere.

---

---

@garrison : You're right! It turns out I'm using Podman. Adding --cap-add=SYS_PTRACE allowed to to build in docker successfully.

> docker --version
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
podman version 3.4.2

Awesome. Do we feel there's any action items here, or is this user-specific enough that we can mark it resolved?

It would be nice if Sandstorm could be built from a directory that is resolved via a symlink. If this can be reliably reproduced, then I think it should be fixed.

If it is not easy to fix, then it could instead be documented that such an arrangement is expected to fail.

I am always in favor of making the build system more robust if it's easy enough, though I can't say I'm likely to prioritize hunting this down in the immediate future. If we decide to let this sit then it would indeed be good to add a thing to the docs.

It is possible this is an ekam issue, in which case a reproducer that's simpler than all of sandstorm might be worth trying to construct.

The missing leading slash is indeed a bit odd. @kentonv, any guesses as to what exactly might be happening there?

I am able to reproduce, but the error I get is the same as the one you originally linked in the top-most post (error on line 42 of capnp.js, rather than line 80).

This occurs when the path contains either an absolute or relative symlink, i.e., when building within either tmp1 or tmp2 with the following directory layout:

garrison:~$ ls -l tmp1 tmp2
lrwxrwxrwx. 1 garrison garrison 10 Nov 29 18:53 tmp1 -> tmp1-real/
lrwxrwxrwx. 1 garrison garrison 24 Nov 29 18:53 tmp2 -> /home/garrison/tmp2-real

garrison:~$ ls tmp1/ tmp2/
tmp1/:
sandstorm

tmp2/:
sandstorm

@catleeball If you do manage to track down what causes this error, feel free to submit a pull request.