I have a project depending on iconv, because I need to work with cp1251 codepage. Here is the minimal implementation of the problem project. I has installed iconv from here and successfully installed haskell package "iconv" like this
cabal install iconv --extra-include-dirs="C:\GnuWin32\include" --extra-lib-dirs="C:\GnuWin32\lib"
The package iconv is properly installed, but the project depending on it failed on linking, here is what is going on.
c:\iconvsmpl>cabal configure --extra-include-dirs="C:\GnuWin32\include" --extra-
lib-dirs="C:\GnuWin32\lib"
Warning: The package list for 'hackage.haskell.org' is 16 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Configuring iconvsmpl-0.1.0.0...
Warning: The 'license-file' field refers to the file 'LICENSE' which does not
exist.
c:\iconvsmpl>cabal build
Building iconvsmpl-0.1.0.0...
Preprocessing executable 'iconvsmpl' for iconvsmpl-0.1.0.0...
[1 of 1] Compiling Main ( iconvsmpl.hs, dist\build\iconvsmpl\iconvsm
pl-tmp\Main.o )
Linking dist\build\iconvsmpl\iconvsmpl.exe ...
C:\Users\admin\AppData\Roaming\cabal\iconv-0.4.1.1\ghc-7.6.3/libHSiconv-0.4.1.1.
a(hsiconv.o):hsiconv.c:(.text+0x7): undefined reference to `_imp__libiconv_open'
C:\Users\admin\AppData\Roaming\cabal\iconv-0.4.1.1\ghc-7.6.3/libHSiconv-0.4.1.1.
a(hsiconv.o):hsiconv.c:(.text+0x17): undefined reference to `_imp__libiconv'
C:\Users\admin\AppData\Roaming\cabal\iconv-0.4.1.1\ghc-7.6.3/libHSiconv-0.4.1.1.
a(hsiconv.o):hsiconv.c:(.text+0x27): undefined reference to `_imp__libiconv_clos
e'
collect2: ld returned 1 exit status
c:\iconvsmpl>
Why is iconv installed and linked but iconvsmpl can not be linked. How to build it under Windows? Is there another way to work with foreign encodings under Windows for Haskell ?
It is very desirable to have executable for windows. Package building and working under Linux.
The version of Haskell-Platform is 2013.2.0.0
You'll need to modify the iconv package's .cabal file when installing on Windows. Remove the conditional check so that the extra-libraries field always applies. Update the include-dirs and extra-lib-dirs fields to read as follows:
include-dirs: cbits, "c:\\GnuWin32\\include"
extra-lib-dirs: "c:\\GnuWin32\\lib"
Related
I'm very new to Yesod and I'm having trouble building Yesod statically
so I can deploy to Heroku.
I have changed the default .cabal file to reflect static compilation
if flag(production)
cpp-options: -DPRODUCTION
ghc-options: -Wall -threaded -O2 -static -optl-static
else
ghc-options: -Wall -threaded -O0
And it no longer builds. I get a whole bunch of warnings and then a
slew of undefined references like this:
Linking dist/build/personal-website/personal-website ...
/usr/lib/ghc-7.0.3/libHSrts_thr.a(Linker.thr_o): In function
`internal_dlopen':
Linker.c:(.text+0x407): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/unix-2.4.2.0/libHSunix-2.4.2.0.a(HsUnix.o): In
function `__hsunix_getpwent':
HsUnix.c:(.text+0xa1): warning: Using 'getpwent' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/unix-2.4.2.0/libHSunix-2.4.2.0.a(HsUnix.o): In
function `__hsunix_getpwnam_r':
HsUnix.c:(.text+0xb1): warning: Using 'getpwnam_r' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/libpq.a(thread.o): In function `pqGetpwuid':
(.text+0x15): warning: Using 'getpwuid_r' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/libpq.a(ip.o): In function `pg_getaddrinfo_all':
(.text+0x31): warning: Using 'getaddrinfo' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__63.o): In function `sD3z_info':
(.text+0xe4): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__164.o): In function `sFKc_info':
(.text+0x12d): warning: Using 'getprotobyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__155.o): In function `sFDs_info':
(.text+0x4c): warning: Using 'getservbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/libpq.a(fe-misc.o): In function `pqSocketCheck':
(.text+0xa2d): undefined reference to `SSL_pending'
/usr/lib/libpq.a(fe-secure.o): In function `SSLerrmessage':
(.text+0x31): undefined reference to `ERR_get_error'
/usr/lib/libpq.a(fe-secure.o): In function `SSLerrmessage':
(.text+0x41): undefined reference to `ERR_reason_error_string'
/usr/lib/libpq.a(fe-secure.o): In function `initialize_SSL':
(.text+0x2f8): undefined reference to `SSL_check_private_key'
/usr/lib/libpq.a(fe-secure.o): In function `initialize_SSL':
(.text+0x3c0): undefined reference to `SSL_CTX_load_verify_locations'
(... snip ...)
If I just compile with just -static and without -optl-static
everything builds fine but the application crashes when it tries to
start on Heroku.
2011-12-28T01:20:51+00:00 heroku[web.1]: Starting process with command
`./dist/build/personal-website/personal-website -p 41083`
2011-12-28T01:20:51+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: error while loading shared libraries: libgmp.so.10:
cannot open shared object file: No such file or directory
2011-12-28T01:20:52+00:00 heroku[web.1]: State changed from starting
to crashed
I tried adding libgmp.so.10 to the LD_LIBRARY_PATH as suggested in here
and then got the following error:
2011-12-28T01:31:23+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: /lib/libc.so.6: version `GLIBC_2.14' not found
(required by ./dist/build/personal-website/personal-website)
2011-12-28T01:31:23+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: /lib/libc.so.6: version `GLIBC_2.14' not found
(required by /app/dist/build/personal-website/libgmp.so.10)
2011-12-28T01:31:25+00:00 heroku[web.1]: State changed from starting
to crashed
2011-12-28T01:31:25+00:00 heroku[web.1]: Process exited
It seems that the version of libc that I'm compiling against is
different. I tried also adding libc to the batch of libraries the
same way I did for libgmp but this results in a segmentation fault
when the application starts on the Heroku side.
Everything works fine on my PC. I'm running 64bit archlinux with ghc
7.0.3. The blog post on the official Yesod blog looked pretty easy
but I'm stumped at this point. Anyone have any ideas? If there's a way to get this thing working without building statically I'm open to that too.
EDIT
Per Employed Russians answer I did the following to fix this.
First created a new directory lib under the project directory and copied the missing shared libraries into it. You can get this information by running ldd path/to/executable and heroku run ldd path/to/executable and comparing the output.
I then did heroku config:add LD_LIBRARY_PATH=./lib so when the application is started the dynamic linker will look for libraries in the new lib directory.
Finally I created an ubuntu 11.10 virtual machine and built and deployed to Heroku from there, this has an old enough glibc that it works on the Heroku host.
Edit:
I've since written a tutorial on the Yesod wiki
I have no idea what Yesod is, but I know exactly what each of your other errors means.
First, you should not try to link statically. The warning you get is exactly right: if you link statically, and use one of the routines for which you are getting the warning, then you must arrange to run on a system with exactly the same version of libc.so.6 as the one you used at build time.
Contrary to popular belief, static linking produces less, not more, portable executables on Linux.
Your other (static) link errors are caused by missing libopenssl.a at link time.
But let's assume that you are going to go the "sane" route, and use dynamic linking.
For dynamic linking, Linux (and most other UNIXes) support backward compatibility: an old binary continues to work on newer systems. But they don't support forward compatibility (a binary built on a newer system will generally not run on an older one).
But that's what you are trying to do: you built on a system with glibc-2.14 (or newer), and you are running on a system with glibc-2.13 (or older).
The other thing you need to know is that glibc is composed of some 200+ binaries that must all match exactly. Two key binaries are /lib/ld-linux.so and /lib/libc.so.6 (but there are many more: libpthread.so.0, libnsl.so.1, etc. etc). If some of these binaries came from different versions of glibc, you usually get a crash. And that is exactly what you got, when you tried to place your glibc-2.14 libc.so.6 on the LD_LIBRARY_PATH -- it no longer matches the system /lib/ld-linux.
So what are the solutions? There are several possibilities (in increasing difficulty):
You could copy ld-2.14.so (the target of /lib/ld-linux symlink) to the target system, and invoke it explicitly:
/path/to/ld-2.14.so --library-path <whatever> /path/to/your/executable
This generally works, but can confuse an application that looks at argv[0], and breaks for applications that re-exec themselves.
You could build on an older system.
You could use appgcc (this option has disappeared, see this for description of what it used to be).
You could set up a chroot environment matching the target system, and build inside that chroot.
You could build yourself a Linux-to-olderLinux crosscompiler
You have several issues.
You should not build production binaries on bleeding edge distributions. The libraries on the production system will not be forward compatible.
You should not link glibc statically - it will always at runtime try to load additional libraries. For example cpu-based assembly. That is what your first warnings are about.
The last linker errors look like they are related to a missing openssl library on the command line.
But all in all - downgrade your distribution.
I had similar problems launching to Heroku (which uses glibc-2.11) where I had an application that required glibc-2.14, but I did not have access to the source and could not re-build it. I tried many things and nothing worked.
My workaround was to launch the service on Amazon Elastic Beanstalk and just provide an API interface.
I found the information provided useful as well, I think the various descriptions miss a critical issue I also ran into while forcing an updated version of Vagrant to start working again.
It's the dependency references internal to something like complicated installs, like Yesod to Heroku. Those interanl refences need to be preserved.
This is the script I wrote to make problems go away (at least, hopefully, for a little while):
#!/bin/bash
cd $HOME/
GLIBC_VERSION="2.17"
GLIBC_PREFIX="/usr/glibc/"
VAGRANT_VERSION="2.2.19"
# Install the basic build system utilities.
yum groupinstall -y "Development tools"
yum install -y curl patchelf
# Grab the tarball with the GNU libc source code.
curl -Lfo glibc-${GLIBC_VERSION}.tar.gz "https://ftp.gnu.org/gnu/glibc/glibc-${GLIBC_VERSION}.tar.gz"
echo "a3b2086d5414e602b4b3d5a8792213feb3be664ffc1efe783a829818d3fca37a glibc-${GLIBC_VERSION}.tar.gz" | sha256sum -c || exit 1
# Extract the secrets and get ready to rumble.
tar xzvf glibc-${GLIBC_VERSION}.tar.gz
# The configure script requrires an independent build directory.
mkdir -p glibc-build && cd glibc-build
# Configure glibc with a GLIBC_PREFIX so it doesn't conflict with distro libc files..
../glibc-${GLIBC_VERSION}/configure --prefix="${GLIBC_PREFIX}" --libdir="${GLIBC_PREFIX}/lib" \
--libexecdir="${GLIBC_PREFIX}/lib" --enable-multi-arch
# Compile and then install GNU libc.
make -j8 && make install
# Download and install Vagrant.
curl -Lfo vagrant_${VAGRANT_VERSION}_x86_64.rpm "https://releases.hashicorp.com/vagrant/${VAGRANT_VERSION}/vagrant_${VAGRANT_VERSION}_x86_64.rpm"
echo "990e8d2159032915f21c0f1ccdcbca1a394f7937e06e43dc1dabe605d208dc20 vagrant_${VAGRANT_VERSION}_x86_64.rpm" | sha256sum -c || exit 1
yum install -y vagrant_${VAGRANT_VERSION}_x86_64.rpm
# Patch the binaries and shared libraries inside the Vagrant directory, so they use the new version of GNU libc.
(find /opt/vagrant/ -type f -exec file {} \; )| grep "dynamically linked" | awk -F':' '{print $1}' | while read FILE ; do
patchelf --set-rpath /opt/vagrant/embedded/lib:/opt/vagrant/embedded/lib64:/usr/glibc/lib:/usr/lib64:/lib64:/lib --set-interpreter /usr/glibc/lib/ld-linux-x86-64.so.2 "${FILE}"
done
The script should be pretty easy to understand, and adapt easily to whatever MacGuffin you want to make work, provied you understand it.
The only tricky part is the rpath you pass to patchelf. Upi need to make sure you preserve the search paths, and precedence your software requires. Or you end up fixing one problem only to create another equally frustrating roadblock.
P.S. Don't forget the update the hashes for any file you down. In particular, you need to compile/install a different version of GNU libc, you will need to update that hash to match the version you want to use.
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
I'm trying to use make install, and I get error:
cannot find -lcurses
In my /usr/lib/curses/ I have two files: libcurses.so and libcurses.a.
So I do have that library, gcc just doesn't see it. I've read almost everything I can find but still couldn't make this work.
Any help would be appreciated.
This is output:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'samtools' failed
make: *** [samtools] Error 1
Note: I've read every similar topic on this website, so please, don't mark this as duplicate.
The linker says:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: \
skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
You are performing a 64-bit build, but the the only libcurses.so the linker
can find is 32-bit, so it is skipped.
It is unclear from your several postings how this 32-bit /usr/lib/libcurses.so got
there. The official latest openSUSE
curses runtime package is libncurses5-5.9-53.4.x86_64.rpm. The official latest developent package is ncurses-devel-5.9-53.4.x86_64.rpm.
If you install either of these packages, they do not place any 32-bit binaries under /usr/lib, so I surmise
that your /usr/lib/libcurses.so got there in some unorthodox way.
Delete this /usr/lib/libcurses.so. Install the ncurses-devel rpm from your distribution's package manager,
e.g.zypper install ncurses-devel. To make sure you have done it successfully, check that /usr/lib64/libncurses.so exists afterwards.
Then in your makefile change:
LIBCURSES= -lcurses
to:
LIBCURSES= -lncurses
You will find that this change is described in paragraph 3 of the samtools INSTALL file.
You need a development library for ncurses installed, i.e., ncurses-devel (for SuSE).
Without the development library, the shared libraries for ncurses are only present as runtime files.
The ncurses development package installs files or symbolic links to make these options work: -lcurses, -lncurses (since the former is standard). It also installs the file to make -lncursesw link, but OP is not using that.
That message
skipping incompatible /usr/lib/libcurses.so
makes it seem as if OP copied files from some other system rather than installing OpenSuSE packages.
The extra question in SuperUser (GCC ld: can't find -lcurses) gives more information, but not enough to see why the file /usr/lib/libcurses.so is incompatible. It may be conflicting with the development package, however.
Pantheios INSTALL.TXT says:
Open a command shell in the appropriate directory that matches your compiler: ...
My compiler is Clang:
> gcc --version
Apple LLVM version 5.1 (clang-503.0.40) ...
Target: x86_64-apple-darwin13.3.0
Which of the compiler settings files in Pantheios 1.0.1-beta214 is the most appropriate?
You can use homebrew to install an older version of gcc (e.g., gcc-4.2) and use the matching Pantheios makefile, like this:
brew install gcc42
make CC=gcc-4.2
However, as far as I have been able to tell, Pantheios is not going to be buildable on a recently-updated system. For example, as of today, building on OSX looks like this:
04:29:23 ~/src/pantheios-1.0.1-beta214/build/gcc42.unix$ make CC=gcc-4.2
Ensuring all STLSoft C source files are in UNIX format
sed: RE error: illegal byte sequence
make: *** [/Users/username/src/stlsoft-1.9.118/include/stlsoft/internal/dos2unix.has.been.performed] Error 1
I have also tried building on Windows as recently as 6 months ago and lost a good bit of time on it before giving up.
The library hasn't been updated in a very long time and the author has very little online activity since then. I call that "abandoned software". Building will very likely require a non-trivial amount of work on your part. I'd highly recommend severing the dependency on STLSoft if you do because it also appears to be abandoned.
haskell 'openid' package depends on HsOpenSSL and nano-hmac packages which requires openssl. I've compiled openssl for MinGW in C:\OpenSSL\ directory and installed openid package with following command:
cabal install openid --extra-include-dirs=C:\OpenSSL\outinc --extra-lib-dirs=C:\OpenSSL\out
When I'm trying to compile haskell program using this package I'm receiving lots linking errors.
test.hs:
import Network.OpenID
main = print "ok"
ghc --make test.hs:
Linking test.exe ...
C:\OpenSSL\out/libcrypto.a(m_sha1.o):m_sha1.c:(.text+0x60): multiple definition of `EVP_sha1'
C:\OpenSSL\out/libeay32.a(deegs01228.o):(.text+0x0): first defined here
C:\OpenSSL\out/libcrypto.a(m_sha1.o):m_sha1.c:(.text+0x100): multiple definition of `EVP_sha256'
C:\OpenSSL\out/libeay32.a(deegs01230.o):(.text+0x0): first defined here
.....
C:\OpenSSL\out/libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x2d4): undefined reference to `X509_VERIFY_PARAM_set_purpose'
C:\OpenSSL\out/libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x2f1): undefined reference to `X509_VERIFY_PARAM_set_purpose'
C:\OpenSSL\out/libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x314): undefined reference to `X509_VERIFY_PARAM_set_trust'
.....
collect2: ld returned 1 exit status
What I'm doing wrong?
I suspect there may be a version mismatch somewhere. Try using the precompiled binaries for OpenSSL here: http://www.openssl.org/related/binaries.html
I was able to get the instructions here to work with the latest version of HsOpenSSL: http://hackage.haskell.org/trac/ghc/wiki/Builder (in fact I worked with the maintainer to make these instructions work without needing to patch the package.)