I am not able to use aviread in GNU Octave on Windows 10. Many sites tell me to install the video package, but I'm getting this error during installation.
octave:3> pkg install -forge video
rm: cannot remove `a.exe': Permission denied
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
configure: error: need libavformat from FFMpeg
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for mkoctfile... C:/Octave/Octave-4.0.0/bin/mkoctfile-4.0.0.exe
retrieving compile and link flags from C:/Octave/Octave-4.0.0/bin/mkoctfile-4.0.0.exe
checking for F77_FUNC... yes
checking for SLList.h... no
checking for lo_ieee_nan_value... yes
checking for octave_idx_type... no
checking for quit.h... no
checking for octave... C:/Octave/Octave-4.0.0/bin/octave-4.0.0.exe
checking for OCTAVE_VERSION in Octave... 4.0.0
checking for octave_config_info('canonical_host_type') in Octave... i686-w64-mingw32
checking for octave_config_info('SHLEXT') in Octave... dll
checking whether ln -s works... no, using cp -p
checking for ranlib... ranlib
checking for strip... strip
checking for pkg-config... pkg-config
checking for av_write_frame in -lavformat... no
pkg: error running the configure script for video.
error: called from 'configure_make' in file C:\Octave\Octave-4.0.0\share\octave\4.0.0\m\pkg\private\configure_make.m near line 79, column 9
octave:3>
May I know how to install this package. Most sites say it is obsolete but none of them provide a solution to my problem. If not, is there any other way to read an AVI file (apart from converting the file itself)?
I tried manually downloading and installing the most recent 'release' build of the video package, verifying your results. (apparently the -forge flag pulls the same one off the server, which is v.1.0.2.) That's from way back in 2009. There hasn't been a stable build since then, and there have been a large number of changes in Octave over that time, so it's no surprise things don't quite work right.
If you check out the Octave forge Packages page you'll see a note at the bottom about unmaintained packages:
They are still stored and release tarballs can be downloaded from our File Release System (same for the very old monolithic releases) . However, many of them have accumulated bug fixes and new features in the mercurial or SVN repositories, it simply happens that no maintainer has prepared a release. Because of this, we encourage users to check the development sources, not the released tarballs. Furthermore, bug reports for those packages continue to be welcome, and anyone wishing to take up the position of maintainer, please contact us through the maintainers mailing list.
Again, the File Release System, May 8 2009 release is the latest one that includes video v1.0.2. If you check out the mercurial repository, however, there is a link to the video source that shows work on the source as recent as Nov 2015. This Octave help mailing list discussion describes some of the recent attempts to get it working about, and mentions specific difficulties for Windows. Another maintainers list discussion indicates it may be improved and working under (at least) linux, and possibly windows if you're set up to re-compile.
My best suggestion would be to email the Octave Help mailing list (help-octave#gnu.org) and see if anyone has come up with procedures for getting that package working under windows. My guess is most are developing and compiling with linux, so this may not be a trivial process.
UPDATE 16 NOV 22: updating this old report to note that the video package has been completely rewritten since this question was first asked. it is now matlab compatible, containing only VideoReader and VideoWriter functions (so no aviread). It is a bundled package included with all Octave installers for windows (video v.2.0.2 is bundled with Octave 7.3.0). The latest video package can be obtained from https://packages.octave.org, and the video package repository is still located at SourceForge.
Related
I have been trying to compile an old Python code. A couple of days ago I posted a question that described problems with accessing Python and gfortran. I solved the Python problem, then the question no longer made sense. It had no answers so I deleted it. However, now when I run a "configure" script, I'm getting an error that I don't understand:
configure: error: You need to set PETSC_DIR to point at your PETSc installation... exiting
An online search to find out what PETSc is turned up a forum post (https://github.com/firedrakeproject/firedrake/issues/1703) that mentions "gfortran" and I wonder that's where my problem is. I installed gcc via Homebrew to get gfortran and now see it at /usr/local/bin/gfortran. In my .zshrc file, I added:
export PATH=$PATH:/usr/local/bin
alias python=/usr/local/bin/gfortran
When I do:
gfortran --version
I get (which seems fine):
GNU Fortran (Homebrew GCC 11.3.0_2) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
When I do:
which gfortran
I get the following.
aliased to gfortran -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
The other thing that seems relevant is that I just did:
brew install openmpi
to overcome an error related to not having MPI. I don't know anything about using MPI on a Mac so it's likely this is where I'm going wrong.
configure: error: no MPI support found on system
Here are the clues from the "configure" script log file:
checking for malloc in -ltcmalloc... no
configure: WARNING: No tcmalloc support available.
checking for mpif90... no
checking for mpf90... no
checking for mpicc... no
checking for mpcc... no
checking for mpicxx... no
checking for mpiCC... no
checking for mpCC... no
checking if we can compile and link without using -lmpi... no
checking if we can compile and link using -lmpi... no
checking if we can compile and link using mpich libs... no
configure: error: no MPI support found on system
I would be very grateful if someone could please point me in the right direction.
Your error message indicates that the PETSc library is missing. You can probably find a pip installation that gives you petsc with a python interface.
However, your further problem with Zoltan indicates that (probably) you need a petsc installation that has zoltan as optional package. I'm not sure that you can find a pip install for that. You may need to install petsc entirely by hand.
https://petsc.org/release/install/
and use the configuration options --with-zoltan --with-mpi4py.
I'm trying to compile the binutils for the i686-elf target according to this tutorial:
https://wiki.osdev.org/GCC_Cross-Compiler
I just added the --enable-tui option, so that I have the support in the gdb.
I did the following:
# get sources
git clone git://sourceware.org/git/binutils-gdb.git
# store settings
export PREFIX="`pwd`/opt/cross"
export TARGET=i686-elf
export PATH="$PREFIX/bin:$PATH"
# create build folder
mkdir build-binutils
cd build-binutils
# run configure
../binutils-gdb/configure -target=$TARGET --prefix="$PREFIX" --with-sysroot --disable-nls --disable-werror --enable-tui
# make
make
This runs for some time and terminates with the following error:
checking for library containing socketpair... (cached) none required
checking for ld used by GCC... (cached) ld
checking if the linker (ld) is GNU ld... (cached) yes
checking for shared library run path origin... (cached) done
checking for iconv... (cached) yes
checking for iconv declaration... (cached)
extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for library containing waddstr... (cached) no
configure: error: no enhanced curses library found; disable TUI
make[1]: *** [Makefile:11329: configure-gdb] Error 1
make[1]: Leaving directory '/home/noexpandtab/dev/build-binutils'
make: *** [Makefile:853: all] Error 2
For me it seems, that the ncurses library cannot be found.
I have a Debian 10 running and installed the following additional packages:
libncurses-dev
ncurses-base
ncurses-doc
libncurses5-dev
Do I have to install additional packages? Or am I missing some options for the configure script?
You're cross-compiling to a different architecture (i686-elf) than whatever you're running on—the $TARGET mentioned in the question. gdb will have to be linked with libraries which are built for that architecture.
Debian provides ncurses packages which run on the current architecture, but does not provide a suitable package for the cross-compiled application. So you get to do this for yourself.
When cross-compiling ncurses, you'll have to keep in mind that part of it builds/runs on the current architecture (to generate source-files for compiling by the cross-compiler). That's defined in the environment as $BUILD_CC (rather than $CC), as you might see when reading the script for the mingw cross-compiling. There's a section in the INSTALL file (in the ncurses sources) which outlines the process.
There's no tutorial (that would be off-topic here anyway), but others have read the instructions and cross-compiled ncurses as evidenced by a recent bug report.
I retried the whole compilation, and suddenly it works! I tested a bit and I assume I found my fault: I executed configure without --enable-tui, where make worked. Then I executed configure with --enable-tui in the same folder without cleaning it. After cleaning or running in a new folder it compiled.
Thanks to the one user who posted to delete the contents of opt/cross. (The comment itself was already somehow deleted in between.) This wasn't the solution, but leaded me in the right direction.
TL;DR: Clean the build folder before running configure with different parameters again.
This may not be easy to answer concisely but I don't consider it to be open-ended: when using automakeand configure to cross-compile a library, what should be the most important things I need to avoid 'toolchain leaks'?
Here is some context...
First off, a toolchain leak is defined here: http://landley.net/writing/docs/cross-compiling.html
I'm compiling libuuid from source using a toolchain that is made for cross compiling code that will run on a custom debian based system. The goal of the project is to compile the code (including this 3rd party library that my app depends on) using the toolchain so that the compilation is independent of the host machine.
So far, I've tried to supply my toolchain's gcc compiler which looks okay, but when I run ./configure there are many things it checks for, and I'm not sure how to tell which ones truly matter, and I'm not sure how to have it only check in my toolchain and ignore anything on the host system. Here are a few examples:
Here you can see that ./configure is happy with my toolchain compiler:
checking whether we are using the GNU C compiler... yes
checking whether <toolchain>/bin/i686-linux-gcc accepts -g... yes
Then shortly after you can see it finds grep on my host system which seems like a 'toolchain leak'
checking for grep that handles long lines and -e... /bin/grep
Then later on it searches the host system for some headers. I think I can specify where it should look, but I still don't know which headers are required:
checking for linux/compiler.h... no
checking for linux/blkpg.h... yes
checking for linux/major.h... yes
checking asm/io.h usability... no
<...>
Then shortly after you can see it finds grep on my host system which seems like a 'toolchain leak'
I would not call that a 'toolchain leak', and the referenced article doesn't either. It does mention these things as being 'leaks':
Improper header files from the autoconf --build system (called "host" in the article, and in your post).
Improper libraries from the --build system
I don't think any toolchain I've used has it's own grep executable. What would it do differently?
That being said, it shouldn't be using --builds linux headers. Usually the toolchain has it's own copy of those. That would be a 'leak'.
I'm compiling libuuid from source using a toolchain that is made for cross compiling code that will run on a custom debian based system. The goal of the project is to compile the code (including this 3rd party library that my app depends on) using the toolchain so that the compilation is independent of the host machine.
It'll go something like this: compile the dependency with the toolchain and install it in the toolchain /usr/lib (or somewhere where you plan on keeping cross compiled libraries, if you don't want to clutter up your toolchain). Compile libuuid with the toolchain (referencing the dependency, of course).
After downloading and untarballing libmicrohttpd from the GNU archive, I did the usual: ./configure. However, configure stopped reporting an error. Here are the last few relevant lines:
checking for pthread_create in -lpthread... no
checking if compiler supports -pthread... no
checking if compiler supports -pthreads... no
checking if compiler supports -threads... configure: error: Your system is not supporting pthreads!
I searched online, and sure enough, it appears that OSX *does* have pthreads, however I could not find anything on configure reporting errors about no pthreads on OSX.
Here is a top level ls of my /usr/include: http://sprunge.us/DGgY
and here is a tree of the same: http://sprunge.us/fVBV
On OS X it's easier to use Homebrew instead of trying to build from scratch - I just checked and they have a formula for libmicrohttpd.
Note that by default Homebrew puts headers and libraries under /usr/local/include and /usr/local/lib - gcc will find libraries and headers here by default, or you can add the paths explicitly if you prefer (-I for include paths, -L for library paths).
I am trying to compile a package on ubuntu 8.1
when executing this command: ./configure I get the follwoing error:
checking for Boost headers version >= 103700... no
configure: error: cannot find Boost headers version >= 103700
knowing that I installed needed boost packages using these command:
$ apt-get install libboost-dev libboost-graph-dev libboost-iostreams-dev
Can anybody help please?
thank you. Now it works but i get another error when running ./configure: checking boost/iostreams/device/file_descriptor.hpp usability... yes checking boost/iostreams/device/file_descriptor.hpp presence... yes checking for boost/iostreams/device/file_descriptor.hpp... yes checking for the Boost iostreams library... no configure: error: cannot not find the flags to link with Boost iostreams any ideas please?
It could be that the version of boost that you're getting from the Ubuntu repository is too old (it's suggested here that the highest version for 8.10 is 1.35; it looks like your configure script is asking for 1.37). You might need to build from source; there's some more info in the answers to the question I linked to which will hopefully help.
UPDATE:
From your new error, it sounds like configure now can't find the boost_iostreams library. On my system it's /usr/lib/libboost_iostreams-mt.[a|so] - do you have those files (possibly in a different directory depending on where you installed boost)?
You can also try running ldconfig in case there's a missing symlink (from, say,
libboost_iostreams-mt.so.1.37.0 to libboost_iostreams-mt.so).
Is this configure one generated by GNU autoconf? If it is, there should be a file called config.log in the same directory which contains a list of all the commands configure tried to run when looking for things. If there's anything in there about boost_iostreams could you post it?
One totally random guess: some examples I've found on the web link to boost_iostreams without the multi-threading suffix -mt - but I don't have those on my machine at all. Maybe your configure script is running into the same problem?
UPDATE 2
The configure script seems to be looking for a single-threaded debug build of the boost iostreams library, which won't be produced by default when building from source on linux. Also, the default on linux is not to name the libraries based on the build configuration (so the libs you found in /usr/lib might not be the ones you installed from source unless you overrode this). This stuff isn't really explained on the boost website, I only found out by looking in the Jamroot file (bjam --help works too)! Anyway, to get a library with the right build configuration, and named correctly, I need to go into the root of the boost source tree and run:
sudo bjam --with-iostreams --layout=tagged variant=debug threading=single install
For me this puts the libraries (libboost_iostreams-d.a and the shared versions) into /usr/local/lib where ld will find them by default, so this should be fine. If you need them to go somewhere else you can use the --prefix=... option to bjam eg. if you want them in /usr/lib you can do --prefix=/usr. If the package you're building needs more boost libraries you can remove the --with-iostreams and then they'll all be built (or replace iostream with the name of each other library you need).
A side note: I had to install the libbz2-dev package to get boost iostreams to build - it's easy to miss the error here if you build all of boost as there's so much output!