I would like to use an iron.io worker to stich panoramas and create HDRs using the OpenSource Hugin and libpano13 toolkits. The programs needed are all command-line (no GUI is needed) but I'm not entirely sure how I go about building a worker that includes the correct binaries for using the Hugin panotools.
Can I pre-compile the right binaries for the iron.io worker OS (Ubuntu Linux)? I can create a VM and install Ubuntu on it to get a set of binaries built that I include in my worker. But is there a better way using the "build" directive in the worker file? The problem I see right away is that Hugin is a cmake-based build so I'd need to create something that uses autoconf/automake, right?
I don't really need all of Hugin, either. I just need the control point finder utility and the enfuse/enblend utilities for doing the actual stitching. I don't need any of the GUI stuff, which is wxWidgets based.
Can anyone shed light on how I would go about this? Thanks!
You really need only statically compiled x64 binaries, find them anywhere - and you're done.
Possible solutions:
Install stuff on local Ubuntu x64 (IronWorker using 12.04 TLS x64) and include required files into worker's package (which is just .zip file after uploading) (and probably extend PATH at start of a worker)
Use build command to do any installation procedures remotely (you're still limited to non-root operations though)
Use deb command to install existing .deb packages.
.worker file example (including custom version of imagemagick):
runtime 'binary'
exec 'run.sh'
full_remote_build true
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/libmagickcore5_6.7.7.10-2ubuntu4_amd64.deb'
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/libmagickwand5_6.7.7.10-2ubuntu4_amd64.deb'
deb 'http://mirror.pnl.gov/ubuntu//pool/main/i/imagemagick/imagemagick_6.7.7.10-2ubuntu4_amd64.deb'
Related
I want to investigate a new application for JPEG 2000 encoding and decoding. I downloaded openjpeg-master and managed to cobble together the ability to cmake the files. After a bunch of grinding, this resulted in the following output:
"Build files have been written to: C: openjpeg-master/build
\build> "
Any "normal" Unix installations have a multi-step installation like this:
"UNIX/LINUX - MacOS (terminal) - WINDOWS (cygwin, MinGW)
To build the library, type from source tree directory:
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
Binaries are then located in the 'bin' directory.
To install the library, type with root privileges:
make install
make clean
To build the html documentation, you need doxygen to be installed on your system. It will create an "html" directory in TOP_LEVEL/build/doc)
make doc"
But the Windows 10 equivalent is unclear, to put the most charitable spin on it. You can find it here: "https://github.com/uclouvain/openjpeg/blob/master/INSTALL.md"
Some questions arise:
is there a better starting place for installing JPEG 2000 that actually shows me how to install it and run the tests?
if not, how do I get from the build files to installing the libraries and making the test programs?
Is there more information I can dig out that would help to answer these questions?
Since I'm allergic to Visual Studio, I overlooked a nice tutorial specifying how to install something as complex as openjpeg by direct clone from github. However, in desperation, I found it and it worked. It is Visual Studio Community 2019 Version 16.8.3. I needed only to use -DTHIRDPARTY to get the third party libraries installed. There is a drop-down menu to build and install OPENJPEG. All I need to do now is figure out how to compile and run the utilities that invoke the installed libraries ...
actually, the complete line to add was -DBUILD_THIRDPARTY:bool=true.
Somewhere in my frantic random search for a way forward, I remember seeing the thought that to make the tests work, I merely need to find files like *.vsproj and run them a separate VS solutions. Some random guesswwork with .vdproj files in src/bin/... hasn't produced anything good. Is there not a document somewhere showing how to run the tests?
I'm using buildroot to create a linux system for raspberry pi. I want to use the initramfs to enable to system to self-patch. The procedure roughly runs as follows:
Raspi boots, kernel loads initramfs
The initramfs-system (which contains busybox, zsync etc.) connects to a central server and checks if there are boot-file updates available (e.g. a new kernel)
If not, it checks if there is a system update available and downloads that if needed
The downloaded (squashfs) system image is mounted and executed via switch_root
My problem is that I need to compile a secondary busybox (and some more packages) for the initramfs which do not belong in the main system. I currently solved this by manually tinkering with the package files to install into target/initramfs, moving this folder out with pre-build and back in again with post-build, but this seems rather hacky. Additionally, different package types require different types of changes. Is there a better solution to this problem? If one could for example manually overwrite the target directory for each package, this problem would be rather easy to solve.
Create two separate buildroot configurations.
One configuration will have the kernel and the initramfs.
The other configuration only has the squashfs rootfs.
Creating a partial rootfs from a configuration is very tricky, because you have to be sure that you don't miss any shared libraries or other auxiliary files needed by some program.
Note that to speed up the build, you can use ccache and/or use an external toolchain. See the manual.
I am using an iron.io node.js worker. I have ant as a dependency. How can I install this?
I could only see the instructions for language specific dependencies installations (like node modules).
Thanks
You can probably include the linux x64 binary distribution along with your worker by including the
"dir" command in your .worker file. Something like:
dir "apache-ant-1.9.4"
That will include the entire directory in your worker package.
Hit us up at get.iron.io/chat for help.
I am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).