By trying to compile QGIS from sources on Ubuntu, there is the file /opt/QGIS/cmake/FindSIP.py which content is:
import sipconfig
sipcfg = sipconfig.Configuration()
print("sip_version:%06.0x" % sipcfg.sip_version)
print("sip_version_num:%d" % sipcfg.sip_version)
print("sip_version_str:%s" % sipcfg.sip_version_str)
print("sip_bin:%s" % sipcfg.sip_bin)
print("default_sip_dir:%s" % sipcfg.default_sip_dir)
print("sip_inc_dir:%s" % sipcfg.sip_inc_dir)
# SIP 4.19.10+ has new sipcfg.sip_module_dir
if hasattr(sipcfg, "sip_module_dir"):
print("sip_module_dir:%s" % sipcfg.sip_module_dir)
else:
print("sip_module_dir:%s" % sipcfg.sip_mod_dir)
In Python3.6, the last if/else statement prints:
sip_module_dir:/usr/lib/python3.6/dist-packages
But the string /usr/lib/python3.6/dist-packages doesn't match an existing directory (it is probably part of why I encountered the error:
python/CMakeFiles/python_module_qgis__core.dir/build.make:537: recipe for target 'python/core/sip_corepart0.cpp' failed' failed during build process).
I either have:
/usr/lib/python3/dist-packages
or
/usr/lib/python3.6/site-packages
And it's only in /usr/lib/python3/dist-packages that I have some 'sip' related files (the other directory gives no results):
$ find . -iname "*sip*"
./twisted/protocols/__pycache__/sip.cpython-36.pyc
./twisted/protocols/sip.py
./twisted/test/test_sip.py
./twisted/test/__pycache__/test_sip.cpython-36.pyc
./sipconfig.py
./sip.pyi
./sipconfig_nd6.py
./sipdistutils.py
./__pycache__/sipconfig_nd6.cpython-36.pyc
./__pycache__/sipdistutils.cpython-36.pyc
./__pycache__/sipconfig.cpython-36.pyc
./sip.cpython-36m-x86_64-linux-gnu.so
I guess there is something to fix within 'sip' itself but don't know where exactly, neither how to do that.
More information;
OS: Ubuntu 16.04 64 bits
Python: 3.6.7
Sip: 4.19.7
Related
This question already has an answer here:
What is the "[" binary file in my "/bin" folder for? (MacOS Big Sur M1 chip) [closed]
(1 answer)
Closed 1 year ago.
I was poking around a new MacBook Air M1 running Big Sur. I came across an executable file in /bin called "[". Seemed strange to me so I looked into it a bit more but the mystery remains. Google/DuckDuckGo searches are fruitless. I copied the file into my homedir to do some more investigation. Here's what I found:
user#jackrabbit(s003) ~ % file foo
foo: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64]
[arm64e:Mach-O 64-bit executable arm64e]
foo (for architecture x86_64): Mach-O 64-bit executable x86_64
foo (for architecture arm64e): Mach-O 64-bit executable arm64e
user#jackrabbit(s003) ~ % strings foo
#(#)PROGRAM:test PROJECT:shell_cmds-216.60.1
33333
$FreeBSD$
missing ]
unexpected operator
%s: %s
closing paren expected
argument expected
%s: bad number
%s: out of range
#(#)PROGRAM:test PROJECT:shell_cmds-216.60.1
33333
k#$FreeBSD$
missing ]
unexpected operator
%s: %s
closing paren expected
argument expected
%s: bad number
%s: out of range
user#jackrabbit(s003) ~ %
I tried running the executable with a few different arguments but didn't get any useful output.
Any ideas?
After some more thinking and poking around, it's a copy of /bin/test. It's got the same size and last modified time, so it appears to be part of the original OS install. Anyone with Big Sur able to verify if they also have /bin/[?
I need to programmatically inspect the library dependencies of a given executable. Is there a better way than running the ldd (or objdump) commands and parsing their output? Is there an API available which gives the same results as ldd ?
I need to programmatically inspect the library dependencies of a given executable.
I am going to assume that you are using an ELF system (probably Linux).
Dynamic library dependencies of an executable or a shared library are encoded as a table on Elf{32_,64}_Dyn entries in the PT_DYNAMIC segment of the library or executable. The ldd (indirectly, but that's an implementation detail) interprets these entries and then uses various details of system configuration and/or LD_LIBRARY_PATH environment variable to locate the needed libraries.
You can print the contents of PT_DYNAMIC with readelf -d a.out. For example:
$ readelf -d /bin/date
Dynamic section at offset 0x19df8 contains 26 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x3000
0x000000000000000d (FINI) 0x12780
0x0000000000000019 (INIT_ARRAY) 0x1a250
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x1a258
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x308
0x0000000000000005 (STRTAB) 0xb38
0x0000000000000006 (SYMTAB) 0x358
0x000000000000000a (STRSZ) 946 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x1b000
0x0000000000000002 (PLTRELSZ) 1656 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x2118
0x0000000000000007 (RELA) 0x1008
0x0000000000000008 (RELASZ) 4368 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffb (FLAGS_1) Flags: PIE
0x000000006ffffffe (VERNEED) 0xf98
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0xeea
0x000000006ffffff9 (RELACOUNT) 170
0x0000000000000000 (NULL) 0x0
This tells you that the only library needed for this binary is libc.so.6 (the NEEDED entry).
If your real question is "what other libraries does this ELF binary require", then that is pretty easy to obtain: just look for DT_NEEDED entries in the dynamic symbol table. Doing this programmatically is rather easy:
Locate the table of program headers (the ELF file header .e_phoff tells you where it starts).
Iterate over them to find the one with PT_DYNAMIC .p_type.
That segment contains a set of fixed sized Elf{32,64}_Dyn records.
Iterate over them, looking for ones with .d_tag == DT_NEEDED.
Voila.
P.S. There is a bit of a complication: the strings, such as libc.so.6 are not part of the PT_DYNAMIC. But there is a pointer to where they are in the .d_tag == DT_STRTAB entry. See this answer for example code.
I don't know ns 2 has capability to do this but I want to implement store-carry-forward mechanism in ns 2. However, I don't know where to start. Also I don't know what its steps. What protocols this mechanism uses? Is there anybody who can help me?
ns2 + DTN
If you have other ns2 builds / installs : Rename the executable´s ns to a new name → ns-orig, 'ns-app-name', etc. And remove any ns2 *PATH text from .bashrc .
Build ns2 + DTN
tar xvf ns-allinone-2.35_gcc5.tar.gz
https://drive.google.com/file/d/0B7S255p3kFXNVVlxR0ZNRGVORjQ/view?usp=sharing
cd ns-allinone-2.35/
zcat dtn_ns235.patch.gz | patch -p0
./install
cd ns-2.35/
sudo make install
Simulation : Copy an example (from ns2dtn_campaign/) to ns-allinone-2.35/, and run ./simulate_dtn.sh. The location is important as this path is used : ../ns-allinone-2.35/dei80211mr-1.1.4/src/.libs/libdei80211mr.so
Example, simulation files (and one empty folder) to be copied : { bundle-test-large-scen.tcl, create-traffic-file.tcl, scen_n40_pt2_ms20_t5000_x2000_y2000, simulate_dtn.sh, Run1/ }.
Please note that the simulation time is an hour (or more).
Watch the trace file qtrace.tr : Will very slowly increase to ~9MB.
Result : ns-allinone-2.35/Run1/{ bundle_delays.tr, qtrace.tr, receipt_delays.tr }. The files can be used with Xgraph.
I am trying to run my IDL programs at home in GDL. Among other problems I run into this one:
GDL> bk=fsc_color('Black')
% Ambiguous: Variable is undefined: FSC_COLOR or: Function not found: FSC_COLOR
% Execution halted at: $MAIN$
Is there a way to get colours by name in GDL?
This sounds like you just haven't put fsc_color.pro in your !path (or the GDL equivalent). FSC_COLOR is not provided by the IDL distribution; you have to install it and tell IDL where it is located.
I have a program (not mine - downloaded from i-net) made on ATI streams (more accurate - on brook lang - file is *.br). There is a python script (see below), that compiles it into *.il file using brook compiler, provided by ATI streams SDK. After it script zips it into *.Z file. C-program's Makefile contains this code
my_kernel_dp11.o: my_kernel_dp11.Z
ld -s -r -o my_kernel_dp11.o -b binary my_kernel_dp11.Z
and then it linked to main executed file.
Data from that obj-file read by C-program into some buffer and then called calclCompile function (as I understand it's OpenCL func).
It works fine at AMD HD 6970-series, but failed at AMD HD 7970-series with following error
Unsupported program construct detected in back-end
Here is a python script
#!/usr/bin/python
import sys
import zlib
import os
def makebrz(dp_bits):
try:
os.unlink("a_slice_dpX_a_slicer.il")
except OSError:
pass
dpdefs=""
for i in range(dp_bits-11):
dpdefs = dpdefs + " -D DP_BIT_%i" % (i+12,)
print "DP_DEFS: ", dpdefs
os.system("/usr/local/atibrook/sdk/bin/brcc -k -pp %s a_slice_dpX.br" % (dpdefs,) )
f = open("a_slice_dpX_a_slicer.il")
if f==None:
print "Could not read ", sys.argv[1]
sys.exit(-1)
data = f.read()
f.close()
oname = "../my_kernel_dp%i.Z" % (dp_bits,)
data2 = zlib.compress(data)
fo = open( oname, "wb" )
fo.write(data2)
fo.close()
#os.system("ld -s -r -o ../%s.o -b binary %s" % (oname[:-2],oname))
makebrz(11)
makebrz(12)
makebrz(13)
makebrz(14)
And here is a program http://dl.dropbox.com/u/46469564/a_slice_dpX.br
The question is: what should I do to make it program "supported" ?
P.S. There is one problem - I don't know this technology (brook, ATI streams, OpenCL) at all. That's why advice like "you should try this or that" are useless. I need particular action to do - change this and you'll have a success :)
Thank you.
AFAIK Radeon HD7970 is built on GCN architecture, so if you are using brook to generate IL code, JIT in southern island may not know how to generate proper ISA for the h/w you are using,so if you would like continue using brook+ then you need to wait till an updated version of Brook+ gets released on sourceforge which can generate an IL which gets converted to right ISA(GCN).
Other option is to use AMD APP SDK 2.6 and rewrite your code in OpenCL.