GO: {GOOS} and {GOARCH} not recognised in environment - command-line

I want to change my diretory to go/pkg/darwin_amd64 but $ cd $GOPATH/pkg/${GOOS}_${GOARCH} doesn't find the folder though directory exists.
$ echo $GOPATH/pkg/${GOOS}_${GOARCH} gives /go/pkg/_ instead of /go/pkg/darwin_amd64.
$ go env prints:
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/sahilkapoor/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
We can see that GOOS and GOARCH are defined here. I am using terminal on Mac OSX 10.10.3. What am I missing?

$GOOS and $GOARCH will only be defined in your shell if you have exported them (which, unless you are doing cross compilation, is unlikely).
When you run go env, default values are shown when they have not been overwritten by your environment. You should change your command to the following to get the desired results:
cd $(go env GOPATH)/pkg/$(go env GOOS)_$(go env GOARCH)

Related

How to use plugin commands in bcftools?

My goal is to use bcftools to check that the reference alleles in my dataset (vcf file) match with a reference genome (fasta file) using the fixref plugin.
Working on command line, I first set the following environment:
export BCFTOOLS_PLUGINS=/path/to/bcftools/plugins
The following code is recommended for test datasets with mismatches:
bcftools +fixref test.bcf -Ob -o output.bcf -- -f ref.fa -m top
When I run this code using my own files (please note that my data is .vcf, not .bcf) I get the following error:
[main] Unrecognized command
If I simply enter:
bcftools
I get a list of the only 5 commands (view, index, cat, ld, ldpair) that I can use. So although I've set the environment, does it somehow need to be activated? Do I need to run my command through a bash script?
bcftools
was pointing to a deprecated version of bcftools (0.1.19) in ../bin/, while
BCFTOOLS_PLUGINS=/path/to/bcftools/plugins
was pointing to the plugins for bcftools version 1.10.2 outside /bin/
Replacing ../bin/bcftools (0.1.19 with 1.10.2) was the fix.

Buildroot Config Option for applying custom patch

I am new to buildroot and working to build Linaro with buildroot ..I have multiple fragment kernel config files and specified that in buildroot defconfig.
I have specified a custom kernel patches directory with BR2_LINUX_PATCH_DIR .
I dont have some of the config flags not set which are supposed to be there in the .config files..so i suspect that the Patches are applied successfully..so i tried giving a non existing location as Linux Patch dir and it does not give any error..
Is there anything other than giving value to BR2_LINUX_PATCH_DIR and what should be the format of the dir structure...in buildroot manual it says it should be
Package_name/patch name..For linux what should be the package name? It should be the same with which linux dir is created.for example for me it is linux-custom
Plz suggest and guide me in this.
Thanks in Advance
The option is named BR2_LINUX_KERNEL_PATCH, there is nothing named BR2_LINUX_PATCH_DIR. It applies all patches listed in this option (if those are files), or all files named *.patch if what's given in this option is a directory. See the code in linux/linux.mk:
define LINUX_APPLY_LOCAL_PATCHES
for p in $(filter-out ftp://% http://% https://%,$(LINUX_PATCHES)) ; do \
if test -d $$p ; then \
$(APPLY_PATCHES) $(#D) $$p \*.patch || exit 1 ; \
else \
$(APPLY_PATCHES) $(#D) `dirname $$p` `basename $$p` || exit 1; \
fi \
done
endef
Also, I would recommend that you watch the output of Buildroot: it shows everything it is doing, especially it lists the patches it applied. Look at the line >>> linux .... Patching, which is the marker for the beginning of the patching step of the linux package.

How can I change the installation path of an autotools-based Bitbake recipe?

I have an autotools-based BitBake recipe which I would like to have binaries installed in /usr/local/bin and libraries installed in /usr/local/lib (instead of /usr/bin and /usr/lib, which are the default target directories).
Here's a part of the autotools.bbclass file which I found important.
CONFIGUREOPTS = " --build=${BUILD_SYS} \
--host=${HOST_SYS} \
--target=${TARGET_SYS} \
--prefix=${prefix} \
--exec_prefix=${exec_prefix} \
--bindir=${bindir} \
--sbindir=${sbindir} \
--libexecdir=${libexecdir} \
--datadir=${datadir} \
--sysconfdir=${sysconfdir} \
--sharedstatedir=${sharedstatedir} \
--localstatedir=${localstatedir} \
--libdir=${libdir} \
...
I thought that the easiest way to accomplish what I wanted to do would be to simply change ${bindir} and ${libdir}, or perhaps change ${prefix} to /usr/local, but I haven't had any success in this area. Is there a way to change these installation variables, or am I thinking about this in the wrong way?
Update:
Strategy 1
As per Ross Burton's suggestion, I've tried adding the following to my recipe:
prefix="/usr/local"
exec_prefix="/usr/local"
but this causes the build to fail during that recipe's do_configure() task, and returns the following:
| checking for GLIB... no
| configure: error: Package requirements (glib-2.0 >= 2.12.3) were not met:
|
| No package 'glib-2.0' found
This package can be found during a normal build without these modified variables. I thought that adding the following line might allow the system to find the package metadata for glib:
PKG_CONFIG_PATH = " ${STAGING_DIR_HOST}/usr/lib/pkgconfig "
but this seems to have made no difference.
Strategy 2
I've also tried Ross Burton's other suggestion to add these variable assignments into my distribution's configuration file, but this causes it to fail during meta/recipes-extended/tzdata's do_install() task. It returns that DEFAULT_TIMEZONE is set to an invalid value. Here's the source of the error from tzdata_2015g.bb
# Install default timezone
if [ -e ${D}${datadir}/zoneinfo/${DEFAULT_TIMEZONE} ]; then
install -d ${D}${sysconfdir}
echo ${DEFAULT_TIMEZONE} > ${D}${sysconfdir}/timezone
ln -s ${datadir}/zoneinfo/${DEFAULT_TIMEZONE} ${D}${sysconfdir}/localtime
else
bberror "DEFAULT_TIMEZONE is set to an invalid value."
exit 1
fi
I'm assuming that I've got a problem with ${datadir}, which references ${prefix}.
Do you want to change paths for everything or just one recipe? Not sure why you'd want to change just one recipe to /usr/local, but whatever.
If you want to change all of them, then the simple way is to set prefix in your local.conf or distro configuration (prefix = "/usr/local").
If you want to do it in a particular recipe, then just assigning prefix="/usr/local" and exec_prefix="/usr/local" in the recipe will work.
These variables are defined in meta/conf/bitbake.conf, where you can see that bindir is $exec_prefix/bin, which is probably why assigning prefix didn't work for you.
Your first strategy was on the right track, but you were clobbering more than you wanted by changing only "prefix". If you look in sources/poky/meta/conf/bitbake.conf you'll find everything you are clobbering when you set the variable "prefix" to something other than "/usr" (like it was in my case). In order to modify only the install path with what would manually be the "--prefix" option to configure, I needed to set all the variables listed here in that recipe:
prefix="/your/install/path/here"
datadir="/usr/share"
sharedstatedir="/usr/com"
exec_prefix="/usr"

running PostgreSQL client in C from Cygwin

I'm trying to build a very simple PostgreSQL client in C over Cygwin.
Here's what I've done so far:
I've downloaded the PostgreSQL source code version 9.1.2 (to match the same version that is running on my server)
I've configured and compiled the source code from Cygwin. The compilation seemed to go smoothly.
From what I can tell, the header files are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq, and
/cygdrive/c/workspace/src/postgresql-9.1.2/src/include
The libraries are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
From here, I compiled and linked the client program using the makefile below:
testlibpq: testlibpq.c
gcc -o testlibpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/include -L /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq testlibpq.c -Bstatic -lpq
The compilation and the linking succeeded without errors or warnings.
However, when I try to run the program, I get the following error:
$ ./testlibpq
/cygdrive/c/Users/dleclair/Dropbox/denis/src/testlibpq/testlibpq.exe: error while loading shared libraries: cygpq.dll: cannot open shared object file: No such file or directory
I haven't figured out how to fix this. Any pointers would be greatly appreciated.
Oh, one more thing, I found the folder that cygpq.dll was sitting in and set my LD_LIBRARY_PATH to point to it but it still gave me the same result.
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ ls /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
bcc32.mak encnames.o fe-connect.o fe-misc.o fe-protocol3.o ip.o libpq-events.c md5.c pgstrcasecmp.c pqsignal.c thread.o
blibpqdll.def exports.txt fe-exec.c fe-print.c fe-secure.c libpq.a libpq-events.h md5.o pgstrcasecmp.o pqsignal.h wchar.c
chklocale.c fe-auth.c fe-exec.o fe-print.o fe-secure.o libpq.rc.in libpq-events.o nls.mk po pqsignal.o wchar.o
chklocale.o fe-auth.h fe-lobj.c fe-protocol2.c inet_net_ntop.c libpqddll.def libpq-fe.h noblock.c pqexpbuffer.c pthread-win32.c win32.c
cygpq.dll fe-auth.o fe-lobj.o fe-protocol2.o inet_net_ntop.o libpq-dist.rc libpq-int.h noblock.o pqexpbuffer.h README win32.h
encnames.c fe-connect.c fe-misc.c fe-protocol3.c ip.c libpqdll.def Makefile pg_service.conf.sample pqexpbuffer.o thread.c win32.mak
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ echo $LD_LIBRARY_PATH
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
Normally on unix/linux systems after building the source a make install is done which copies the headers to standard locations like /usr/local/include and /usr/local/lib. You may have to do that on cygwin to to get the DLL in the search path.
Or you can just locate the DLL yourself and put it on the search path or in the same folder as your executable.

How to install a terminfo entry (eterm-color from Emacs)?

I want to run GNU Screen from within an Emacs term-mode buffer. When I try to do this I get an error:
$ screen
Cannot find terminfo entry for 'eterm-color'.
This error suggests that I should install the eterm-color terminfo entry. I attempted to do this in 2 ways which both failed.
The first attempt was to use the TERMINFO environment variable.
My .bashrc:
export TERMINFO=~/.terminfo
Then I did:
$ mkdir -p ~/.terminfo/e/
$ cp /usr/local/Cellar/emacs/23.3a/share/emacs/23.3/etc/e/* ~/.terminfo/e/
In the term-mode buffer the eterm-color entry is not found. It says that it gets eterm-color from TERMCAP instead of from the actual file.
$ infocmp
# Reconstructed via infocmp from file: TERMCAP
eterm-color,
am, mir, xenl,
colors#8, cols#138, it#8, lines#41, pairs#64,
bel=^G, bold=\E[1m, clear=\E[H\E[J, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
el=\E[K, el1=\E[1K, home=\E[H, ht=^I, ich=\E[%p1%d#,
il=\E[%p1%dL, il1=\E[L, ind=^J, invis=\E[8m, kbs=\177,
kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\E[4~, khome=\E[1~, knp=\E[6~, kpp=\E[5~,
nel=^M^J, op=\E[39;49m, rc=\E8, rev=\E[7m, rmir=\E[4l,
rmso=\E[27m, rmul=\E24m, rs1=\Ec, sc=\E7, setab=\E[4%p1%dm,
setaf=\E[3%p1%dm, sgr0=\E[m, smir=\E[4h, smso=\E[7m,
smul=\E[4m,
The second attempt was to use symlinks.
$ sudo mkdir /usr/share/terminfo/e/
$ sudo cp /usr/local/Cellar/emacs/23.3a/share/emacs/23.3/etc/e/* /usr/share/terminfo/e/
This failed in the same way as the first attempt.
Why did neither attempt work? How do I get the eterm-color terminfo entry installed?
I am running OS X 10.6.8 and Emacs 23.3.1.
The following worked for me on FreeBSD.
Put the termcap entry pasted below in /usr/share/misc/termcap and run # cd /usr/share/misc/ && cap_mkdb termcap.
# Termcap entry for eterm-color (taken from $TERMCAP set by emacs and formatted)
eterm-color|Emacs term.el terminal emulator term-protocol-version 0.96:\
:am:bs:mi:pt:xn:\
:Co#8:co#166:li#48:pa#64:\
:#7=\E[4~:AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:\
:DL=\E[%dM:DO=\E[%dB:IC=\E[%d#:LE=\E[%dD:RI=\E[%dC:\
:UP=\E[%dA:al=\E[L:bl=^G:cb=\E[1K:cd=\E[J:ce=\E[K:\
:cl=\E[H\E[J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:dc=\E[P:\
:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:kD=^[[3~:\
:kN=\E[6~:kP=\E[5~:kb=^?:kd=\EOB:kh=\E[1~:kl=\EOD:\
:kr=\EOC:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mk=\E[8m:mr=\E[7m:\
:nd=\E[C:op=\E[39;49m:r1=\Ec:rc=\E8:sc=\E7:se=\E[27m:sf=^J:\
:so=\E[7m:ta=^I:ue=\E[m:\
:up=\E[A:us=\E[4m: