4.7.0-4.7.2 binaries incompatible with CentOS 5 - ELF file OS ABI invalid #2159

ReidBraswell · 2017-11-20T19:03:18Z

Before opening an issue:

Check that the version of node-sass you're trying to install supports your version of Node by looking at the release page for that version https://github.com/sass/node-sass/releases
Read the common workarounds in the TROUBLESHOOTING.md
Search for duplicate or closed issues
Validate that it runs with both Ruby Sass and LibSass
Prepare a reduced test case for any bugs
Read the contributing guidelines

When reporting an bug, you must provide this information:

NPM version (npm -v): 3.10.8
Node version (node -v): 6.9.1
Node Process (node -p process.versions):
Node Platform (node -p process.platform): linux
Node architecture (node -p process.arch): x64
node-sass version (node -p "require('node-sass').info"): 4.7.1
npm node-sass versions (npm ls node-sass):

When encountering a syntax, or compilation issue:

Open an issue on LibSass. You
may link it back here, but any change will be required there, not here

If you delete this text without following it, your issue will be closed.

Below is the output from our Jenkins job:

npm info lifecycle [email protected]~postinstall: [email protected]

> [email protected] postinstall /usr/local/jee/hudson/jobs/workspace/front-end/node_modules/node-sass
> node scripts/build.js

Binary found at /usr/local/jee/hudson/jobs/workspace/front-end/node_modules/node-sass/vendor/linux-x64-48/binding.node
Testing binary
Binary has a problem: Error: /usr/local/jee/hudson/jobs/workspace/front-end/node_modules/node-sass/vendor/linux-x64-48/binding.node: ELF file OS ABI invalid
    at Error (native)
    at Object.Module._extensions..node (module.js:597:18)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at module.exports (/usr/local/jee/hudson/jobs/workspace/front-end/node_modules/node-sass/lib/binding.js:19:10)
    at Object.<anonymous> (/usr/local/jee/hudson/jobs/workspace/front-end/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:570:32)

On Friday, November 17, we ran a build with [email protected] and did not have any issues.

The text was updated successfully, but these errors were encountered:

xzyfer · 2017-11-20T21:17:23Z

Interesting. Out of curiosity, which OS is this?

ghost · 2017-11-20T21:50:29Z

We are facing the same exact issue. Our OS is Red Hat Enterprise Linux Server release 5.11 (Tikanga)

We have switched back to 4.6.1 till this issue is fixed.

xzyfer · 2017-11-21T01:54:51Z

Locking to node-sass@~4.6 will likely work around the issue. Does the issue persist in 4.7.2?

…

On 21 Nov. 2017 8:50 am, "aseem001" ***@***.***> wrote: We are facing the same exact issue. Our OS is Red Hat Enterprise Linux Server release 5.11 (Tikanga) Is there a way around it, like reverting back to 4.6.1? We also did not see this issue when we ran a build with ***@***.*** on Friday, November 17 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2159 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWBk7veEApYSgbsdAnEQggWc0jjDXks5s4fQmgaJpZM4QkvU9> .

thilo-cts · 2017-11-21T09:23:11Z

We are facing the same issue in Red Hat 5.11(Tikanga). Can you please provide a quick solution.Since I can't switch back to older versions of node-sass as it is referring from ember-cli-sass

thilo-cts · 2017-11-21T09:35:58Z

@xzyfer Still we are facing the same issue in 4.7.2.

xzyfer · 2017-11-21T11:47:49Z

We don't understand the problem yet. For now you can add [email protected] in your package.json. npm will install that version even if it's a dependency of another package

…

On 21 Nov. 2017 8:35 pm, "Thilagavathi Indrajit" ***@***.***> wrote: @xzyfer <https://github.com/xzyfer> Still we are facing the same issue in 4.7.2. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2159 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWGayEv0M_qSC7myZPsIGnhz9njstks5s4pl-gaJpZM4QkvU9> .

thilo-cts · 2017-11-21T11:59:25Z

@xzyfer Yes. We have done the same now. it is working.

nschonni · 2017-11-22T06:35:41Z

@xzyfer did you rebuild with the old CentOS 5 machine for the linux binaries? I believe this might be because of the really old libc issues we ran into before

xzyfer · 2017-11-22T06:42:49Z

We've been using CentOS 6 for a while now. I think some of the RPM may have been updated on use though. I had some troubled with the x86 binaries.

nschonni · 2017-11-22T06:46:08Z

OK, related nodejs/build#898 CentOS/RHEL 5 is only valid for Node < 8 since it's EOL, but I guess it should still be working with 6

xzyfer · 2017-11-22T07:17:13Z

@stefanpenner are you able to confirm this with your CentOS setup?

cedricroijakkers · 2017-11-22T08:07:03Z

I can reproduce this issue on the following setup:

RedHat EL 5.9
Node v6.11.2
node-sass versions 4.7.1 and 4.7.2

If you need me to test anything, just let me know. For now, I've rolled back to node-sass 4.6.

xzyfer · 2017-11-22T08:21:50Z

Are you able to reproduce the issue on a newer version of node? I wonder if it's something specific about node 6

…

On 22 Nov. 2017 7:07 pm, "Cedric Roijakkers" ***@***.***> wrote: I can reproduce this issue on the following setup: RedHat EL 5.9 Node v6.11.2 node-sass versions 4.7.1 and 4.7.2 If you need me to test anything, just let me know. For now, I've rolled back to node-sass 4.6. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2159 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWGtvU-6L0r5iTdcH9B3TE8fxsINnks5s49YngaJpZM4QkvU9> .

adarBlack · 2017-11-22T10:36:54Z

Hitting this since Sunday. Using node-sass 4.6 now.

cedricroijakkers · 2017-11-22T12:06:32Z

@xzyfer: Node 8 is not an option on RHEL5, because the C library is not the right version:

node: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.10' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.3' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by node)

stefanpenner · 2017-11-22T20:16:00Z

@stefanpenner are you able to confirm this with your CentOS setup?

I'll take a look. Just a note, My oldest RHEL is 6... I don't have easy access to 5 ATM.

stefanpenner · 2017-11-22T20:22:07Z

node-sass versions 4.7.1 and 4.7.2

@xzyfer on my RHEL6 box, with node 6.9.1 all appears fine:

> [email protected] postinstall /home/spenner/l/<snip>/package
> node scripts/build.js

Binary found at /home/spenner/l/<nip>package/vendor/linux-x64-48/binding.node
Testing binary
Binary is fine

> [email protected] postinstall /home/spenner/l/<snip>/package
> node scripts/build.js

Binary found at /home/spenner/l/<snip>package/vendor/linux-x64-48/binding.node
Testing binary
Binary is fine

stefanpenner · 2017-11-22T20:36:56Z

If memory serves GLIBC 2.5 is what RHEL 5.x provides, and that version of GLIBC was released in 2006...

Anyways, to be a good node ecosystem citizen node-sass should likely mimic node's support platforms:

For new versions of node, the minimums are: Linux >= 2.6.32 with glibc >= 2.12 https://github.com/nodejs/node/blob/master/BUILDING.md.
For node 8 (and lower) the miimums are: kernel >= 2.6.18, glibc >= 2.5 https://github.com/nodejs/node/blob/v8.0.0/BUILDING.md

This would suggest, until node-sass drops support for node 8 (likely when node 8 ends its LTS December 2019) node-sass should support glibc => 2.5 and thus most likely support RHEL 5.x until Dec 2019.

Now obviously, this sounds like a PITA. So if it is decided that support for glibc 2.5 is to be dropped, it would at the very least require a major version bump.

stefanpenner · 2017-11-22T20:46:57Z

Maybe I am confusing myself, but it appears the binaries claim to only depend on quite old versions of GLIBC. How am I trolling myself?

objdump -t node_sass/vendor/linux-x64-48/binding.node  | grep GLIBC_

0000000000000000       F *UND*	0000000000000000              memset@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              snprintf@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              ceil@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              toupper@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              exit@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              __assert_fail@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strncmp@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              malloc@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              fopen@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              __cxa_atexit@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              fmod@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              free@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strlen@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              opendir@@GLIBC_2.2.5
0000000000000000  w    F *UND*	0000000000000000              __cxa_finalize@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              sprintf@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              trunc@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              pow@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strtol@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              memcpy@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              memmove@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strchr@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              fread@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strdup@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strcmp@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              tolower@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              getcwd@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              localeconv@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strcpy@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              memcmp@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              calloc@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              ceilf@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              fclose@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              __xstat64@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              isspace@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              isxdigit@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              closedir@@GLIBC_2.2.5
0000000000000000       O *UND*	0000000000000000              stderr@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              round@@GLIBC_2.2.5
0000000000000000  w    F *UND*	0000000000000000              __pthread_key_create@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              fwrite@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              realloc@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              floor@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strtoul@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              strtod@@GLIBC_2.2.5
0000000000000000       F *UND*	0000000000000000              readdir64@@GLIBC_2.2.5

Although

stefanpenner · 2017-11-22T20:55:17Z

It seems like: https://www.npmjs.com/package/prebuild maybe help simplify this process as it supports amongst other things spo--libc (use provided libc rather than system default)

And coupled with https://github.com/mapbox/node-pre-gyp, I suspect the binary build process will become greatly simplified.

saper · 2017-11-28T20:45:53Z

I have reproduced this with CentOS 5.11, node v6.12.0, yarn 1.3.2 and node-sass 4.7.2

saper · 2017-11-28T21:10:26Z

First thing that is unusual is that OS ABI in the binding.node file is set to 0x3 Linux, while normally it is set to 0x0 System V

[root@centos5 node]# readelf -h /tmp/node-v6.12.0-linux-x64/bin/node 

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x7b9da4
  Start of program headers:          64 (bytes into file)
  Start of section headers:          26102128 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         8
  Size of section headers:           64 (bytes)
  Number of section headers:         39
  Section header string table index: 36




[root@centos5 node]# readelf -h node_modules/node-sass/vendor/linux-x64-48/binding.node 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - Linux
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0xb0790
  Start of program headers:          64 (bytes into file)
  Start of section headers:          2617736 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         6
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 27

I have fixed this by binary editing the file and then the next problem appears:

[root@centos5 node]# node -p 'require("node-sass")'
module.js:597
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /tmp/node/node_modules/node-sass/vendor/linux-x64-48/binding.node)
    at Error (native)
    at Object.Module._extensions..node (module.js:597:18)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at module.exports (/tmp/node/node_modules/node-sass/lib/binding.js:19:10)
    at Object.<anonymous> (/tmp/node/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:570:32)

node v6.12.0 needs GLIBCXX_3.4 ABI which was the first libstdc++.so.6.0.0 release:

 [root@centos5 node]# objdump -t /tmp/node-v6.12.0-linux-x64/bin/node | grep GLIBCXX | sed s,^.*@,, | sort -u
GLIBCXX_3.4

But we need GLIBCXX_3.4.11 ABI which arrived with gcc 4.4:

[root@centos5 node]# objdump -t node_modules/node-sass/vendor/linux-x64-48/binding.node | grep GLIBCXX | sed s,^.*@,, | sort -u
GLIBCXX_3.4
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.9

saper · 2017-11-28T21:14:10Z

In 4.6.1 things were normal, albeit we needed a slightly newer libc:

[root@centos5 node]# objdump -t linux*binding.node | grep GLIBC_ | sed s,^.*@,, | sort -u
GLIBC_2.2.5
GLIBC_2.4
[root@centos5 node]# objdump -t linux*binding.node | grep GLIBCXX_ | sed s,^.*@,, | sort -u
GLIBCXX_3.4

so it looks like node 8 compiler/library dependencies sneaked into older builds.

kbower · 2018-01-30T11:32:50Z

I have access to a CentOS 5 (5.3) environment where everything builds fine:

(tg2env)[rarch@kb linux-x64-48]$ readelf -h binding.node
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0xaed00
  Start of program headers:          64 (bytes into file)
  Start of section headers:          3086096 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         6
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 27

(tg2env)[rarch@kb linux-x64-48]$ npm -v
3.10.9
(tg2env)[rarch@kb linux-x64-48]$ node -v
v6.9.2
(tg2env)[rarch@kb linux-x64-48]$ node -p process.versions
{ http_parser: '2.7.0',
  node: '6.9.2',
  v8: '5.1.281.88',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2j' }
(tg2env)[rarch@kb linux-x64-48]$ node -p process.platform
linux
(tg2env)[rarch@kb linux-x64-48]$ node -p process.arch
x64
(tg2env)[rarch@kb linux-x64-48]$ node -p "require('node-sass').info"
node-sass       4.7.2   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]
(tg2env)[rarch@kb linux-x64-48]$ npm ls node-sass
[email protected] /home/rarch/trunk/src/emberapps/cyclecount/node_modules/node-sass
└── (empty)

npm ERR! code 1

And this CentOS5 (5.5) machine, where the failure occurs:

(tg2env)[rarch@eld linux-x64-48]$ readelf -h binding.node
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0xb0790
  Start of program headers:          64 (bytes into file)
  Start of section headers:          2617736 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         6
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 27

(tg2env)[rarch@eld linux-x64-48]$ npm -v
3.10.9
(tg2env)[rarch@eld linux-x64-48]$ node -v
v6.9.2
(tg2env)[rarch@eld linux-x64-48]$ node -p process.versions
{ http_parser: '2.7.0',
  node: '6.9.2',
  v8: '5.1.281.88',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2j' }
(tg2env)[rarch@eld linux-x64-48]$ node -p process.platform
linux
(tg2env)[rarch@eld linux-x64-48]$ node -p process.arch
x64
(tg2env)[rarch@eld linux-x64-48]$ node -p "require('node-sass').info"
module.js:597
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: /home/rarch/trunk/src/emberapps/cyclecount/node_modules/node-sass/vendor/linux-x64-48/binding.node: ELF file OS ABI invalid
    at Error (native)
    at Object.Module._extensions..node (module.js:597:18)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at module.exports (/home/rarch/trunk/src/emberapps/cyclecount/node_modules/node-sass/lib/binding.js:19:10)
    at Object.<anonymous> (/home/rarch/trunk/src/emberapps/cyclecount/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:570:32)
(tg2env)[rarch@eld linux-x64-48]$ npm ls node-sass
[email protected] /home/rarch/trunk/src/emberapps/cyclecount/node_modules/node-sass
└── (empty)

npm ERR! code 1

saper · 2018-01-30T20:59:15Z

@kbower thanks for trying this! The issue is with the binaries provided by us. Rebuilding from source should produce a working binary. Can you check if the binding file built on older Centos 5.3 works when copied (not rebuilt) on Centos 5.5?

kbower · 2018-01-31T10:57:41Z

@saper Yes, indeed, copying the binding.node file from the CentOS 5.3 to 5.5 allowed me to build the rest of the app on the CentOS 5.5 machine.

xzyfer · 2018-03-10T07:39:24Z

I believe I may have a resolution to this. Is someone available to help me test this in real time?

anandbhaskaran · 2018-03-11T08:15:51Z

I am still stuck with this error. I tried with version 4.6.1, 4.7.1 and 4.7.2

saper · 2018-03-11T10:53:59Z

@anandbaskaran which node version are you on ? can you try 4.8.1 binaries?

xzyfer · 2018-03-11T13:04:53Z

Yes please, if you're experiencing this issue please try 4.8.1

npm install node-sass@^4.8.1

You can confirm you're using 4.8.1

npm ls node-sass

saper · 2018-03-11T19:11:37Z

@xzyfer I have just checked things on my 5.11 CentOS VM. node engines newer than 6 will not work.

But version 6 works fine with 4.8.1:

# cat /etc/redhat-release 
CentOS release 5.11 (Final)
# rpm -qf /usr/lib/libstdc++.so.6.0.8 
libstdc++-4.1.2-55.el5
# ./node_modules/node-sass/bin/node-sass  -v
node-sass	4.8.1	(Wrapper)	[JavaScript]
libsass  	3.5.0	(Sass Compiler)	[C/C++]

What about providing the following compatibility table with our releases:

OS	Architecture	Node
CentOS 5 Linux	x86 & x64	0.10, 0.12, 1, 2, 3, 4, 5, 6
CentOS 6, 7 Linux*	x86 & x64	0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8, 9
Alpine Linux	x64	4, 6, 8, 9

also recent releases of Ubuntu and Debian are supported

xzyfer · 2018-03-12T02:22:57Z

@saper correct me if I'm wrong, but my understanding is that

Node >= 7.10.0 will run on CentOS 5
Node > 7.10.0 will not run on CentOS 5
Node 8 will not run on CentOS 5
Node 9 will not run on CentOS 5

I have built the Node 7 binary with 7.10.0 in hopes it would run on both CentOS 5 and 6.

xzyfer · 2018-03-24T04:04:51Z

We have since released 4.8.3 which should address this issue.
Can someone please confirm?

kbower · 2018-03-24T17:47:22Z

I no longer have access to the CentOS 5.5 machine where this was failing, so I can't help. Sorry.

saper · 2018-03-24T19:23:26Z

@ReidBraswell can you check with your setup?

RuudV · 2018-03-26T10:12:38Z

Can confirm that version 4.8.3 resolves this issue on our environment.

xzyfer · 2018-03-26T11:03:55Z

Thanks

nschonni added the OS - Linux label Nov 22, 2017

saper added Bug - Confirmed Module - Binding Node 6 npm install labels Nov 28, 2017

saper changed the title ~~4.7.1 binary issue - ELF file OS ABI invalid~~ 4.7.0+ binaries incompatible with CentOS 5 - ELF file OS ABI invalid Nov 28, 2017

dependencies bot mentioned this issue Dec 5, 2017

Update 23 dependencies from npm JetBrains/ring-ui#31

Merged

dependencies bot mentioned this issue Dec 15, 2017

Update node-sass in / from 4.6.1 to 4.7.2 leonardofaria/leozera-ui#16

Closed

xzyfer mentioned this issue Feb 7, 2018

Failed at the [email protected] postinstall script. dlmanning/gulp-sass#652

Closed

johnpletka mentioned this issue Feb 8, 2018

ELF file OS ABI invalid on Centos5 with node-sass >4.7.0 dependency michaelwayman/node-sass-chokidar#36

Open

sass deleted a comment from kumar-tadepalli Mar 10, 2018

saper changed the title ~~4.7.0+ binaries incompatible with CentOS 5 - ELF file OS ABI invalid~~ 4.7.0-4.7.2 binaries incompatible with CentOS 5 - ELF file OS ABI invalid Mar 11, 2018

dependabot-preview bot mentioned this issue Mar 19, 2018

Bump node-sass from 4.5.3 to 4.7.2 fcknutwil/sponsorencrm_client#54

Closed

xzyfer closed this as completed Mar 26, 2018

4.7.0-4.7.2 binaries incompatible with CentOS 5 - ELF file OS ABI invalid #2159

4.7.0-4.7.2 binaries incompatible with CentOS 5 - ELF file OS ABI invalid #2159

Comments

ReidBraswell commented Nov 20, 2017 • edited Loading

xzyfer commented Nov 20, 2017

ghost commented Nov 20, 2017 • edited by ghost Loading

xzyfer commented Nov 21, 2017 via email

thilo-cts commented Nov 21, 2017

thilo-cts commented Nov 21, 2017

xzyfer commented Nov 21, 2017 via email

thilo-cts commented Nov 21, 2017

nschonni commented Nov 22, 2017

xzyfer commented Nov 22, 2017

nschonni commented Nov 22, 2017

xzyfer commented Nov 22, 2017

cedricroijakkers commented Nov 22, 2017

xzyfer commented Nov 22, 2017 via email

adarBlack commented Nov 22, 2017

cedricroijakkers commented Nov 22, 2017 • edited Loading

stefanpenner commented Nov 22, 2017 • edited Loading

stefanpenner commented Nov 22, 2017

stefanpenner commented Nov 22, 2017 • edited Loading

stefanpenner commented Nov 22, 2017

stefanpenner commented Nov 22, 2017 • edited Loading

saper commented Nov 28, 2017

saper commented Nov 28, 2017

saper commented Nov 28, 2017 • edited Loading

kbower commented Jan 30, 2018 • edited Loading

saper commented Jan 30, 2018

kbower commented Jan 31, 2018

xzyfer commented Mar 10, 2018

anandbhaskaran commented Mar 11, 2018

saper commented Mar 11, 2018

xzyfer commented Mar 11, 2018

saper commented Mar 11, 2018

xzyfer commented Mar 12, 2018

xzyfer commented Mar 24, 2018

kbower commented Mar 24, 2018

saper commented Mar 24, 2018

RuudV commented Mar 26, 2018

xzyfer commented Mar 26, 2018

ReidBraswell commented Nov 20, 2017 •

edited

Loading

ghost commented Nov 20, 2017 •

edited by ghost

Loading

cedricroijakkers commented Nov 22, 2017 •

edited

Loading

stefanpenner commented Nov 22, 2017 •

edited

Loading

stefanpenner commented Nov 22, 2017 •

edited

Loading

stefanpenner commented Nov 22, 2017 •

edited

Loading

saper commented Nov 28, 2017 •

edited

Loading

kbower commented Jan 30, 2018 •

edited

Loading