Thursday, March 13, 2014

[Cross-Compile] What's the difference of `./configure` option `--build`, `--host` and `--target`?

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/lib and
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.

Wednesday, March 12, 2014

[NETCONF] The summary of NETCONF Content

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">

Protocol Capabilities



Standard Capabilities


Configuration Databases


Protocol Operations

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:baseTerminate this session
commit:base AND :candidateCommit the contents of the <candidate/> configuration database to the <running/> configuration database
copy-config:baseCopy a configuration database
create-subscription:notificationCreate a NETCONF notification subscription
delete-config:baseDelete a configuration database
discard-changes:base AND :candidateClear all changes from the <candidate/> configuration database and make it match the <running/> configuration database
edit-config:baseModify a configuration database
get:baseRetrieve data from the running configuration database and/or device statistics
get-config:baseRetrieve data from the running configuration database
kill-session:baseTerminate another session
lock:baseLock a configuration database so only my session can write
unlock:baseUnlock a configuration database so any session can write
validate:base AND :validateValidate the entire contents of a configuration database