When using ./configure especially in cross-compiling purpose, I kind of confuse about the option --build and --host so that the following content is what I found on searching:
some remarks on specifying --host=<host>, --target=<target> and --build=<build
# kindly provided by Keith Marshall:
# 1) build
# this is *always* the platform on which you are running the build
# process; since we are building on Linux, this is unequivocally going to
# specify `linux', with the canonical form being `i686-pc-linux-gnu'.
# 2) host
# this is a tricky one: it specifies the platform on which whatever we
# are building is going to be run; for the cross-compiler itself, that's
# also `i686-pc-linux-gnu', but when we get to the stage of building the
# runtime support libraries to go with that cross-compiler, they must
# contain code which will run on the `i686-pc-mingw32' host, so the `host'
# specification should change to this, for the `runtime' and `w32api'
# stages of the build.
# 3) target
# this is probably the one which causes the most confusion; it is only
# relevant when building a cross-compiler, and it specifies where the code
# which is built by that cross-compiler itself will ultimately run; it
# should not need to be specified at all, for the `runtime' or `w32api',
# since these are already targetted to `i686-pc-mingw32' by a correct
# `host' specification.
And I found an answer after posting this question.. Still posting it here in case it helps someone else in the future.
As per this blog in my case
build will be i686-pc-linux-gnu ( My PC)
host will be mipsel-linux ( The platform I am going to run my code on)
target will be used if I am building a cross-compiling toolchain.
Since I am not building a toolchain, I didnt have to specify target.
You will have to cross-compile libusb and then copy the library and
header files to a location where your toolchain can locate them. In
the case of CodeSourcery, you can put them in
cs_root/arm-none-linux-gnueabi/include for example. You will also need
the library on the target's root filesystem unless you link it
statically, please mind the licencing implications if you do though.
Thursday, March 13, 2014
Wednesday, March 12, 2014
The following content is about the summary of the NET-CONF web site:
Session Initiation For Clients
<?xml version="1.0" encoding="UTF-8"?> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> </capabilities> </hello>]]>]]>
<capability> urn:ietf:params:netconf:capability:writable-running:1.0 </capability>
Once a NETCONF session is established, the client knows which capabilities the server supports. The client then can send RPC method requests and receive RPC replies from the server. The server's request queue is serialized, so requests will be processed in the order received.
|close-session||:base||Terminate this session|
|commit||:base AND :candidate||Commit the contents of the <candidate/> configuration database to the <running/> configuration database|
|copy-config||:base||Copy a configuration database|
|create-subscription||:notification||Create a NETCONF notification subscription|
|delete-config||:base||Delete a configuration database|
|discard-changes||:base AND :candidate||Clear all changes from the <candidate/> configuration database and make it match the <running/> configuration database|
|edit-config||:base||Modify a configuration database|
|get||:base||Retrieve data from the running configuration database and/or device statistics|
|get-config||:base||Retrieve data from the running configuration database|
|kill-session||:base||Terminate another session|
|lock||:base||Lock a configuration database so only my session can write|
|unlock||:base||Unlock a configuration database so any session can write|
|validate||:base AND :validate||Validate the entire contents of a configuration database|
NETCONF and Yang
NETCONF and Yang