Kitty terminal needs harfbuzz - path

I compiled harfbuzz 7.0.0 on Ubuntu 22.04 ok.
I want to install latest kitty terminal (0.27.1) where harfbuzz >= 1.5 is required.
Kitty did not find harfbuzz 7.0.0
When I typed "make" for Kitty, i get a system exit telling me that harfbuzz >= 1.5 is required and that the version is not found.
I typed "export PKG_CONFIG_PATH=/home/user/harfbuzz/harfbuzz-7.0.0/src" since that is where 'harfbuzz.pc' resides.
harbuzz is still not found when typing 'make' in the kitty directory.
Alternative solution implemented (worked ok): "curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin"

Related

How to read the interface name from a .pcapng file using tshark?

I am trying to run this tshark command :
tshark -r $file -T fields -E separator=/t -e frame.number -e frame.time -e frame.protocols -e frame.len -e frame.interface_id -e frame.interface_name
I get this warning :
** (process:30955): WARNING **: 'frame.interface_name' isn't a valid field!
tshark: Some fields aren't valid
But I am able to see the field when I open the file in Wireshark ?
What is the right way to access the interface_name info?
I am using the following tshark version -
TShark 1.12.1 (Git Rev Unknown from unknown)
Copyright 1998-2014 Gerald Combs <gerald#wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GLib 2.32.4, with libpcap, with libz 1.2.7, with POSIX
capabilities (Linux), with libnl 3, with SMI 0.4.8, with c-ares 1.9.1, with Lua
5.2, without Python, with GnuTLS 2.12.20, with Gcrypt 1.5.0, with MIT Kerberos,
with GeoIP.
Running on Linux 3.16.7-cb2000v1, with locale en_US.UTF-8, with libpcap version
1.3.0, with libz 1.2.7.
Intel(R) Xeon(R) CPU E5-2640 v4 # 2.40GHz
Built using gcc 4.7.2.
I tried updating wireshark -
$ sudo apt-get install wireshark
Reading package lists... Done
Building dependency tree
Reading state information... Done
wireshark is already the newest version.
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
isc-dhcp-relay : Depends: isc-dhcp-common (= 4.2.2.dfsg.1-5+deb70u8) but 4.2.2.dfsg.1-5+deb70u8 is to be installed
isc-dhcp-server : Depends: isc-dhcp-common (= 4.2.2.dfsg.1-5+deb70u8) but 4.2.2.dfsg.1-5+deb70u8 is to be installed
libsnmp-perl : Depends: perl (>= 5.14.2-21+deb7u5) but 5.14.2-21+deb7u3 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
It says wireshark is already the newest version.
This is the linux OS details of the machine :
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy
Which version of tshark are you using? Run tshark -v to check.
The frame.interface_name display filter is only available beginning with version 2.4.0, so maybe you have an older version of tshark in your %PATH%?
Note that you can check for the availability of any display filter on the Wireshark Display Filter Reference Page.

ejabber's erl file give error "segmentation fault: 11" while running on mac os 10.7.5

I am trying to start ejabber 16.05 server on mac os 10.7.5. while starting up, it gives error. on further investigation, I found that "erl" executor file shipped with ejabber is throwing "Segmentation Fault:11" while running independently. I firmly believe that resolving issue with "erl" file execution will solve server start up issue. can anyone please help. Below is the code from "erl" that is causing segmentation fault error
#!/bin/sh
ROOTDIR=/Applications/ejabberd-15.06
export ROOTDIR
BINDIR=$ROOTDIR/bin
export BINDIR
EMU=beam
export EMU
PROGNAME=$BINDIR/erl
export PROGNAME
PATH=$BINDIR:$PATH
export PATH
arch() {
case `uname -m` in
i[3456]86 ) echo x86 ;;
i86pc) echo x86 ;;
armv7*) echo armhf ;;
arm*l) echo armel ;;
* ) echo `uname -m | tr A-Z a-z` ;;
esac
}
os=`uname -s | tr A-Z a-z`
cpu=`arch`
ARCHDIR=${os}-${cpu}
export ARCHDIR
# Dynamic libraries
LD_LIBRARY_PATH=$ROOTDIR/lib/$ARCHDIR
export LD_LIBRARY_PATH
DYLD_LIBRARY_PATH=$LD_LIBRARY_PATH
export DYLD_LIBRARY_PATH
exec $BINDIR/erlexec ${1+"$#"}
I just see that you are using OSX 10.7. We do not test ejabberd binary installer on version of OS that are so old.
I do not even expect the binary installer to run on such an old release.
If you have to run ejabberd on that OSX version, you have to build it from source.
ejabberd source are available on official ejabberd Github.
Documentation for installation and build is here Installing ejabberd from source code.

Can't compile CUDA samples: ld: library not found for -lgomp clang: error: linker command failed with exit code 1 [duplicate]

I'm trying to get openmp to run in my program on Mavericks, however when I try to compile using the flag -fopenmp I get the following error:
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The command I am running is:
gcc myProgram.cpp -fopenmp -o myProgram
Also, when I run gcc I get Clang warnings which I find to be very strange. And looking into /usr/bin/gcc it does not appear to link to Clang.
Any suggestions on how to fix my Clang errors and get openmp to compile?
The gcc command in the latest Xcode suite is no longer the GCC frontend to LLVM (based on the very old GCC 4.2.1) but rather a symlink to clang. Clang does not (yet) support OpenMP. You have to install separately another version of GCC, e.g. by following this tutorial or by using any of the available software package management systems like MacPorts and Homebrew.
I just recently attacked this problem and have scripted the process of getting everything working based on the official instructions.
The script will download everything into ~/code for easy maintenance and will append the correct environment variables to your ~/.profile file. For advanced users, pick a nice location you want the lib, bin and include installed and move them manually. The script depends on knowing the latest OpenMP runtime from Intel, which can be altered at the top of the script.
The script should work out of the box with vanilla Mavericks, except for one small problem. In the OpenML runtime make script, it does not reliably accept clang when specified and continues with the default GCC. As such, if you don't have GCC installed (which is not normal on out of the box Mavericks), it will fail to build. To fix this, you must comment out two lines (as noted in the script) based on the libomp_20131209_oss.tgz build of OpenMP. Newer builds of OpenML might break this script, so use at your own peril on newer versions.
Simply save this script into a file, run 'chmod +x filename.sh', and run './filename.sh' from terminal. It will take a while to build LLVM and Clang, so be patient.
EDIT: This script will most likely fail on Yosemite and I am having issues using the built clang2 after the update to the dev builds of OSX 10.10.
INTEL_OPENMP_LATEST_BUILD_LINK=https://www.openmprtl.org/sites/default/files/libomp_20131209_oss.tgz
DEST_FOLDER = ~/code
CLANG_INCLUDE=${DEST_FOLDER}/llvm/include
CLANG_BIN=${DEST_FOLDER}/llvm/build/Debug+Asserts/bin
CLANG_LIB=${DEST_FOLDER}/llvm/build/Debug+Asserts/lib
OPENMP_INCLUDE=${DEST_FOLDER}/libomp_oss/exports/common/include
OPENMP_LIB=${DEST_FOLDER}/libomp_oss/exports/mac_32e/lib.thin
mkdir ${DEST_FOLDER}
cd ${DEST_FOLDER}
git clone https://github.com/clang-omp/llvm
git clone https://github.com/clang-omp/compiler-rt llvm/projects/compiler-rt
git clone -b clang-omp https://github.com/clang-omp/clang llvm/tools/clang
cd llvm
mkdir build
cd build
../configure
make
cd Debug+Asserts/bin
mv clang clang2
rm -rf clang++
ln -s clang2 clang2++
echo "LLVM+Clang+OpenMP Include Path : " ${CLANG_INCLUDE}
echo "LLVM+Clang+OpenMP Bin Path : " ${CLANG_BIN}
echo "LLVM+Clang+OpenMP Lib Path : " ${CLANG_LIB}
cd ${DEST_FOLDER}
curl ${INTEL_OPENMP_LATEST_BUILD_LINK} -o libomp_oss_temp.tgz
gunzip -c libomp_oss_temp.tgz | tar xopf -
rm -rf libomp_oss_temp.tgz
cd libomp_oss
echo "You need to do one or two things:"
echo "1.) [Required] Comment out line 433 from libomp_oss/src/makefile.mk"
echo "2.) [Optional] If you do not have GCC installed (not normal on vanilla Mavericks), you must comment out lines 450-451 in libomp_oss/tools/check-tools.pl. Have you done this or want to compile anyway?"
select yn in "Yes" "No"; do
case $yn in
Yes ) make compiler=clang; break;;
No ) exit;;
esac
done
echo "OpenMP Runtime Include Path : " ${OPENMP_INCLUDE}
echo "OpenMP Runtime Lib Path : " ${OPENMP_LIB}
(echo 'export PATH='${CLANG_BIN}':$PATH';
echo 'export C_INCLUDE_PATH='${CLANG_INCLUDE}':'${OPENMP_INCLUDE}':$C_INCLUDE_PATH';
echo 'export CPLUS_INCLUDE_PATH='${CLANG_INCLUDE}':'${OPENMP_INCLUDE}':$CPLUS_INCLUDE_PATH';
echo 'export LIBRARY_PATH='${CLANG_LIB}':'${OPENMP_LIB}':$LIBRARY_PATH';
echo 'export DYLD_LIBRARY_PATH='${CLANG_LIB}':'${OPENMP_LIB}':$DYLD_LIBRARY_PATH}') >> ~/.profile
source ~/.profile
echo "LLVM+Clang+OpenMP is now accessible through [ clang2 ] via terminal and does not conflict with Apple's clang"
If you are running homebrew you can fix this problem by calling:
brew install clang-omp
The compiler will be available under clang-omp++ name
Just worked through this problem. Here's the answer plus how to get it worked with Xcode.
Grab the latest version of openMP runtime library from
https://www.openmprtl.org/download
unzip and compile it by
mkdir build && cd build && cmake .. && make && sudo make install
install it by
sudo cp ./libiomp5.dylib /usr/lib/
sudo cp ./omp.h /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/
Grab openmp/clang from Git following the instructions on http://clang-omp.github.io/
compile openmp/clang
cd llvm && mkdir build && cd build && ../configure --enable-optimized && make -j
sudo make install
normally it would install clang/clang++ into /usr/local/bin, we need replace the Apple clang with our version
cd /usr/bin
sudo mv clang clang-apple
sudo mv clang++ clang++-apple
sudo ln -s /usr/local/bin/clang ./clang
sudo ln -s /usr/local/bin/clang++ ./clang++
cd /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
sudo mv clang clang-apple
sudo mv clang++ clang++-apple
sudo ln -s /usr/local/bin/clang ./clang
sudo ln -s /usr/local/bin/clang++ ./clang++
cd /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
sudo mv -f * ../../
Create a project in Xcode, using the Hello World code on clang-openmp website for test. After created, add "-fopenmp" to Custom Compiler Flags -> Other C Flags in project settings; add /usr/lib/libiomp5.dylib to the build phases of project (project settings -> Build Phases -> Drag /usr/lib/libiomp5.dylib into Link Binary with Libraries)
It should work. Yosemite + Xcode 6 is tested.
Note: the custom clang is NOT as stable as Apple's. Switch back if you meet strange instruction error after compiled.

image::magick not installing with cpan in perl v5.14.2 from dwimperl

I am attempting to rebuild my development/test environment on a new laptop running windows7 32 bit. imageMagick is one of the modules I had installed in an (ancient) version on my old laptop. I have downloaded and installed perl from dwimperl, which is v5.14.2 and had a couple modules install, and several did not.
cpanm Image::Magick - failed
cpanm DB_File - failed
cpanm Time::HiRes - failed
I searched around and found a discussion on magick failing to install on v5.12, but couldn't tell if that was supposed to have been fixed, or if I need to attempt to recreate the fix discussed for 5.12
should I try installing perl from Strawberry? looks like it is a little newer v5.18 ?
is there something I can tweak and re-run cpan installs?
I installed the binaries from imagemagick, from Link first, then cpan again, and cpan still fails....
This is the top part of the build log down to where it really goes south and starts kicking out errors:
cpanm (App::cpanminus) 1.6941 on perl 5.014002 built for MSWin32-x86-multi-thread
Work directory is C:\Users\dtbaker/.cpanm/work/1377281741.8420
You have make C:\Dwimperl\c\bin\dmake.exe
You have LWP 6.03
Falling back to Archive::Tar 1.80
Searching Image::Magick on cpanmetadb ...
--> Working on Image::Magick
Fetching http://www.cpan.org/authors/id/J/JC/JCRISTY/PerlMagick-6.86.tar.gz
-> OK
Unpacking PerlMagick-6.86.tar.gz
Entering PerlMagick-6.86
META.yml/json not found. Creating skelton for it.
Configuring PerlMagick-6.86
Running Makefile.PL
################################### WARNING! ###################################
# It seems that you are trying to install Perl::Magick on a MS Windows box with
# perl + gcc compiler (e.g. strawberry perl), however we cannot find ImageMagick
# binaries installed on your system.
#
# Please check the following prerequisites:
#
# 1) You need to have installed ImageMagick Windows binaries from
# http://www.imagemagick.org/script/binary-releases.php#windows
#
# 2) We only support dynamic (DLL) ImageMagick binaries
# note: it is not possible to mix 32/64-bit binaries of perl and ImageMagick
#
# 3) During installation select that you want to install ImageMagick's
# development files (libraries+headers)
#
# 4) You also need to have ImageMagick's directory in your PATH
# note: we are checking the presence of convert.exe and/or identify.exe tools
#
# 5) You might need Visual C++ Redistributable Package installed on your system
# see instructions on ImageMagick's Binary Release webpage
#
# We are gonna continue, but chances for successful build are very low!
################################################################################
Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lMagickCore-6.Q16
Writing Makefile for Image::Magick
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.62)
Building and testing Image-Magick-6.86
cp Magick.pm blib\lib\Image\Magick.pm
AutoSplitting blib\lib\Image\Magick.pm (blib\lib\auto\Image\Magick)
C:\Dwimperl\perl\bin\perl.exe C:\Dwimperl\perl\lib\ExtUtils\xsubpp -typemap C:\Dwimperl\perl\lib\ExtUtils\typemap -typemap typemap Magick.xs > Magick.xsc && C:\Dwimperl\perl\bin\perl.exe -MExtUtils::Command -e mv -- Magick.xsc Magick.c
gcc -c -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"6.86\" -DXS_VERSION=\"6.86\" "-IC:\Dwimperl\perl\lib\CORE" -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
Magick.xs:60:31: error: magick/MagickCore.h: No such file or directory
Magick.xs:167: error: expected specifier-qualifier-list before 'MagickRealType'
Magick.xs:188: error: expected specifier-qualifier-list before 'ImageInfo'
Magick.xs:210: error: 'MagickNoiseOptions' undeclared here (not in a function)
however we cannot find ImageMagick binaries installed on your system.
Is ImageMagick is in your path, as recommanded in the 4) point? Open cmd.exe and type convert -v or convert.exe -v. If you don't see informations about Image Magick (Windows have a built-in convert command), it is very likely you have to add it to your path.
You also have to check points 1), 3), and 5). After that try again to run installation process through cpanm.
Trying to install for Citrus Perl, I discovered on debugging through the Perl part of the install that the mingw64 install had not included 'pexports.exe'. Downloading that from https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/
and placing it in the mingw64 directory was necessary to solve the problem of a long list of library export symbols not found.
Prior to that I had also set the environment variables CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH to point to the "include" directory of the ImageMagick install include directory in C:\Program Files (x86). (When you install ImageMagick you should check the box to install also for Strawberry Perl.)

Errors due to vowpal wabbit's dependencies on boost library

I'm trying real hard to install vowpal wobbit and it fails when i run the make file, throwing:
cd library; make; cd ..
g++ -g -o ezexample temp2.cc -L ../vowpalwabbit -l vw -l allreduce -l boost_program_options -l z -l pthread
ld: library not found for -lboost_program_options collect2: ld returned 1 exit status make[1]: *** [ezexample] Error 1'
I then added the links to the boost library here by specifying -L/usr/local/lib
Now I get the following error:
g++ -g -o ezexample temp2.cc -L/usr/local/lib ../vowpalwabbit -l vw -l allreduce -l boost_program_options -l z -l pthread
ld: library not found for -lvw
collect2: ld returned 1 exit status
make: *** [ezexample] Error 1
I happened to get everything working on OS X 10.7 as follows:
Make sure you have a working Boost installation. As indicated on the Getting started page, usually we only need header files, but some Boost libraries must be built separately, including the program_options library which is used to process options from command line or config file. Go into your boost folder, and then at your shell prompt:
$ ./bootstrap.sh
$ ./bjam
This will compile and build everything. You should now have a bin.v2/ directory in your boost directory, with all built libraries for your system (static and threaded libs).
$ ls bin.v2/libs/
date_time iostreams python serialization test
filesystem math random signals thread
graph program_options regex system wave
More importantly, extra Boost libraries are made available in the stage/lib/ directory. For me, these are Mach-O 64-bit dynamically linked shared library x86_64.
The include path should be your_install_dir/boost_x_xx_x, where boost_x_xx_x is the basename of your working Boost. (I personally have boost_1_46_1 in /usr/local/share/ and I symlinked it to /usr/local/share/boost to avoid having to remember version number.) The library path (for linking) should read your_install_dir/boost_x_xx_x/stage/lib. However, it might be best to symlink or copy (which is what I did) everything in usual place, i.e. /usr/local/include/boost for header files, and /usr/local/lib for libraries.
Edit the Makefile from the vowpal_wabbit directory, and change the include/library paths to reflect your current installation. The Makefile should look like this (first 12 lines):
COMPILER = g++
UNAME := $(shell uname)
ifeq ($(UNAME), FreeBSD)
LIBS = -l boost_program_options -l pthread -l z -l compat
BOOST_INCLUDE = /usr/local/include
BOOST_LIBRARY = /usr/local/lib
else
LIBS = -l boost_program_options -l pthread -l z
BOOST_INCLUDE = /usr/local/share/boost # change path to reflect yours
BOOST_LIBRARY = /usr/local/share/boost/stage/lib # idem
endif
Then, you are ready to compile vowpal_wabbit (make clean in case you already compiled it):
$ make
$ ./vw --version
6.1
$ make test
You can also install vowpal wabbit on OS X using brew:
brew install vowpal-wabbit
Or you can just install boost, and then install vw from the github repo.
brew install boost
For installation on CentOS 7 (6.5 perl version is too old for latest vw source code), I've found the instructions at http://wkoplitz.blogspot.be/2012/12/vowpal-wabbit-on-centos.html to work fine:
yum install zlib-devel boost-devel
yum groupinstall "Development Tools"
git clone git://github.com/JohnLangford/vowpal_wabbit.git
cd vowpal_wabbit
./autogen.sh
make
make test
Good news:
As of the latest release VowpalWabbit version 9.1.0, vw no longer relies on Boost program_options
From the release highlights:
Removal of Boost Program Options dependency
For a long time we have depended on Boost Program Options
for command line options parsing. In this release, we have > replaced this dependency with our own implementation of
command line parsing. Apart from one place where we depend > on Boost Math in standalone mode, this means that VW core
and the command line tool are free of Boost dependencies
hopefully making the code a bit easier to build and package.
Vowpal Wabbit 9.1.0 release notes

Resources