Open rombert opened 11 years ago
Does this happen only on a 32-bit distro (I'm just curious)? I think this issue might be coming from the CEF binary, and not the Brackets binary.
To verify my suspicion, please run:
ldd /opt/brackets/Brackets | grep libnspr
and paste the output here. If the output shows ".so" and not ".so.0d" then it is definitely not the Brackets executable to blame.
Also, try the latest 1.0 and see if anything's changed.
$ ldd /opt/brackets/Brackets | grep libnspr
libnspr4.so => /usr/lib64/libnspr4.so (0x00007f1c860dc000)
This seems to work now with 1.0 in my situation
So, the issue doesn't exist anymore? This issue can be closed then...
The Brackets binary links to libplc4.so.0d and libnspr4.so.0d , which are Debian-specific AFAICT.
Ideally it would link to libplc4.so and libnspr4.so, which are available on RPM-based systems. The workaround is to symlink e.g. libnspr4.so to libnspr4.so.0d , but that's in the way of a smooth installation, and a large share of users won't know how to do that.
See also CEF: Shared Library name mismatch in Fedora and Ubuntu .