When i try to attach hhvm process to nuclide debug interface, nothing happened. In the dev console.
Please find the below screenshot for more information.
lldb is already installed. How can I fix this error?
I don't know what the nuclide package's "find_lldb()" function does, so I can't tell why it is failing. If you have the source to that package you might take a look at what it is looking for.
You could try adding the directory that holds the lldb Python module to your PYTHONPATH directly. Then lldb should just load normally without more intervention from nuclide.
The lldb driver when invoked with the -P argument will print out the directory containing that module. You might also make sure that:
$ PYTHONPATH=`lldb -P` python
>>> import lldb
works correctly. It should not give the "No module named lldb" error. If it does then somehow your lldb isn't installed properly.
Related
I need to run a javascript script in pfsense terminal but I don't know how to download the gcc nor node library to run it. And if I do don't know how to export the correct command to use the "gcc [command]" and "node [command]" without using the full path.
Is there anyone who can give me steps to download them, and make them usable without full path, cause I'm trying for months now and noone has helped me.
I've tried the normal way of "pkg install X" and drag&drop the library folder directly to the VM I use for the pfsense. I cant even download side package manager cause pfsense doesn't let me.
Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.
I am using OSX 10.8.2 and gdb 6.3. I have to use both xcode 4.6.1 and xcode 3.
I have a simple c executable for which i am trying to attach gdb through command line. But i am not able to give break points. As soon as the gdb is attached i am getting the below lines.
unable to read unknown load command 0x2b
unable to read unknown load command 0x80000022
unable to read unknown load command 0x24
unable to read unknown load command 0x2a
I goggled it out and found that gdb 6.3 has few bugs for which above thing might be happening. so i thought of updating the gdb to 7.6. Even this is not happening.
Steps i did to install gdb 7.6
./congigure
make
make install
make is ending with below lines
make[8]: Nothing to be done for `all-am'.
make[1]: Nothing to be done for `all-target'.
make install with below lines
make[11]: Nothing to be done for `install-data-am'.
make[1]: Nothing to be done for `install-target'.
I want gdb which is supported by xcode 3,4.6 as well as in command line. Please help to resolve this.
They're just warnings, you're fine to ignore them. The gdb binary you're using didn't include the definitions of these load commands (LC_DYLD_INFO_ONLY, LC_VERSION_MIN_MACOSX, etc see /usr/include/mach-o/loader.h) and it's complaining about them when it parses the Mach-O binaries with them included. The gdb included in Xcode 4.6 will handle these without warning, fwiw.
As I can figure out with make command output your program is compiled and not changed. So you have to make clean your code and try again. Make sure that you are compiling the code with -g parameter of gcc to link the symbol table of C to the executable, in order to give to gdb the necessary parameters for debugging. So, you must to have a look at makefile.
I've got a project in KDevelop, but attempting to install if from within the IDE simply gives the following output:
/home/<myusername>/Projects/rect/build/release> kdesu -t -- make -j8 install
*** Failed ***
However, when I run the exact same command from the exact same location in terminal (outside KDevelop), it asks for the root password as it should and installs just fine. All possible solutions for the problem I could find are either for missing kdesu or kdesu installed in a location not on PATH by default; however, I most certainly have kdesu on my system and I have exported its location, and like I said, the exact command that KDevelop appears to be trying to run works beautifully outside the IDE.
So, how would I get the install option working in KDevelop itself?
I'm using Debian Wheezy if this matters.
I got around this by creating a symlink to the kdesu binary in /usr/local/bin, which seems to be working just fine. I'm still curious as to why it didn't work before since the directory containing kdesu was on the PATH, though.
Of course the problem with my PATH was that I was only setting it in the console but the PATH is different for GUI applications (thanks D.J.Duff for pointing that out, can't believe I didn't know this) - I fixed it by adding PATH="$PATH:/usr/lib/kde4/libexec" (the location of these binaries) to my .profile file as suggested here.
I'm trying to set up unixODBC to connect to a Netezza database, however I'm getting a "Undefined symbol: SSL_connect" when I try to connect using isql.
Currently using: CentOS 5.5, unixODBC 2.3.0 (Same issue with 2.2.11).
I have done the following:
Configured the LD_LIBRARY_PATH, ODBCINI, and NZ_INI_FILE_PATH according to the README.txt that came with the ODBC drivers.
Ensued that all libraries are loaded by using the ldd command and setting up symbolic links for libssl and libcrypto.
Updated the /etc/ld.so.conf file to ensure the netezza drivers path is loaded.
Used nm to confirm that the SSL_connect symbol is in the driver.
Running dltest against the file for this symbol reports a "file not found" error, which is what I normally get when I try to run isql -v, however I changed the LD_DEBUG environment variable to get additional debugging info, which led me to SSL_connect.
(FYI, export LD_DEBUG=files isql sospos is what I used.)
Any thoughts? This is driving my crazy as it appears everything is there, but it's still not working. Worst part is that I set up the same thing on Ubuntu 10.10 months ago and it worked without any issues.
UPDATE:
First, ldd on the libnzodbc.so file looks good. All dependencies have been satisfied.
Second, the only thing I could see in the file that was missing was the libc.mo file for the en_US locale, so I set up a symbolic link to the en_GB one. Unfortunately, it's still throwing the same error even though it it looks like it found every other lib it's looking for. Is there anything else in the strace output I should be looking for?
UPDATE 2:
An issue I'm currently seeing is that isql is looking for gconv_end in ISO8859-1.so, however that symbol does not exist. Interestingly enough, the symbol does not exist on my Ubuntu server VM and isql works fine. Both versions of unixODBC I specified above have the same issue.
UPDATE 3:
O.K. Re-ran ldd with the -d and -r options and yes, there are still issues. Every SSL* symbol is missing. I'm guessing this means that I created a symbolic link to the wrong file. Anyone know which ssl library file contains SSL_connect?
O.K. Figured it out. It turns out the symbolic link I created was pointing to the wrong library file. Originally I did this:
(/usr/lib/) ln -s libssl3.so libssl.so.4
I should have done this:
(/usr/lib) ln -s ../../lib/libssl.so.0.9.8e libssl.so.4
Well, SSL_connect is from the OpenSSL libs. Maybe you could try using strace on isql and post the parts where it fails (I suspect) to load a libssl. It may be that your existing ssl lib doesn't match what the driver is looking for. What does ldd show on the driver lib?
If anyone is still looking at a similar issue, there's a django-netezza package that works well: https://github.com/msabramo/django-netezza