i've got a trouble. Can't debug my program remotly due to can't call wiringPiSetupGpio(). I'm using netbeans to develop and debug my programs. I'm almost sure I need run debugging as root user but... how can I do that?
Is it possible to force netbeans start something like 'sudo gdb' insead of normal user? Or maybe to force my account in raspberry pi to call 'sudo gdb' when whatever try to call 'gdb'?
To force netbeans start gdb as root, you need to install netbeans as root. make sure your netbeans intall dir is in /usr/local and not in /home/[user_name]. You have to run netbeans installation as sudo
This is an old post but since I was facing the same issue I will post how I resolved this:
The problem for me did not seem to be the gdb, but the gdbserver running on the Raspi (or Beaglebone in my case).
I added a debug configuration to debug the application as root, therefore I added a script to the Beaglebone /usr/local/sbin/gdbserver and added the following lines:
#!/bin/bash
sudo /usr/bin/gdbserver $*
and made it executable:
sudo chmod a+x /usr/local/sbin/gdbserver
and see that in the file /etc/login.defs the lines
ENV_SUPATH PATH= ....
ENV_PATH PATH= ....
contain /usr/local/sbin. then in the debug configuration for the root execution I changed the command gdbserver to /usr/local/sbin/gdbserver. If that still doesn't work you might have to do this too:
sudo visudo
and add
<your_user> ALL=(root) NOPASSWD:/usr/bin/gdbserver
I hope this helps.
Related
When I run make run.byte I get this error ocsigenserver: ocsigen:main: Fatal - You are not allowed to use port 80.. I've tried sudo make run.byte but sudo doesn't know about opam or ocsigenserver. I've tried to play with wwwuser in the Makefile.options, but I can't make it work.
The README generated by the distillery doesn't give much information, and I can't find anything online.
make test.byte works just fine.
Any idea please?
edit:
It looks like it has nothing to do with eliom/ocaml, non root users just can't run anything on ports lower than 1024 on Ubuntu. But I still don't understand why the distillery suggests that I can do it if my wwwuser is me, I don't think there's any way this is ever going to work.
I also don't understand how I am supposed to run sudo make run.byte, opam is installed in my ~ directory, sudo cannot find ocsigenserver.
I could make it work by running everything as root, but anytime I run an opam command as root I get the you shouldn't use opam as root warning. I don't think this is the way I'm supposed to run it. Something's not right.
With previous release of eliom (eliom.5.0.0) - I have not used yet the fresh 6.0.0 release - you have to install first your eliom application :
sudo make install
Then you have to kill the process listening to the 80/tcp port (ex: sudo netstat -tulpn 80 | grep :80 will help identify the process listening to that port - most likely apache2 or lighthttpd).
Then, you run your executable:
sudo PATH=$PATH OCAMLPATH=$OCAMLPATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH
make run.byte
This is what is written in README created with eliom-distillery - but take care to set your env variables before :
OCAMLPATH is the location of ocaml used in your env (in my env :~/.opam/4.02.3/bin).
LD_LIBRARY_PATH : .opam/4.02.3/lib/stublibs (otherwise dllssl_threads_stubs is not found)
I am trying to get Leiningen and Cygwin working together.
One of the problems I think I have is that I have Java installed in "C:\Program Files\Java..." directory. The space appears to be causing issues.
When I try to run the lein script in Cygwin, I am getting the following error:
./lein: line 325: C:\Program Files\Java\jdk1.8.0_05\bin\java.exe : command not found
Then I thought the issue was the space. So I changed line 325 from:
"$LEIN_JAVA_CMD" \
to (for testing purposes):
"$'C:\\\Program Files\\\Java\\\jdk1.8.0_05\\\bin\\\java.exe'" \
But, I am still getting this error:
./lein: line 325: $'C:\\Program Files\\Java\\jdk1.8.0_05\\bin\\java.exe' : commande introuvable
However, this file clearly exists:
Owner#Owner-PC ~
$ ls -alh $'C:\\Program Files\\Java\\jdk1.8.0_05\\bin\\java.exe'
-rwxr-xr-x 1 Owner None 187K 8 mai 15:39 C:\Program Files\Java\jdk1.8.0_05\bin\java.exe
The lein script appears to be properly configuring Leiningen for Cygwin, however I can't get it to work.
Note that I previously installed Leiningen outside of Cygwin (I was running it in Windows' normal shell).
What could be wrong with my setup, any ideas?
I use Leiningen via Cygwin with no problems.
Start over
Start over with a fresh copy of the lein script. There should be no need to edit it.
Set your PATH to include java
The easiest solution is to set your path in ~/.profile to include the path to Java's bin directory. Lein will then find java on the path and you'll have access to java and its related tools in your shell.
export JAVA_HOME="/cygdrive/c/Program Files/Java/jdk1.8.0_05/"
export PATH="${JAVA_HOME}/bin/:${PATH}"
Restart your shell or source ~/.profile. Verify that which java finds java command. And run java to verify you get the help output.
And/or explicitly set the LEIN_JAVA_CMD and JAVA_CMD variables
Alternatively, set the LEIN_JAVA_CMD and JAVA_CMD variables used by lein in your ~/.profile
export JAVA_HOME="/cygdrive/c/Program Files/Java/jdk1.8.0_05/"
export LEIN_JAVA_CMD="${JAVA_HOME}/bin/java"
export JAVA_CMD=`cygpath -w "${LEIN_JAVA_CMD}"`
Restart your shell or source ~/.profile.
Note: You can also set a separate LEIN_JVM_OPTS and JVM_OPTS if desired, but this should not be necessary.
If you have lein previously installed on Windows and want to reach it from cygwin, then do:
on cmd:
cd C:/Users/%userprofile%/.lein/bin
mklink lein lein.bat
on cygwin:
export CYGWIN=winsymlinks:nativestrict
I feel your pain. I tried something like this myself several years ago.
You have at least two problems. One is getting lein to run as under unix as you noted. There are really two lein scripts - one for unix, the other a batch script for use under windows.
Your bigger problem is java.exe - getting the windows java executable to behave as a cygwin shell, and particular the unix lein script running in a cygwin shell, expects is messy and fragile undertaking.
I would strongly recommend either using a clojure ide that supports Windows (perhaps LightTable) or installing a full linux virtual machine with the unix java SDK and doing clojure development in that environment. Ubuntu running on virtualbox is freely available and an option I have used in the past for just this purpose.
You need to create a symbolic link to the "lein.bat" file.so you use it properly in Cygwin.
Open CMD and go to the ".lein" path (cd %userprofile%\.lein\bin) and run this: mklink lein lein.bat
#a-webb is almost right ,but there are still some steps to complete.First,you will find a folder called “.lein” where you run the lein script in cygwin,go in,copy the folder "self-installs" inside to C:\Users\yourUserName.lein
,then,add C:\Users\yourUserName.lein\bin to the environment variable $Path.
I've found the easiest way is to:
Install via the windows binaries and
Copy the lein bash script into .lein/bin
Then it should just work in cygwin.
I am experiencing very annoying problems with the application apktool problem.
I do not understand what i am doing wrong, or what the problem is.
I tried this on debian , and on linux mint. I used different versions of apktool,
resulting in the same error:
I: Checking whether sources has changed...
I: Checking whether resources has changed...
I: Building resources...
Exception in thread "main" brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [aapt, p, -F, /tmp/APKTOOL3630495287059303807.tmp, -I, /home/awesomename/apktool/framework/1.apk, -S, /home/awesomename/out/./res, -M, /home/awesomename/out/./AndroidManifest.xml]
at brut.androlib.res.AndrolibResources.aaptPackage(Unknown Source)
at brut.androlib.Androlib.buildResourcesFull(Unknown Source)
at brut.androlib.Androlib.buildResources(Unknown Source)
at brut.androlib.Androlib.build(Unknown Source)
at brut.androlib.Androlib.build(Unknown Source)
at brut.apktool.Main.cmdBuild(Unknown Source)
at brut.apktool.Main.main(Unknown Source)
Caused by: brut.common.BrutException: could not exec command: [aapt, p, -F, /tmp/APKTOOL3630495287059303807.tmp, -I, /home/windows/apktool/framework/1.apk, -S, /home/windows/out/./res, -M, /home/windows/out/./AndroidManifest.xml]
at brut.util.OS.exec(Unknown Source)
... 7 more
Caused by: java.io.IOException: Cannot run program "aapt": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
at java.lang.Runtime.exec(Runtime.java:617)
at java.lang.Runtime.exec(Runtime.java:485)
... 8 more
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:135)
at java.lang.ProcessImpl.start(ProcessImpl.java:130)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
... 10 more
It seems it can not use aapt , but i read about apktool.
And it seems that aapt is build inside apktool , why is it not working ?
It seems there's some problem in building the resources while recompiling the apk.
what you can do is, when you decompile your apk use this command
apktool d -f -r apkfilename.apk
here -f is to replace previous decompiled apk's code and -r is to ignore the decompiling of resources.
this would prevent the resources from being decompiled and will simply copy the same resources when you recompile the apk.
In case you've been using v1 and now upgraded to v2, try manually deleting the framework file.
On windows 8 it's normally at C:\Users\YourName\apktool\framework\1.apk.
The file should be regenerated once you try to build something.
My problem was solved by deleting the \framework\1.apk, making a backup on the files I modified, ereasing the dir and decompiling the *.apk again, etc... (on linux, the path is home/[user]/apktool/...). After the update, apktool always loaded the old resource table. N
For me, I solved this problem by first clearing apktool's framework directory by typing in the terminal.
$ apktool empty-framework-dir
Afterwards I uninstalled apktool and related files by typing
$ sudo apt purge apktool
Then i went to https://bitbucket.org/iBotPeaches/apktool/downloads/ to get the latest jar file for apktool(apktool_2.5.0.jar as at the time of writing this).
On first run
$ java -jar apktool_2.5.0.jar b <MyAPP.apk> #Without ><
it works.
since I work with apktool most of the times I needed a situation where I can run apktool from anywhere so I gave the jar file execute permissions by typing
$ sudo chmod +x apktool_2.5.0.jar
Afterwards I moved it /usr/bin/ by typing
$ sudo apktool_2.5.0.jar /usr/bin/
Definitely seems like the aapt PATH problem I had awhile back. Have you added aapt to PATH? If you still have problems, I have made a good apk kit in bash to avoid all these dependency problems. It supports apktool, signapk, zipalign,adb, fastboot, and heimdall. Check it out. All you need is a current java install.
http://forum.xda-developers.com/android/development/toolkit-apk-munky-rench-t3026757/post58747626#post58747626
There isn’t really enough information to give you a definite answer.
How ever you mentioned using different versions but the aapt issue was solved in version 2.4. Dependencies have been reduced to java version 1.8 or greater and the framework.
I use Debian and have the following:
Apktool 2.4
java version 11
Android framework
That’s all it took to get rid of the aapt path error.
The last error I came across was unrelated to aapt but was on the framework so I ran this command
apktool empty-framework-dir
And it solved it.
try to put the dir which include aapt file to your PATH. for example, export PATH=$PATH:./ ./apktool b
try to install ia32-libs and update latest version of apktool. (if possible restart)
apktool requires "ia32-libs" which is not available after Ubuntu 12.04. install ia32-libs
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 lib32stdc++6
Download latest version of apktools.jar - https://bitbucket.org/iBotPeaches/apktool/downloads
apktool complete installation guide - http://ibotpeaches.github.io/Apktool/install/
I just encounter same problem when run apktool d foo.apk(decompiled success) and then apktool b foo(recompile failed with similar error).
The apktool tool above was installed via sudo apt-get install apktool on Kali Linux.
So, the solution was visits apktool's official site, e.g. https://connortumbleson.com/2017/01/23/apktool-v2-2-2-released/ (it's latest version at this time of writing), download it, md5sum it, e.g. md5sum apktool_2.2.2.jar to verify, then rename that apktool_2.2.2.jar to apktool.jar.
Then do java -jar ./apktool.jar b foo to recompile, it success without error (the generated apk located at ./foo/dist/foo.apk).
The main issue is apktool version you need 2.4.0
You must manually install it from ibotpeaches git hub
here some good info
https://www.youtube.com/watch?v=kB6s10Uwpcs
and a automated script for kali
https://github.com/catenatedgoose?tab=repositories
In my mind the problem is how you install apktool...
I had the same problem and I did this and it worked very well:
For installation you first have to remove any installed apktool by the command:
sudo apt purge apktool
Then you'll have to install apktool but in a different way.
To continue save the link bellow as apktool in a directory.
[https://raw.githubusercontent.com/iBotPeaches/Apktool/master/scripts/linux/apktool]
Then open this link below and download the latest apktool.jar file: https://bitbucket.org/iBotPeaches/apktool/downloads/
Then rename the file as apktool.jar
After that give both files the permission by the command:
Sudo chmod -x apktool.jar
And for the saved script:
Sudo chmod -x apktool
At the end copy both files in the directory:
/usr/local/bin
By the command:
Sudo cp apktool.jar /usr/local/bin
And the script file:
Sudo cp apktool /usr/local/bin
After that try running apktoolin the terminal.
The solution is to include your apktool directory into your system PATH.
I have a project that runs on Ubuntu and Solaris. Fabric works fine with Ubuntu but does not on Solaris. If I try something inside a virtualenv it fails with workon: command not found.
This is how my fabfile.py looks like:
with prefix('workon %s' % env.virtualenv):
sudo('manage.py collectstatic --noinput')
I put those lines in .profile on both platforms:
export WORKON_HOME=$HOME/.virtualenvs
source /path/to/virtualenvwrapper.sh
That's all I've done. Why does Ubuntu work but Solaris doesn't? Any ideas?
It's Virtualenvwrapper that's failing, not Fabric or Virtualenv. Try using Virtualenv directly with:
with prefix('source path/to/virtualenv/bin/activate'):
sudo('manage.py collectstatic --noinput')
EDIT:
to try to fix virtualenvwrapper, try wrapping your code in the following, and see if it solves the original error.
with prefix('source path/to/virtualenvwrapper.sh'):
Consider where you have put the following?
export WORKON_HOME=/opt/virtual_envs
source /usr/local/bin/virtualenvwrapper.sh
According to man bash, the -l flag, that fabric issues, will cause the the following to happen
[bash] looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
I had this bootstrap code in .bashrc, which wasn't being sourced by bash -l. I moved those two lines to .profile, and can now do the fabric lines below. (I don't have .bash_profile or .bash_login)
with cd('/www/code'):
with prefix('workon code'):
run('./manage.py validate')
I compiled a simple go application with debug flags:
go build -gcflags "-N -l" -o main main.go
main.go
package main
import (
"fmt"
"time"
)
func main() {
for i := 0; true; i++ {
fmt.Println("number:", i)
time.Sleep(time.Second)
}
}
In gdb, I attached to its pid and executed break and break 11.
gdb --pid=<pid>
Gdb reports that the breakpoints are successfully set, but they don't ever get hit. Is there a way to get this working?
Note: that same setup (even when adding your runtime-gdb.py to your .gdbrc) risks to not work with Ubuntu 13.10, where you would get a "SyntaxError" message, as illustrated in:
blog post "Debugging Go 1.2 on Ubuntu 13.10 with GDB" from Michael Susens-Schurter (schmichael)
issue 6698 (gdb: upgrade to be python 3 compatible)
The problem is that Ubuntu 13.10 links GDB against Python 3.3 while the script golang ships is for Python 2. Someone has already filed an issue, and it appears to be fixed upstream (so expect Go 1.3 to Just Work).
Luckily backporting the fix is easy. Simply move your exist runtime-gdb.py out of the way and download the upstream version in its place.
If your $GOROOT is /usr/local/go the following should Just Work:
sudo mv /usr/local/go/src/pkg/runtime/runtime-gdb.py /usr/local/go/src/pkg/runtime/runtime-gdb.py.orig
cd /usr/local/go/src/pkg/runtime/
sudo wget https://go.googlecode.com/hg/src/pkg/runtime/runtime-gdb.py
the go/src/pkg/runtime/runtime-gdb.py script needs to be loaded inside gdb to effectively be able to debug go programs.
You can add it to the .gdbrc file.