cannot locate -lpaho-mqttpp3 when attempting to compile paho mqtt cpp samples - makefile

As per title I'm having problems running the Makefile located in
org.ecliplse.paho.mqtt.cpp/src/samples
I understand the C++ library requires the C library to be correctly installed. To do so I followed the documentation
and in /usr/local/lib I'm able to locate
libpaho-mqtt3a.so
libpaho-mqtt3a.so.1
libpaho-mqtt3a.so.1.0
libpaho-mqtt3as.so
libpaho-mqtt3as.so.1
libpaho-mqtt3as.so.1.0
libpaho-mqtt3c.so
libpaho-mqtt3c.so.1
libpaho-mqtt3c.so.1.0
libpaho-mqtt3cs.so
libpaho-mqtt3cs.so.1
libpaho-mqtt3cs.so.1.0
am I missing something on the installation of the C library? should lpaho-mqttpp3 be produced at that stage?
please help

Received this answer from Google Groups
Yes, apologies, we're currently working on the build system for the C++ library. All the libraries that you see in the /usr/local/lib are the Paho C libraries. The C++ library produces a single library, libpaho-mqttpp, when you build from the top-level cpp workspace. That's the file that is missing.
The GitHub 'develop' branch is in flux at the moment, as we proceed to a 1.0 release of the C++ library, but has a number of updates that might be helpful, particularly a "make install" build target. To get this, clone the latest GitHub repo and then checkout the 'develop' branch:
$ git clone https://github.com/eclipse/paho.mqtt.cpp.git
$ cd paho.mqtt.cpp
$ git checkout develop
$ make
$ sudo make install
$ make samples
That get you going for now. Look for a stable 'master' in a few weeks time.
Frank Pagliughi

Related

How to install golang-libguestfs package?

I am trying to install the libguestfs package for golang but couldn't find the way to do so. I went through this but it didn't work for me and I believe it's empty. I see only test files here
Following is the content of the README
$GOPATH
-------
http://golang.org/doc/code.html
Note that $GOPATH is set (by the ./run script) to the
libguestfs/golang directory so that "installs" happen in the local
build tree.
From this I could figure out that I need to build the package but again for that, I couldn't find some help or proper document.
Is there any way to do the installation? I am using RHEL 7.7
Libguestfs (the C library) is packaged already in RHEL 7, so I would suggest first of all installing that using yum install libguestfs. That's the version that Red Hat supports.
We don't ship the golang bindings, not even in RHEL 8. Furthermore the bindings in all languages are generated from a mechanical description of the API and thus not stored directly inside our git repository. That's why you could only find test files in git.
However we do distribute the generated files in the tarballs, so an easy way is to grab the latest tarball from https://download.libguestfs.org/1.42-stable/ and look in the golang/src/libguestfs.org/guestfs subdirectory of the tarball.
The harder way is to generate them from git. These steps worked for me on RHEL 7.7, YMMV:
sudo yum-builddep libguestfs
git clone https://github.com/libguestfs/libguestfs
cd libguestfs
git submodule init
git submodule update
./bootstrap
./autogen.sh SUPERMIN=/usr/bin/supermin5
make
and again look in the golang/ subdirectory.
I'm reasonably sure that golang bindings from one version should work with another version of the C library. We did test this at one point in time, so if it's no longer true then it may have regressed as these things sometimes do.

Get travisCI build environment working for netcdf-dependent Fortran built in R package

The title should have two subtitles:
What is the pathname to any installed libraries in the Travis CI environment?
or
How do I get my Makevars file portable for NetCDF libraries??
Background:
I am developing and R package that is supposed to work with a shared library I have written in Fortran. I want to check my builds with TravisCI, so my package is currently on GitHub.
So upon package installation, the Fortran source code should be compiled. I can do this locally, but TravisCI errors with the following message:
gfortran -fdefault-real-8 -c HANDLE_ERR.f90
HANDLE_ERR.f90:4: Error: Can't open included file 'netcdf.inc'
make: *** [HANDLE_ERR.o] Error 1
Which I understand as the compiler not finding the NetCDF library, which I made sure I installed by adding this to my .travis.yml:
before_install:
- sudo apt-get install libnetcdf-dev -y
Example
I have created a minimal working example, which is failing in TravisCI, with the error message (above) I am getting on my big project.
See here for the travis build https://travis-ci.org/teatree1212/nctest
you can access my minimal working example repository from there, but here is the link as well: https://github.com/teatree1212/nctest/tree/master
The compilation works when I do it locally, as I can specify the NetCDF library directories. I don't know where these are installed in the Travis build environment, so I think this is where my problem lies at the moment.
However, I would like to make this package portable and not only make it work in the travis container. Therefore these two questions:
What is the pathname to any installed libraries in the Travis CI environment?
and more importantly:
How do I make my Makevars file portable for compiling with NetCDF libraries?

How to build Courguette in Debian

Right now I am trying to compile Courguette in order to generate a diff patch. The source and some documentation can be found in the following link:
Courguette
I downloaded it but I don't find the way of compiling it.
I have Googled and found some references even to this forum, such as:
StackOverflow link
And other references:
Chromium Linux build instructions
After reading things about ninja and gpy I decided to install them, but there are not references to a .ninja file. I find a courguette.gyp file but using gpy I neither get it compiled...
I am following the guide they provide:
Installed the depot_tools and added to the path.
gclient runhooks
gclient sync
And when I execute gn gen out/Default it fails with the following message:
gn.py: Could not find gn executable at: ~/binary_diff_tools/courgette-master/courgette/buildtools/linux64/gn
Then I used git to pull from the repository the buildtools, but I get the same result.
Any help will be appreciated.
Best regards,
Iván
Ok... It seems that is needed to install all Chromium dependencies before being able to compile courgette so... it must be done as follows:
Install depot_tools git clone and you will have them installed.
After including the depot_tools in your patch (.profile or .bashsrc for example as indicate the depot_tools installation tutorial) execute fetch chromium ouside the depot_tools folder ( it always failed me when I executed it inside the same folder).
I want to build it in Debian so I have to do "gclient runhooks" instead of the .sh script for Ubuntu.
ninja -C out/Default courgette
You will find the executable in the folder out/Default, so ./courgette and it will indicate you the right parameters in order to generate your patch properly.
Best regards,
Iván.

How to build a package from source?

I'm working on a Windows 7 computer at work and want to use the libpostal package. Unfortunately, it's apparently not available for Windows, so I'm trying to configure it through Cygwin and I'm SO close. The last step is to install snappy from Google. Again, not available on Windows...
My assumption (based on nothing) is that I can just download the tarball and build it from source, right? I tried that, and I think it worked? But a) I don't know how to tell, and b) if it did, I don't know how to tell ./configure in libpostal to find it.
In order to build it from source, I downloaded the tarball and saved it in the folder that Cygwin reads as my home, which is C:\cygwin64\home\brittenb\. From there, I ran bash autogen.sh, which created the ./configure that I needed. So I ran that and while some responses to the checks were no, it seemed to run fine. I then ran make and make install. Nothing seemed out of place, so my assumption is that it did what it was supposed to do. I just have no idea where to go from here.
Here is the output from ls after I run everything:
aclocal.m4 snappy.cc
AUTHORS snappy.h
autogen.sh snappy.lo
autom4te.cache snappy.o
ChangeLog snappy.pc
compile snappy.pc.in
config.guess snappy_unittest.cc
config.h snappy_unittest.exe
config.h.in snappy_unittest-snappy_unittest.o
config.log snappy_unittest-snappy-test.o
config.status snappy-c.cc
config.sub snappy-c.h
configure snappy-c.lo
configure.ac snappy-c.o
COPYING snappy-internal.h
depcomp snappy-sinksource.cc
format_description.txt snappy-sinksource.h
framing_format.txt snappy-sinksource.lo
INSTALL snappy-sinksource.o
install-sh snappy-stubs-internal.cc
libsnappy.la snappy-stubs-internal.h
libtool snappy-stubs-internal.lo
ltmain.sh snappy-stubs-internal.o
m4 snappy-stubs-public.h
Makefile snappy-stubs-public.h.in
Makefile.am snappy-test.cc
Makefile.in snappy-test.h
missing stamp-h1
NEWS testdata
README test-driver
ls /usr/local/bin shows nothing, but ls /usr/local/include shows:
snappy.h snappy-c.h snappy-sinksource.h snappy-stubs-public.h
So... my question: did it work? Why does ./configure in libpostal say it can't find snappy? Thanks in advance.
The snappy dependency has been removed as of release 1.0.0. I made changes to the source and make and config so that it will build on MinGW.
Get it in my repository:
https://github.com/BenK10/libpostal_windows
Note that this is not the complete source since not everything had to be changed. I would suggest merging my changes with the official libpostal distribution to make sure you've got everything. Also, there are some extra DLLEXPORTs in some source files that I haven't removed yet, and the part in the Makefile that builds the executables like address_parser.exe was removed because some porting is necessary to build those programs on Windows. You can write your own using the DLL you'll get in the Windows build and the original source as a reference.
Check the return code from make install ($?). If it is zero, make install succeeded.
snappy looks like a library, so maybe it doesn't install anything in /usr/local/bin. The library is probably installed into /usr/local/lib.

Building and linking shared Tensorflow library on OSX El Capitan to call from Ruby via Swig

I'm trying to help build a Ruby wrapper around Tensorflow using Swig. Currently, I'm stuck at making a shared build, .so, and exposing its C/C++ headers to Ruby. So the question is: How do I build a libtensorflow.so shared build including the full Tensorflow library so it's available as a shared library on OSX El Capitan (note: /usr/lib/ is read-only on El Capitan)?
Background
In this ruby-tensorflow project, I need to package a Tensorflow .bundle file, but whenever I irb -Ilib -rtensorflow or try to run the specs rspec, I get and errors that the basic numeric types are not defined, but they are clearly defined here.
I'm guessing this happens because my .so-file was not created properly or something is not linked as it should. C++/Swig/Bazel are not my strong sides, I'd like to focus on learning Tensorflow and building a good wrapper in Ruby, but I'm pretty stuck at this point getting to that fun part!
What I've done:
git clone --recurse-submodules https://github.com/tensorflow/tensorflow
cd tensorflow
bazel build //tensorflow:libtensorflow.so (wait 10-15min on my machine)
Copied the generated libtensorflow.so (166.6 MB) to the /ext-folder
Run the ruby extconf.rb, make, and make install described in the project
Run rspec
In desperation, I've also gone through the official installation from source several times, but I don't know if that, the last sudo pip install /tmp/tensorflow_pkg/tensorflow-0.9.0-py2-none-any.whl-step even creates a shared build or just exposes a Python interface.
The guy, Arafat, who made the original repository and made the instructions that I've followed, says his libtensorflow.so is 4.5 GB on his Linux machine – so over 20X the size of the shared build on my OSX machine. UPDATE1: he says his libtensorflow.so-build is 302.2 MB, 4.5GB was the size of the entire tensorflow folder.
Any help or alternative approaches are very appreciated!
After more digging around, discovering otool (thanks Kristina) and better understanding what a .so-file is, the solution didn't require much change in my setup:
Shared Build
# Clone source files
git clone --recurse-submodules https://github.com/tensorflow/tensorflow
cd tensorflow
# Build library
bazel build //tensorflow:libtensorflow.so
# Copy the newly shared build/library to /usr/local/lib
sudo cp bazel-bin/tensorflow/libtensorflow.so /usr/local/lib
Calling from Ruby using Swig
Follow the steps here, https://github.com/chrhansen/ruby-tensorflow#install-ruby-tensorflow, to run Swig, create a Makefile and make
When you run make you should see a line saying:
$ make
$ linking shared-object libtensorflow.bundle
If your shared build is not accessible you'll see something like:
$ ld: library not found for -ltensorflow
Simple tutorial
For those starting on this adventure, using C/C++ libraries in Ruby, this post was a good tutorial for me: http://engineering.gusto.com/simple-ruby-c-extensions-with-swig/
I don't think you actually want a .so, I think you want a .dylib (see What are the differences between .so and .dylib on osx?). You're forcing Bazel to build a .so by specifying libtensorflow.so as the target, build this instead:
bazel build //tensorflow
(//tensorflow is shorthand for //tensorflow:tensorflow, which is "build the tensorflow target." Specifying an exact file you want forces Bazel to build that file, if possible.)
Once you have a .dylib, you can check its contents with otool:
otool -L bazel-bin/tensorflow/libtensorflow.dylib
Not sure if this will solve all your problems, but worth a try.

Resources