I am attempting to open multixterm on my desktop machine, but I end up with the error:
usr:~> multixterm
can't find package Expect
while executing
"package require Expect"
(file "/usr/local/bin/multixterm" line 6")
Any help would be appreciated. I've tried running multixterm on my laptop and on a friend's machine, and there is no issue there. Both Expect and multixterm exist in the /usr/local/bin/ directory.
Update: I've also found that neither kibitz nor autoexpect will run. I now assume that there is an issue with where the programs are looking for Expect. Does anyone know how I can verify/check that?
First, run ldd /usr/local/bin/expect to find out where the Expect library (libexpect) is. For example:
% ldd /usr/bin/expect | grep libexpect
libexpect.so.5.45 => /usr/lib/x86_64-linux-gnu/libexpect.so.5.45 (0x00007f230f348000)
%
Then, export the TCLLIBPATH var with the libexpect directory. For example (seems like you're using csh):
% setenv TCLLIBPATH /usr/lib/x86_64-linux-gnu
Then run your multixterm command.
Expect was dropped from ubuntu's default installation,
run once:
conda install -c eumetsat Expect
and things should work again.
In my experience on Ubuntu, libexpect.so obtained through apt cannot be used for package require because the file contains 3 undefined-symbols. (E.g. Debian Bug report logs - #890228)
So I compiled the libexpect.so from its source. To do so, I had to compile 3 sources: Tcl, Tk, and Expect.
After decompressing sources, installing by following:
$ cd /path/to/install
$ mkdir tcl tk expect
$
$ /path/to/download/tcl8.*.*/unix/configure \
--prefix=/path/to/install/tcl
$ make ; make install
$
$ /path/to/download/tk8.*.*/unix/configure \
--with-tcl=/path/to/install/tcl \
--prefix=/path/to/install/tk
$ make ; make install
$
$ /path/to/download/expect5.*.*/configure \
--with-tclconfig=/path/to/install/tcl/lib \
--with-tkconfig=/path/to/install/tk/lib \
--prefix=/path/to/install/expect
$ make ; make install
gave me the file /path/to/install/expect/libexpect5.*.*.so for 64-bit architecture without undefined-symbols.
Here are 2 useful links about compiling:
How to Compile Tcl
[SOLVED] configuration error: Can't find Tcl configuration definition
Finally, in the case TCLLIBPATH does not work, unwarping approach using TclKits with sdx can be remedy. On Ubuntu, I used one for RHEL5 x86_64.
Related
I am totally new to swift. It has just been released as open source for linux and I wanted to try it. This is on ubuntu 14.04. clang is installed as per prerequisites.
<Edit>: requirements here request clang version 3.6 also on ubuntu 14.04. I had first tried these first steps with clang 3.4, but have since updated to 3.6 following the instructions in the link and retried. Same result.</Edit>
I have downloaded https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz to ~/Downloads/. Transcript of installation and first step in swift:
$ cd /tmp
$ tar xf ~/Downloads/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
$ PATH=/tmp/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin/:"$PATH"
$ clang++ --version
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ which swift
/tmp/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin//swift
$ swift --version
Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c)
Target: x86_64-unknown-linux-gnu
$ swift
Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
1> 1 + 2
opening import file for module 'SwiftShims': No such file or directory
1>
According to this getting started guide it should have printed instead
$R0: Int = 3
What's wrong and how can I fix it?
Edit: Trying to find that file manually: It is apparently not contained in the installation:
$ find swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/ | grep -i shims
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/FoundationShims.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/SwiftStddef.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/module.map
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/UnicodeShims.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/GlobalObjects.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/HeapObject.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/RuntimeShims.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/RefCount.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/RuntimeStubs.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/LibcShims.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/CoreFoundationShims.h
swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/shims/SwiftStdint.h
Edit: When I try the swift build helloworld example, this output is produced:
/tmp/Hello$ swift build
<unknown>:0: error: opening import file for module 'Swift': No such file or directory
swift-build: exit(1): ["/tmp/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin/swiftc", "--driver-mode=swift", "-I", "/tmp/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/pm", "-L", "/tmp/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/pm", "-lPackageDescription", "/tmp/Hello/Package.swift"]
Edit: new findings up to 2015-12-22
Since I posted this question, at least two more snapshots of swift for linux have been released: 2015-12-10 and 2015-12-18. I have tried these, but they do not fix the issue.
This mailing list thread here (post 1, post 2, post 3) is about the same problem. It was suggested there that installation of swift under the home directory would help. It did not help in my case, the error message is still the same.
More interestingly, that mailing list thread contains an analysis of the REPL error created with strace. It would be interesting to compare that particular strace output with the strace output from a system where REPL works.
Edit: More info up to 2015-12-26:
A new swift release is out, dated 2015-12-22. This release exhibits the same problem.
Another thread concerning this problem has appeared on the swift mailing list starting here. The user experiencing the problem has also posted strace output here.
I had the exact same problem. It turns out that I had added the ppa:ubuntu-toolchain-r/test repo in order to install g++-4.9 on my Mint distro (17.2). Once I purged the repository and restored various libraries to their original versions, swift finally worked for me.
Specifically, I had to run
sudo apt-get install ppa-purge
sudo ppa-purge -d trusty ppa:ubuntu-toolchain-r/test
While cleaning up, ppa-purge was complaining that in order to resolve conflicts, it would have to remove quite a few packages it could not find in the Ubuntu Trusty repo (including really core ones like build-essential, xorg, gcc, x11-xserver-utils...), so I made a note and reinstalled these right away after the purge. Just be very careful.
I think some of the libraries overridden when installing g++ 4.9 were creating a conflict. I've verified all this on a fresh Mint install too.
This is not really an answer -- I have the same problem as OP -- but SwiftShims is actually defined the module.map file in your file listing above:
module SwiftShims {
header "CoreFoundationShims.h"
header "FoundationShims.h"
header "GlobalObjects.h"
header "HeapObject.h"
header "LibcShims.h"
header "RefCount.h"
header "RuntimeShims.h"
header "RuntimeStubs.h"
header "SwiftStddef.h"
header "SwiftStdint.h"
header "UnicodeShims.h"
export *
}
https://github.com/apple/swift/blob/8d9ef80304d7b36e13619ea50e6e76f3ec9221ba/stdlib/public/SwiftShims/module.map
I repeated the same steps as you described on a brand-new Ubuntu 14.04 Azure VM and got the expected
$R0: Int = 3
Interestingly, it worked fine even without Clang or GCC! Later I installed Clang-3.5, and it worked as well.
Is it possible that they have sneaked in a new tarball with the same name? The MD5 hash of the one I got is here:
user#ubuntu1:/tmp/junk$ md5sum swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
a93f52921c491b747cad256904c8742f swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
Does yours match? If so, you may want to try a different installation of Ubuntu 14.04 if you have access to one.
I have also been able to successfully use swift build as instructed in https://swift.org/getting-started/#using-the-build-system . Removing the clang-3.5 package broke swift build, just as I had suspected, but REPL swift still worked as it did originally, before installing Clang for the first time. Then I installed Clang-3.4, and swift build was back in business.
Update 1/3/2016:
Using the hints from the various comments on this question, I've been able to reproduce the error on my Ubuntu 14.04 Azure VM. As an alternative solution, the problem can also be addressed by manipulating $LD_LIBRARY_PATH, see Unable to compile "hello world" program with Swift on Ubuntu 14.04.
Had the same issue, what I missed was that I didn't get the keys for the package and verify it before extracting.
Download the package
wget -q -O - https://swift.org/keys/all-keys.asc | gpg --import
gpg --keyserver hkp://pool.sks-keyservers.net --refresh-keys Swift
gpg --verify swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz.sig
tar xzf swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
add PATH=/path/to/usr/bin:"${PATH}" to your .bashrc
finally run swift
You should see:
Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
1> 1+1
$R0: Int = 2
Following the advice of James D, I tried to run
sudo apt-get install ppa-purge
sudo ppa-purge -d trusty ppa:ubuntu-toolchain-r/test
However, this did not work. What's strange, is that what did work doesn't make sense. For me, I got it working by installing the above ppa first and then purging it. The whole command set that got me working was
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install g++-4.9 # This step may be optional
sudo apt-get install ppa-purge
sudo ppa-purge -d trusty ppa:ubuntu-toolchain-r/test
I am compiling a theorem prover on cygwin and I get this error:
$ make
ocamlmklib -o bin/minisatinterface minisat/core/Solver.o minisat/simp/SimpSolver
.o bin/Ointerface.o -lstdc++
** Fatal error: Error while reading minisat/core/Solver.o: Sys_error("Invalid ar
gument")
Makefile:49: recipe for target `bin/libminisatinterface.a' failed
make: *** [bin/libminisatinterface.a] Error 2
It is not clear what kind of invalid argument is here?
The only documentation I have found for ocamlmklib did not help on understanding the error message. Could it not read the file itself or there is a problem with the contents? ls does list the file:
$ ls -l minisat/core/Solver.o
-rw-r--r-- 1 gbuday mkpasswd 2096 jan. 22 10.42 minisat/core/Solver.o
update: if I remove Solver.o I get a different error message:
** Fatal error: Cannot find file "minisat/core/Solver.o"
So the above error message is about the contents of the object file.
I happen to know that this specifically has to do with the build of the ATP Satallax, which can be used with Isabelle Sledgehammer, and I was asked to look at this.
I have no expertise with make files and ocaml. My success at building Satallax v2.7 came purely from following the instruction in INSTALL, with some minimal ability at guessing at what error codes meant, which I mainly needed when building Satallax v2.6 over a year ago.
The first important thing to do is make sure that the tar file is unzipped while working in a Cygwin terminal, rather than under Windows with something like WinZip.
Assuming that you're working in a Cygwin terminal, these are the notes which I made. After that I'll include text from the Satallax INSTALL, and few comments.
Sources: http://www.ps.uni-saarland.de/~cebrown/satallax/
0) tar xvzf satallax-2.7.tar.gz
1) Cygwin Package (these are also for other's like Leo-II):
zlib-devel, make, OCaml devel, gcc devel, g++ devel, libstdc++6-devel
Ubuntu 12 Packages:
sudo apt-get install build-essential
zlibg-dev using the Ubuntu Software Center
ocaml and g++ if they don't come with "build-essential"
2) Put eprover.exe in the path so that ./configure can find it.
a) There are the following lines in the configure files, which shows
that it's configured to find picomus, eprover has to be in the path
or `which eprover` has to be edited.
# Optionally set picomus to your picomus executable
picomus=${PWD}/picosat-936/picomus
# Optionally set eprover to your E theorem prover executable
eprover=`which eprover`
3) Follow the instructions in INSTALL.
a) export MROOT=`pwd` takes care of this next note, which I had to do
for v2.6, info I keep in here in case I need it in the future.
b) export MROOT=<minisat-dir>, where you replace "minisat-dir" with the
/cygdrive/e\E_2\binp\isaprove\satallax-2.6\cygwin\minisat
3) OLD v2.6 NOTE: If you get an error, delete the old source and try
untaring the sources again.
My build of v2.7 went through without problems, other than the test giving errors.
With Satallax v2.7, there is now the requirement that the build find the eprover. Note STEP 3 of INSTALL tells you to modify configure, or put eprover.exe in the path before the build. I put it in the path, which for me is
E:\E_2\dev\Isabelle2013-2\contrib\e-1.8\x86-cygwin
The INSTALL file then gives short instructions:
* Short Instructions
cd minisat
export MROOT=`pwd`
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../../picosat-936
./configure
make
cd ..
./configure
make
./test | grep ERROR
After downloading all needed packages, and putting eprover.exe in the path, it built without errors for me other than the test, but the executable works when used by Isabelle Sledgehammer.
STEP 3 of INSTALL talks about providing the location of the picomus executable, but I'm pretty sure that there's not need to do that because picosat-936\picomus.exe gets built in this build.
If you watch the build messages, it'll tell you what it's looking for and what it finds.
For completeness, I include the text from INSTALL, except for the instructions related to what's pertinent for Coq.
There are a number of requirements in order to compile Satallax.
In short, you need make, ocaml, g++ and the zlib header files.
In Debian and derived Linux systems, you can get these from
the build-essential and zlib1g-dev packages. You need
ocamlopt to obtain a standalone executable.
If you're not the administrator of the computer on which you're installing,
you can quote the previous paragraph to the administrator.
* Short Instructions
cd minisat
export MROOT=`pwd`
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../../picosat-936
./configure
make
cd ..
./configure
make
./test | grep ERROR
./bin/satallax.opt is the native code executable to use.
See test for examples of how to use it.
* Long Instructions
STEP 1:
Compile minisat (see minisat/README)
cd minisat
export MROOT=<minisat-dir> (or setenv in cshell)
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../..
STEP 2 (Optional. Only needed to extract proof information for proof terms.) :
Build picosat (including picomus):
cd picosat-936
./configure
make
cd ..
STEP 3:
If desired, edit the configure script to give the location of your picomus
and eprover executables. (If the executables are not found by the configure script,
you will need to give the location of the executables to satallax via the command line
options -P <picomus> -E <eprover> if they are needed.)
Run the configure script for Satallax.
./configure
STEP 4:
make
uses ocamlopt to make a standalone executable
./bin/satallax.opt
and uses ocamlc to make a bytecode executable
./bin/satallax
that depends on ocamlrun
STEP 5:
Test satallax using the examples in the script file:
./test
As long as you don't see a line with the word ERROR, it should be working.
I'm attempting to install a toolchain for assembly code on the raspberry pi. I used the following procedure to install the package files:
$ wget http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/downloads/arm-none-eabi.tar.bz2
--2012-08-16 18:26:29-- http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/downloads/arm-none-eabi.tar.bz2
Resolving www.cl.cam.ac.uk (www.cl.cam.ac.uk)... 128.232.0.20, 2001:630:212:267::80:14
Connecting to www.cl.cam.ac.uk (www.cl.cam.ac.uk)|128.232.0.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 32108070 (31M) [application/x-bzip2]
Saving to: `arm-none-eabi.tar.bz2'
100%[======================================>] 32,108,070 668K/s in 67s
2012-08-16 18:27:39 (467 KB/s) - `arm-none-eabi.tar.bz2' saved [32108070/32108070]
$ tar xjvf arm-none-eabi.tar.bz2
arm-2008q3/arm-none-eabi/
arm-2008q3/arm-none-eabi/lib/
arm-2008q3/arm-none-eabi/lib/libsupc++.a
arm-2008q3/arm-none-eabi/lib/libcs3arm.a
...
arm-2008q3/share/doc/arm-arm-none-eabi/info/gprof.info
arm-2008q3/share/doc/arm-arm-none-eabi/info/cppinternals.info
arm-2008q3/share/doc/arm-arm-none-eabi/LICENSE.txt
$ export PATH=$PATH:$HOME/arm-2008q3/bin
That appeared to work, the package files are in the correct place.
~/arm-2008q3/bin $ ls
arm-none-eabi-addr2line arm-none-eabi-gcc-4.3.2 arm-none-eabi-objdump
arm-none-eabi-ar arm-none-eabi-gcov arm-none-eabi-ranlib
arm-none-eabi-as arm-none-eabi-gdb arm-none-eabi-readelf
arm-none-eabi-c++ arm-none-eabi-gdbtui arm-none-eabi-run
arm-none-eabi-c++filt arm-none-eabi-gprof arm-none-eabi-size
arm-none-eabi-cpp arm-none-eabi-ld arm-none-eabi-sprite
arm-none-eabi-g++ arm-none-eabi-nm arm-none-eabi-strings
arm-none-eabi-gcc arm-none-eabi-objcopy arm-none-eabi-strip
However, when I go to make, I get the following outcome.
arm-none-eabi-as -I source/ source/main.s -o build/main.o
make: arm-none-eabi-as: Command not found
make: *** [build/main.o] Error 127
Thanks in advance for any help.
export PATH=$PATH:$HOME/arm-2008q3/bin is only valid in the shell it is executed in (and any shells spawned from that shell). So you either use that shell instead of opening a new one to execute make or edit your ~/.bashrc (see Unix: Getting Export PATH to "Stick")
I encountered the same problem and in my case the problem was that I was running a 64-bit operating system and the package to be used is a 32-bit. The fix was to install i32-libs package which allows running 32-bit applications on a 64-bit system.
# apt-get install ia32-libs
You have to direct your compiler to the right path where arm-none-eabi-as is located. You can do so by
export PATH=$PATH:/file_path_goes_here/
When you compile, you should have no problems as the compiler will now know where to look.
I'm trying to build prerequisites for gcc-4.7.2.
Both ppl-0.11 and gmp-4.3.2 are the recommended versions in <gcc_src>/gcc-4.7.2/gcc/doc/HTML/prerequisites.html
I have built and installed gmp-4.3.2 (with --enable-cxx set)
Attempting to configure ppl-0.11 fails.
configure: error: Cannot find GMP version 4.1.3 or higher.
GMP is the GNU Multi-Precision library:
see http://www.swox.com/gmp/ for more information.
When compiling the GMP library, do not forget to enable the C++ interface:
add --enable-cxx to the configuration options.
This is my configure line:
./configure \
--prefix=$PREFIX \
--with-gmp=$PREFIX \
--with-gmp-prefix=$PREFIX \
If I look in the directory where I specified with-gmp, here is the installed gmp:
$ grep MP_VERSION $PREFIX/include/gmp*
$PREFIX/include/gmp.h:#define __GNU_MP_VERSION 4
$PREFIX/include/gmp.h:#define __GNU_MP_VERSION_MINOR 3
$PREFIX/include/gmp.h:#define __GNU_MP_VERSION_PATCHLEVEL 2
.
$ l $PREFIX/include/gmp*
$PREFIX/include/gmp.h
$PREFIX/include/gmpxx.h
.
$ l /$PREFIX/lib/libgmp*
$PREFIX/lib/libgmp.a
$PREFIX/lib/libgmp.la
$PREFIX/lib/libgmp.so -> libgmp.so.3.5.2
$PREFIX/lib/libgmp.so.3 -> libgmp.so.3.5.2
$PREFIX/lib/libgmp.so.3.5.2
$PREFIX/lib/libgmpxx.a
$PREFIX/lib/libgmpxx.la
$PREFIX/lib/libgmpxx.so -> libgmpxx.so.4.1.2
$PREFIX/lib/libgmpxx.so.4 -> libgmpxx.so.4.1.2
$PREFIX/lib/libgmpxx.so.4.1.2
Am I missing something?
As far as I can tell, GMP is available and of the requisite version
Depending on what distro you are running, have you tried to install the gmp-devel package (i.e. yum install gmp-devel on Fedora/RedHat etc)?
PPL will by default try to use default locations for GMP. If you use crosstool-ng, you must do either a cross-native or canadian-cross build. If you are doing this manually, specify CXXFLAGS to PPL's ./configure, with a -I<path-to-gmp-header> and a -Wl,-L<path-to-gmp-libs>. This allows the PPL ./configure to find the correct version of GMP.
Apparently a PPL configure with,
--prefix=$PREFIX \
--with-gmp=$PREFIX \
--with-gmp-prefix=$PREFIX \
Is not enough. I sleuthed through the ./configure script and was hacking up crosstool-ng before I realized that I was no longer building a cross-compiler, but a canadian-cross when I wasn't using my distro gcc, but another host compiler with a lower glibc shared library. This is useful if you want your compiler to run on a larger class of machines. It is unlikely that the glibc version of the build compiler will effect much.
I still had to patch 120-ppl.sh in crosstool-ng,
do_ppl_for_build() {
...
ppl_cxxflags="${CT_CFLAGS_FOR_BUILD}"
+ ppl_cxxflags+=" -I${CT_BUILDTOOLS_PREFIX_DIR}/include "
+ ppl_cxxflags+=" -Wl,-L${CT_BUILDTOOLS_PREFIX_DIR}/lib "
if [ "${CT_PPL_NEEDS_FPERMISSIVE}" = "y" ]; then
ppl_cxxflags+=" -fpermissive"
fi
So I also faced the same issue and what I did was:
1) Went inside gmp-4.3.2 folder
2) make distclean
3) ./configure --prefix=/home/sen/Documents/mingw/downloads/gmp_build --enable-cxx
4) make && make install
5) Went inside ppl-0.11 folder
6) ./configure --prefix=/home/sen/Documents/mingw/downloads/ppl_build --with-gmp-prefix=/home/sen/Documents/mingw/downloads/gmp_build --enable-cxx
7) make & make install
Took some 10-20 mins to compile and things were fine.
Thanks,
Sen
After years, the issue has been run into. The solution is firstly to download last version of gmp. Then, copy the path as in like the picture. Don't forget to ./configure with --enable-cxx, which is really important point. ./configure --enable-cxx. Now time is to ppl installation, ./configure -help indicates that --with-gmp=DIR search for libgmp/libgmpxx in DIR/include and DIR/lib. So write ./configure --with-gmp=<<dir of gmp as shown in first picture, you may have a different path>>
I wrote, respectively, ./configure --with-gmp=/usr/local/include, make, sudo make install then it works like a charm!
I am trying to cross-compile climm-0.6.4 to windows under Ubuntu with the following command:
./configure --host=i686-pc-mingw32 --enable-ssl=gnutls
and I get this error message:
**checking for libgnutls-config... no
checking for libgnutls - version >= 0.8.8... no
*** The libgnutls-config script installed by LIBGNUTLS could not be found
*** If LIBGNUTLS was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBGNUTLS_CONFIG environment variable to the
*** full path to libgnutls-config.**
After some research on the Internet I found a hint here:
The package's ./configure script is trying to invoke libgnutls-config
and/or libgnutls-extra-config to search for the gnutls library. Newer
versions of gnutls do not ship these scripts anymore.
and I am using gnutls-2.12.5
Does anybody have a patch or a kludge trick so that I am able to cross-compile climm-0.6.4 with gnutls-2.12.5?
Thank you in advance!
cheers
Daniel
Try the --with-libgnutls-prefix=PFX option to the configure script telling where the library is.
Other option in to set the environment variable LIBGNUTLS_CONFIG to a program that outputs just the parameters you need to compile/link the library.
Update:
Try the following script, name it mygnutls_config:
#!/bin/bash
if [ "$1" == "--version" ]
then
shift
EXTRA="--modversion"
else
EXTRA=""
fi
pkg-config gnutls $EXTRA "$#"
And then
$ chmod a+x mygnutls_config
$ LIBGNUTLS_CONFIG=`pwd`'/mignutls_config' ./configure --enable-ssl=gnutls
note that for this to work you need pkg-config to detect the crosscompilation configuration, not the native one. So you may need the PKG_CONFIG_LIBDIR environment variable to point to the directory where the appropriate gnutls.pc file is.