Skip to content

Conversation

@E100Beta
Copy link

@E100Beta E100Beta commented Nov 5, 2017

I suspect you package non-statically compiled Node, so it doesn't work on systems which don't have glibc, e.g. Voidlinux.
This causes $id to be an empty variable.
This means rm -r ~/.config/.
Yep, I just deleted my entire ~/.config directory by running your script.

You package non-statically compiled Node, so it doesn't work on systems which don't have glibc, e.g. Voidlinux.
This causes $id to be an empty variable.
This means `rm -r ~/.config/`.
Yep, I just deleted my entire ~/.config directory by running your script.
@E100Beta
Copy link
Author

E100Beta commented Nov 5, 2017

Thankfully I had a backup from two weeks ago, so I only need to bring some configs up to speed.
I didn't really think of what a correct way to avoid the issue would be, only worked around the most dangerous command.

The best way to go would be to just compile Node statically, with glibc built into binary. This would avoid the issue altogether.
Another way is to check if node is launching, and if not, aborting with an error.

@belaviyo
Copy link
Owner

belaviyo commented Nov 5, 2017

I suspect you package non-statically compiled Node

I am using the official releases -> Linux Binaries (x86/x64); https://nodejs.org/en/download/current/

@E100Beta
Copy link
Author

E100Beta commented Nov 5, 2017

Looking through the ldd output:

        /lib64/ld-linux-x86-64.so.2 (0x7fa5dd8b8000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fa5dd8b8000)
        librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7fa5dd8b8000)
        libstdc++.so.6 => /lib/libstdc++.so.6 (0x7fa5dd49f000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fa5dd8b8000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fa5dd289000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fa5dd8b8000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fa5dd8b8000)
Error relocating node: __isinf: symbol not found
Error relocating node: __isnan: symbol not found
Error relocating node: __strtod_internal: symbol not found
Error relocating node: backtrace: symbol not found

It searches for a linker in /lib64 folder, which doesn't exist on musl-based 64bit distributions.

So it's probably Node's fault, they didn't think about niche audience :)

So this script should probably just do what install.sh does and check for local node.js (I had local nodejs installed), but both scripts should probably try to detect non-glibc systems.

One way I found, but I am not sure if it's totally correct, is to look for ldd output:

ldd 2>&1 | grep GNU

ldd is actually a symlink to /usr/lib/libc.so, so it should be on any Linux system.
So something like:

if [ -z "$(ldd 2>&1 | grep GNU)" ]; then
    printf "Non-glibc system, bundled Node probably won't work\n" >&2
    exit 1
fi

Shoul work.

@belaviyo belaviyo merged commit a2a481c into belaviyo:master Nov 5, 2017
@belaviyo
Copy link
Owner

belaviyo commented Nov 5, 2017

I am really sorry about this. Thanks for the fix.

@belaviyo
Copy link
Owner

belaviyo commented Nov 5, 2017

Right, I guess using the native NodeJS should be the first option. how about having something like this:

MACHINE_TYPE=`uname -m`

which node 2>/dev/null
isNode=$?
echo NodeJS status = $isNode

if [ ${isNode} -eq 0 ]; then
  echo "Using system NodeJS"
  id=`node -e "process.stdout.write(require('./config.js').id)"`
elif [ ${MACHINE_TYPE} == 'x86_64' ]; then
  echo "Using ../node/x64/node"
  id=`../node/x64/node -e "process.stdout.write(require('./config.js').id)"`
else
  echo "Using ../node/x86/node"
  id=`../node/x86/node -e "process.stdout.write(require('./config.js').id)"`
fi

@E100Beta
Copy link
Author

E100Beta commented Nov 5, 2017

Yeah, looks fine 👍
And I just finished restoring my configs, so yay, damage undone and future damage hopefully prevented :)

@belaviyo
Copy link
Owner

belaviyo commented Nov 5, 2017

Perfect.

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

Successfully merging this pull request may close these issues.

2 participants