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).
Related
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.
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.
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).
I got the libpuzzle source here: http://www.pureftpd.org/project/libpuzzle/download.
I read I need MinGW to compile any C programs on windows, so I got that alot with C, C++ and mins options. Using mins I was followed: http://wiki.openttd.org/Compiling_on_MinGW
I downloaded the .tar.gz and unpacked it, executed the ./configure command and got:
libgd2 development files are not found
Makes sense given in the readme:
In order to load images, the library relies on the GD2 library.
You need to install gdlib2 and its development headers before compiling
libpuzzle.
The GD2 library is available as a pre-built package for most operating systems.
Debian and Ubuntu users should install the "libgd2-dev" or the "libgd2-xpm-dev"
package.
Gentoo users should install "media-libs/gd".
OpenBSD, NetBSD and DragonflyBSD users should install the "gd" package.
MacPorts users should install the "gd2" package.
X11 support is not required for the Puzzle library.
Once GD2 has been installed, configure the Puzzle library as usual:
My problem at this time is finding a libgd2-dev or like file to compile. I found this: http://mldonkey.sourceforge.net/Windows and downloaded http://www.boutell.com/gd/http/gd-2.0.33.tar.gz and it installed fine. Running gdlib-config outputs typical man. However, libpuzzle still says I need the "libgd2 development files", so I assume the gd I downloaded was "libgd" but just "gd" or the file I had didn't have development files. Where can I found what I need?
Here is mingw output:
Brian#2500K ~/libpuzzle-0.11
$ gdlib-config
Print information on GD library's version, configuration, and use.
Usage: gdlib-config [options]
Options:
--libdir # directory where GD library is installed
--includedir # directory where GD library headers are installed
--version # complete GD library version string
--majorversion # GD library major version number
--minorversion # GD library minor version number
--revision # GD library revision version number
--ldflags # options required for linking against GD library
--libs # libs required for linking against GD library
--cflags # options required for compiling GD library apps
--includes # same as --cflags
--features # lists optional features compiled into gd, separated
# by spaces. Currently (as of 2.0.26) the optional
# features are GD_PNG, GD_JPEG, GD_XPM, and
# GD_FREETYPE. When these features are reported by
# --features, it is safe to include calls to the
# related functions in your code.
--all # print a summary of all GD library configure options
Brian#2500K ~/libpuzzle-0.11
$ gdlib-config --includedir
/usr/local/include
Brian#2500K ~/libpuzzle-0.11
$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
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 dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... no, using cp -p
checking whether make sets $(MAKE)... (cached) yes
checking for gdlib-config... /usr/local/bin/gdlib-config
checking for gdImageCreateFromGd2 in -lgd... no
configure: error: libgd2 development files not found
Edit: Started a bounty. I am looking for either compile the libpuzzle for me so it works on WAMP (skipping the complicated middle stuff). Or help on getting each requirement needed so that I can compile it. My end goal is having libpuzzle run on wamp
Edit 2: Just an update, it seems libgd2 has problems with mingw. Even if I was to get libgd2 to finally work then I still need phpize for mingw as well, which also doesn't work for mingw. It seems it's not possible to use libpuzzle for windows
It sounds like the program is just not finding the headers for libgd. If you look at that tarbar, it's a source tarball that includes the headers. When you compiled and installed it, it installed the library and the headers somewhere. You need to figure out where.
Run ./configure --help
There should be an option like --with-gd=, that option lets you tell it the path where libgd is installed. Specify the path where it is installed, and it should work.
Encountered the same error when compiled GD2 myself.
Using old precompiled version from GnuWin32 solved the problem:
http://sourceforge.net/projects/gnuwin32/files/gd/2.0.33-1/
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!