I'm working in a project that uses buildroot-2012.11 to generate a Linux image for an embedded system.
I need to configure openocd for a JTAG debugger that uses an FTDI chip (FT2232D).
I realized that this buildroot version integrate openocd-0.5.0 and the latest openocd release is 0.9.0. I'm interested in updating to this version since I want to use ftdi interface driver instead of ft2232 (deprecated).
I tried to accomplish that by modifying /package/openocd/openocd.mk on the lines:
OPENOCD_VERSION:=0.9.0
OPENOCD_CONF_OPT += --enable-ftdi
The new openocd files where downloaded successfully but when it tries to install it and apply openocd-0001-fix-cross-compilation-host-libsub-was-used-before.patch I got:
Applying openocd-0001-fix-cross-compilation-host-libsub-was-used-before.patch using patch:
can't find file to patch at input line 17
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 3728c4af7f6303ccedab56ec220797f8f290580e Mon Sep 17 00:00:00 2001
|From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj#jcrosoft.com>
|Date: Wed, 10 Aug 2011 00:17:29 +0800
|Subject: [PATCH] fix cross compilation: host libsub was used before
|
|tested in buildroot
|
|Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj#jcrosoft.com>
|---
| configure.in | 7 +++++--
| 1 files changed, 5 insertions(+), 2 deletions(-)
|
|diff --git a/configure.in b/configure.in
|index dfa1e8f..cfe2218 100644
|--- a/configure.in
|+++ b/configure.in
--------------------------
File to patch: configure.in
configure.in: No such file or directory
If I skipped the patch the building process stop and I'm not able to generate the images.
I've doing some research on the internet and I couldn't find how to do this correctly.
Maybe one obvious solution could be updating the buildroot version but since there is a lot of other people development with the current version I'm not in a position of taking that decision right now.
I'll do appreciate any help.
Upgrade your Buildroot release. 2015.08 already has OpenOCD 0.8.0 and it should be trivial to update to 0.9.0. Plus you will benefit from the numerous improvements and updates that have been made between 2012.11 and 2015.08.
Related
I'm having problems with files created from within Eclipse running on Linux.
All files (as far as I know) only gets the owner read and write permissions. Build output is the same but with the execute permission added.
The "test" file is created in Eclipse by File > New, and the "test1" file is created in command line by "touch" by the same user in the same folder.
-rw-------. 1 user stdgroup 0 Mar 15 10:22 test
-rw-r--r--. 1 user stdgroup 0 Mar 15 10:23 test1
My umask is set to 0022, so the output from the "touched" file is correct.
I'm running Eclipse Oxygen.2 Release 4.7.2 on Linux RedHatEnterpriseServer 7.3.
Anyone knows if there is a setting in Eclipse that can cause this, or any other ideas as to why this happens?
I am trying to run Open Drone Map which I have cloned to an Ubuntu 15.04 server I have installed all the required libraries. After I execute the code:
perl ../OpenDroneMap/run.pl
from within the directory I have all the photos in I get this error:
: , or } expected while parsing object /hash at character offset 11081 (before " " Mantis i23" : 45.00\n...") at ../OpenDroneMap/run.pl line 36, <$fh> chunk1.
Any help or suggestions greatly appreciated. Let me know if you need to see the perl code that executes.
http://pastebin.com/nCy12Ezu
Update your version of OpenDroneMap, it looks like it has already been fixed.
https://github.com/OpenDroneMap/OpenDroneMap
Latest commit:
commit 6b4d8b8cfc106182031f6b5f78976aff42836c54
Author: Stephen Mather <stephen#smathermather.com>
Date: Sat Jul 18 15:56:53 2015 -0400
fix for missing comma
ccd_defs.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Try to erase last line (not "}") from ccd_defs.json file. There is a non correct ":" character in Mantis i23 definition line.
I am facing a strange issue with getting the db2 version using db2ls.
Below are 2 instances of db2ls execution
[root#dummy 6]# cd /tmp
[root#dummy tmp]# db2ls
Install Path Level Fix Pack Special Install Number Install Date Installer UID
---------------------------------------------------------------------------- -----------------------------------------
/opt/ibm/db2/V10.5 10.5.0.3 3 Tue Mar 10 01:38:53 2015 PDT 0
[root#dummy tmp]# mkdir test\ dir
[root#dummy tmp]# cd test\ dir/
[root#dummy test dir]# db2ls
/usr/local/bin/db2ls: line 43: cd: /tmp/test: No such file or directory
Install Path Level Fix Pack Special Install Number Install Date Installer UID
---------------------------------------------------------------------------------------------------------------------
/opt/ibm/db2/V10.5 10.5.0.3 3 Tue Mar 10 01:38:53 2015 PDT 0
It looks like db2ls is having issues when executed from a directory having spaces. Is this a known issue? I could not find any documentation for this. I am trying to circumvent this problem by using db2ls 2>/dev/null.
If there is a more efficient way please let me know.
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.qb.server.doc/doc/t0023683.html
for DB2 installation paths it says
DB2 installation paths have the following rules:
Can include lowercase letters (a-z), uppercase letters (A-Z), and the underscore character ( _ )
Cannot exceed 128 characters
Cannot contain spaces
Cannot contain non-English characters
Reading statements like this are always a warning sign not to use spaces in paths in general. BTW, shell scripts don't play well with spaces in paths which is for me a good reason to avoid spaces in general.
This call fails on Solaris with EACCES when ran as ordinary user:
sem_open(fileName.c_str(), O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO, 1);
When process is started as root, it runs fine. Is this expected behavior?
Environment:
$ uname -a
SunOS solaris 5.11 11.0 i86pc i386 i86pc
$ g++ --version
g++ (GCC) 4.5.2
At the command line try:
prctl $$
These are the system enforced resource limits your process has. Note there are
process.max-sem-ops
process.max-sem-nsems
project.max-sem-ids
These are limits that have a number, if you do not see them (or the limits are already reached) then you have to add them to your account's profile with projadd or projmod to increase them if your project already exists.
If you cannot do this (no root access) consult with your sysadmin, s/he probably has some reason for not allowing semapahore access.
Note carefully:
sempahores are kernel persistent. If you ran your code a bunch of times the sempahores you created are likely still out there.
To see existing semaphores try ipcs -as
To remove lingering sempahores that your code should have removed use ipcrm
For example, if I have two files:
file1:
This is file 1
and file2:
This is file 2
and create patch with the following command:
diff -u file1 file2 > files.patch
result is:
--- file1 Fri Aug 13 17:53:28 2010
+++ file2 Fri Aug 13 17:53:38 2010
## -1,1 +1,1 ##
-This is file 1
+This is file 2
Then if I try to apply this patch on Solaris with patch command:
patch -u -i files.patch
it hangs on:
Looks like a unified context diff.
File to patch:
1. Is there a way to use Solaris native patch command with unified diffs?
2. Which diff format is considered most portable if it's not possible to apply unified format?
Update:
I've found answer on the first part of my question. Seems that patch on Solaris hangs if the second file (file2 in this case) exists in the same folder as the first one (file1). For example, the following quite common diff:
--- a/src/file.src Sat Aug 14 23:07:29 2010
+++ b/src/file.src Sat Aug 14 23:07:37 2010
## -1,2 +1,1 ##
-1
-
+2
will not work with quite common patch command:
patch -p1 -u -d a < file.patch
while the following diff (note second file is renamed):
--- a/src/file.src Sat Aug 14 23:07:29 2010
+++ b/src/file_new.src Sat Aug 14 23:07:37 2010
## -1,2 +1,1 ##
-1
-
+2
will work perfectly.
For the second part of my question see accepted answer below.
On Solaris /usr/bin/patch is an old version required to comply with some ancient standards.
A modern version of GNU patch is provided as /usr/bin/gpatch on Solaris 8 and later.
diff -cr old.new new.txt > patch.txt
gpatch -p0 < patch.txt
Works perfectly for me (using gpatch)
Single Unix v2 and v3 both support context diffs but not unified diffs, so for better portability you should use context diffs (-c option to diff and patch).
On older Solaris releases (pre-10, I think), you need to make sure that /usr/xpg4/bin is before /usr/bin in your $PATH, otherwise you may get compatibility versions of some utilities instead of standard ones.