I am running Ubuntu and need to use a 32 bit version of ncurses with my program. I downloaded ncurses-5.9 using wget from http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.9.tar.gz. I then entered:
gzip -dc < ncurses-5.9.tar.gz | tar -xf -
cd ncurses-5.9
At this point I followed all the instructions listed here (I have listed them below as well:
CC="gcc ${BUILD32}" CXX="g++ ${BUILD32}" \
./configure --prefix=/usr --libdir=/lib \
--with-shared --without-debug --enable-widec \
--with-manpage-format=normal \
--with-default-terminfo-dir=/usr/share/terminfo
make
make install
mv -v /usr/bin/ncursesw5-config{,-32}
mv -v /lib/lib{panelw,menuw,formw,ncursesw,ncurses++w}.a /usr/lib
rm -v /lib/lib{ncursesw,menuw,panelw,formw}.so
ln -svf ../../lib/libncursesw.so.5 /usr/lib/libncursesw.so
ln -svf ../../lib/libmenuw.so.5 /usr/lib/libmenuw.so
ln -svf ../../lib/libpanelw.so.5 /usr/lib/libpanelw.so
ln -svf ../../lib/libformw.so.5 /usr/lib/libformw.so
All of these commands executed successfully. When I go to run my program however, I use the appropriate flag -lncurses yet I get back the error: /usr/bin/ld: cannot find -lncurses
From the terminal I can see that libncurses libncurses++w.a libncursesw.a libncursesw.so are all in /usr/lib and ncurses5-config ncursesw5-config-32
are in /usr/lib.
Please advise as to what I should try to change, thanks much!
Related
I'm trying to statically build my rust application, using MUSL.
My application uses sqlcipher. This means a statically built executable must include the openssl and sqlcipher C libraries.
I'm using https://github.com/emk/rust-musl-builder, so I wrote a Dockerfile which starts with their dockerfile, which already provides a MUSL environment including a statically built musl-enabled openssl.
So "all I need" is to build sqlcipher and then my rust application. Unfortunately this has a proven very complicated for me.
Here is my current docker file:
FROM ekidd/rust-musl-builder
# sqlcipher requirements
ENV TZ=Europe/Ljubljana
RUN sudo sh -c "ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone"
RUN sudo apt update
RUN sudo apt install tcl -y
# sqlcipher
RUN VERS=4.4.1 && \
cd /home/rust/libs && \
curl -LO https://github.com/sqlcipher/sqlcipher/archive/v$VERS.tar.gz && \
tar xzf v$VERS.tar.gz && cd sqlcipher-$VERS && \
CC=musl-gcc ./configure --host=x86_64-pc-linux-gnu --target=x86_64-linux-musl --prefix=/usr/local/musl --disable-tcl --disable-shared --with-crypto-lib=none --enable-static=yes --enable-tempstore=yes CFLAGS="-DSQLITE_HAS_CODEC -DSQLCIPHER_CRYPTO_OPENSSL -I/usr/include/x86_64-linux-musl -I/usr/local/musl/include -I/usr/local/musl/include/openssl" LDFLAGS=" /usr/local/musl/lib/libcrypto.a" && \
make && sudo make install && \
cd .. && rm -rf v$VERS.tar.gz sqlcipher-$VERS
# bring in my rust source
ADD --chown=rust:rust ./ .
# build my rust code
ENV RUSTFLAGS='-L/usr/local/musl/lib -L/usr/lib/x86_64-linux-musl -L/lib/x86_64-linux-musl -C linker=musl-gcc -Clink-arg=/usr/local/musl/lib/libcrypto.a -Clink-arg=/usr/local/musl/lib/libsqlcipher.a -C link-arg=/lib/ld-musl-x86_64.so.1 -Clink-arg=/usr/lib/x86_64-linux-musl/libc.a -Ctarget-feature=-crt-static -Clink-arg=-no-pie -C target-feature=+crt-static'
ENV PKG_CONFIG_ALLOW_CROSS=1
ENV PKG_CONFIG_ALL_STATIC=true
ENV OPENSSL_STATIC=true
ENV LIBZ_SYS_STATIC=1
CMD cargo build --target x86_64-unknown-linux-musl --release --bin projectpad-cli && cp /home/rust/src/target/x86_64-unknown-linux-musl/release/projectpad-cli /host
(my rust source is at https://github.com/emmanueltouzery/projectpad2)
This succeeds entirely and generates a binary, but it's not statically linked:
ldd projectpad-cli
/lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f56d6749000)
linux-vdso.so.1 (0x00007fff301f7000)
file projectpad-cli
projectpad-cli: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped
Attempting to run this binary crashes in malloc_usable_size () from /lib/ld-musl-x86_64.so.1.
I believe it's because my system doesn't have the MUSL linker and so it uses the glibc/gcc one, and this causes issues.
I'm thinking that if I could manage to produce a really static binary, that wouldn't have references to the linker, this would possibly work.
Any idea what I'm doing wrong? I experimented with some builder.rs printlns, but I currently don't have any.
OK, I found it...
I'm pretty sure the problem was the -C link-arg=/lib/ld-musl-x86_64.so.1 flag. This more or less forced a dynamic executable I think. Removing it fixed the issue :-)
# -*- mode: dockerfile -*-
#
# An example Dockerfile showing how to add new static C libraries using
# musl-gcc.
FROM ekidd/rust-musl-builder
# https://rtfm.co.ua/en/docker-configure-tzdata-and-timezone-during-build/
ENV TZ=Europe/Ljubljana
RUN sudo sh -c "ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone"
RUN sudo apt update
RUN sudo apt install tcl -y
# Build a static copy of sqlcipher.
# https://github.com/sqlcipher/sqlcipher/issues/132#issuecomment-122908672
# also related https://discuss.zetetic.net/t/cross-compile-sqlicipher-for-arm/2104/4
# https://github.com/sqlcipher/sqlcipher/issues/276
# https://github.com/rust-lang/rust/issues/40049
RUN VERS=4.4.1 && \
cd /home/rust/libs && \
curl -LO https://github.com/sqlcipher/sqlcipher/archive/v$VERS.tar.gz && \
tar xzf v$VERS.tar.gz && cd sqlcipher-$VERS && \
CC=musl-gcc ./configure --host=x86_64-pc-linux-gnu --target=x86_64-linux-musl --prefix=/usr/local/musl --disable-tcl --disable-shared --with-crypto-lib=none --enable-static=yes --enable-tempstore=yes CFLAGS="-DSQLITE_HAS_CODEC -DSQLCIPHER_CRYPTO_OPENSSL -I/usr/include/x86_64-linux-musl -I/usr/local/musl/include -I/usr/local/musl/include/openssl" LDFLAGS=" /usr/local/musl/lib/libcrypto.a" && \
make && sudo make install && \
cd .. && rm -rf v$VERS.tar.gz sqlcipher-$VERS
ADD --chown=rust:rust ./ .
# https://stackoverflow.com/questions/40695010/how-to-compile-a-static-musl-binary-of-a-rust-project-with-native-dependencies
# https://github.com/rust-lang/rust/issues/54243
ENV RUSTFLAGS='-L/usr/local/musl/lib -L/usr/lib/x86_64-linux-musl -L/lib/x86_64-linux-musl -C linker=musl-gcc -Clink-arg=/usr/local/musl/lib/libcrypto.a -Clink-arg=/usr/local/musl/lib/libsqlcipher.a -Clink-arg=/usr/lib/x86_64-linux-musl/libc.a'
ENV PKG_CONFIG_ALLOW_CROSS=1
ENV PKG_CONFIG_ALL_STATIC=true
ENV OPENSSL_STATIC=true
ENV LIBZ_SYS_STATIC=1
CMD cargo build --target x86_64-unknown-linux-musl --release --bin projectpad-cli && cp /home/rust/src/target/x86_64-unknown-linux-musl/release/projectpad-cli /host
I'm trying to build and install my own gcc 4.7.2 in /usr/local to use in place of the gcc 4.4.6 in /usr. (This is on CentOS 6.3.)
gcc makes executables and dynamic libraries that dynamically link to its own dynamic libraries, e.g. libstdc++.so. How do I build and install gcc so that the generated binaries automatically get a linker -rpath option (-rpath /usr/local/lib64) that causes dynamic libraries in /usr/local/lib64 to be linked instead of those in /usr/lib64 or /lib64?
If it works properly, after I build an executable with the gcc without specifying "-Wl,-rpath=/usr/local/lib64", when I ldd the executable, it should show /usr/local/lib64/libstdc++.so.6 instead of /usr/lib64/libstdc++.so.6. Similarly for the libgcc_s.so.1.
I have tried different approaches, including specifying LDFLAGS_FOR_TARGET=-Wl,-rpath=/usr/local/lib64,-rpath=/usr/local/lib on the 'configure' command-line, but nothing worked.
If you don't want to export paths there's an alternative solution:
with your toolchain in the PATH:
gcc -dumpspecs > specsfile
edit specsfile and in the section link add your -rpath example:
*link:
%{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic} -dynamic-linker %(dynamic_linker)} %{static:-static}} -rpath /usr/local/lib64
at this point you can test if it work with:
g++ -specs=specsfile test.cpp
readelf -d a.out |grep RPATH
if it work you can make it permanent (no need to pass -specs everytime)
strace -fF -o /tmp/g++.log g++ test.cpp
grep specs /tmp/g++.log
the grep should show the paths where gcc look for the default specs file.
The specs files are flexible enough to allow conditional linking depending on variables, example:
{!static: %{mabi=n32:-rpath-link %R/lib32:%R/usr/lib32} %{mabi=64:-rpath-link %R/lib64:%R/usr/lib64} %{mabi=32:-rpath-link %R/lib:%R/usr/lib}}
should use different and multiple paths depending on mabi (untested, yet), %R should be the sysroot path, can be changed with needed full path.
There's also a --with-specs= option gcc configure eventually to be used at build time, not clear to me yet how to use with the link section (working on it).
--with-specs="%{shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}%{!shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}"
It work, I used both shared and not !shared just for test, probably some smarter condition should be used, note that it isn't reported with -dumpspecs.
Reading through some thread of the gcc mailing list I had the impression specs aren't liked by everyone (but if I'm not wrong 4.9 add another option --with-extra-specs) instead preferred way to do such customizations appears to be configure.host, but I'm done and not looking into it, have fun! :-)
see also: gcc faq rpath
update above
I don't know if you can set a pre-defined rpath, probably if you can would be in the linker ld of binutils not in gcc/g++, but why would you do that?
Just export LD_LIBRARY_PATH at runtime and LD_RUN_PATH at build time
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
ldd a.out
ldd should show the paths you exported.
To quote a message given when a shared library is built with libtool:
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
add LIBDIR to the `LD_RUN_PATH' environment variable during linking
use the `-Wl,--rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
for completeness
the Makefile I used for testing the thing, all the configure options, environment variables (see boot ldflags) I tried didn't work, --enable-rpath included.
use with mkdir ~/gcc copy the Makefile below into ~/gcc then cd ~/gcc && make build-gcc
notice the options used are only for this test case, don't use as reference.
FETCH = aria2c --file-allocation=none -c -d dl
NICE = nice -n 19
PARALLEL = -j4
DESTDIR = $(HOME)/gcc/install
SRCDIR = $(HOME)/gcc/src
all:
# if more downloads are added just remove {dl,src}/*-my-stamp not the .bak
# the .bak should avoid to rebuild targets because of timestamp
touch_stamp = if [ -f $#.bak ]; then \
touch -r $#.bak $#; \
else \
touch $# $#.bak; \
fi
dl/dl-my-stamp:
$(FETCH) https://ftp.gnu.org/gnu/gcc/gcc-4.7.2/gcc-4.7.2.tar.bz2
$(FETCH) http://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2
$(FETCH) ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz
$(FETCH) https://ftp.gnu.org/gnu/mpfr/mpfr-2.4.2.tar.bz2
$(FETCH) --check-certificate=false http://www.mirrorservice.org/sites/sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2 \
ftp://sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2
$(touch_stamp)
untar_dep = src/untar-my-stamp
src/untar-my-stamp: dl/dl-my-stamp
mkdir -p src
tar -C src -xjf dl/gcc-4.7.2.tar.bz2
tar -C src -xjf dl/gmp-4.3.2.tar.bz2
tar -C src -xzf dl/mpc-0.8.1.tar.gz
tar -C src -xjf dl/mpfr-2.4.2.tar.bz2
tar -C src -xjf dl/binutils-2.24.51.tar.bz2
$(touch_stamp)
define configure-rule
$(1)_install = $(DESTDIR)/$(1)-install-my-stamp
$(1)_builddir = $$($(1)_dir)/build
$(DESTDIR)/$(1)-install-my-stamp: $$($(1)_deps)
mkdir -p $$($(1)_builddir)
cd $$($(1)_builddir) && \
$$($(1)_env) ../configure --cache-file=$(SRCDIR)/$(1)-config.cache \
$$($(1)_configure)
$(NICE) make -C $$($(1)_builddir) $$($(1)_make_target) $(PARALLEL)
ifneq ($$($(1)_post_make),)
$$($(1)_post_make)
endif
touch $$#
.PHONY: build-$(1) clean-$(1)
build-$(1): $$($(1)_install)
clean-$(1):
-rm -fr $$($(1)_builddir)
endef
gmp_dir = src/gmp-4.3.2
gmp_env = CONFIG_SITE=$(SRCDIR)/config.site
gmp_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static --enable-cxx
gmp_deps = $(untar_dep)
gmp_make_target = install
$(eval $(call configure-rule,gmp))
mpfr_dir = src/mpfr-2.4.2
mpfr_env = CONFIG_SITE=$(SRCDIR)/config.site
mpfr_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR)
mpfr_deps = $(untar_dep) $(gmp_install)
mpfr_make_target = install
$(eval $(call configure-rule,mpfr))
mpc_dir = src/mpc-0.8.1
mpc_env = CONFIG_SITE=$(SRCDIR)/config.site
mpc_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR)
mpc_deps = $(untar_dep) $(gmp_install) $(mpfr_install)
mpc_make_target = install
$(eval $(call configure-rule,mpc))
gcc_dir = src/gcc-4.7.2
gcc_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
CXXFLAGS="-I/usr/include/i386-linux-gnu"
gcc_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-local-prefix=$(DESTDIR) \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR) \
--with-mpc=$(DESTDIR) \
--disable-bootstrap \
--enable-languages=c,c++ \
--disable-libgomp --disable-multilib \
--disable-libmudflap --disable-libssp \
--disable-libquadmath \
--enable-rpath \
MAKEINFO=missing
gcc_deps = $(untar_dep) $(gmp_install) $(mpfr_install) $(mpc_install)
gcc_make_target =
gcc_post_make = make -C $(gcc_builddir) install
$(eval $(call configure-rule,gcc))
binutils_dir = src/binutils-2.24.51
#binutils_env = LDFLAGS=-Wl,-rpath\ $(DESTDIR)/lib
binutils_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
BOOT_LDFLAGS="-rpath-link=$(DESTDIR)/lib -rpath=$(DESTDIR)/lib"
binutils_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-gmp=$(DESTDIR) \
--enable-rpath
binutils_deps = $(untar_dep) $(gmp_install)
#binutils_make_target = install
binutils_post_make = make -C $(binutils_builddir) install
$(eval $(call configure-rule,binutils))
.PHONY: env
env:
#echo export PATH=$(DESTDIR)/bin:\$$PATH
#echo export LIBRARY_PATH=/usr/lib/i386-linux-gnu
I was installing httpd-2.4.51 and needed to specify -rpath to compile the program. I use the linker flag -Wl,-rpath -Wl,LIBDIR.
Use commands:
sudo mv httpd.c /usr/lib #create a .c file and move it to the default directory for the library file
sudo gcc -o httpd httpd.c -L$--prefix=/usr/lib -lhttpd -Wl,-rpath=$--prefix=/usr/lib
Your can check where you have gcc installed:
whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/share/man/man1/gcc.1.gz
I am trying to update my OpenVPN and OpenSSL.
While updating openvpn to openvpn-2.4.4, I was required to update my openssl first to the latest openssl-1.0.2n
$ cd~
$ wget https://openvpn.net/index.php/download/openvpn-2.4.4.tar.gz
$ sudo tar -zvxf openvpn--2.4.4.tar.gz
$ cd openvpn-2.4.4
$ sudo ./configure
$ sudo make
$ sudo make install
But when I reach ./configure above, I run into an issue with legacy openssl as I have mentioned earlier (i thought an update would fix that):
checking tap-windows.h presence... no
checking for tap-windows.h... no
checking whether TUNSETPERSIST is declared... yes
checking for setcon in -lselinux... no
checking for pam_start in -lpam... no
checking for PKCS11_HELPER... no
checking for OPENSSL... no
checking for SSL_CTX_new... no
configure: error: openssl check failed
So I tried the following commands to update to the latest openssl :
$ cd /usr/src
$ wget https://www.openssl.org/source/openssl-1.0.2n.tar.gz -O openssl-1.0.2n.tar.gz
$ tar -zxf openssl-1.0.2n.tar.gz
$ cd openssl-1.0.2n
$ ./config
$ sudo make
$ sudo make test
$ sudo make install
$ mv /usr/bin/openssl /root/
$ ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl
$ openssl version
When I get to make test, I run into a compilation error. I have copy pasted my terminal output here because that output is HUGE, error is in the bottom : pastebin
Any suggestions how I can move past this issue?
RELEASE=18 sarah, EDITION=Cinnamon 32-bit, GRUB_TITLE=Linux Mint 18 Cinnamon 32-bit
Judging from your output, you need to run all three commands as sudo, and you missed the initial make.
elliot#warmachine /usr/src/openssl-1.0.2n $ sudo ./config
...
elliot#warmachine /usr/src/openssl-1.0.2n $ make
...
/bin/sh: 1: cannot create buildinf.h: Permission denied
Makefile:58: recipe for target 'buildinf.h' failed
which fails as it does not have permissions to write to the directory, which causes sudo make test to fail because openssl hasn't been built:
/usr/bin/ld: cannot find -lssl
collect2: error: ld returned 1 exit status
-l{library_name} is what ld uses to link in external libraries, meaning test cannot find the openssl .so that should have been built in previous steps
Lastly, it is bad practice to build software as root. My recommendation is to build it as an unprivileged user, then install as root.
$ cd ~
$ wget https://www.openssl.org/source/openssl-1.0.2n.tar.gz -O openssl-1.0.2n.tar.gz
$ tar -zxf openssl-1.0.2n.tar.gz
$ cd openssl-1.0.2n
$ ./config
$ make
$ make test
$ sudo make install
I'm trying to write a Makefile which compiles a cross compiler.
It downloads GCC and binutils, extract the archive, run the configure script and run make.
This is the Makefile I wrote:
# Versions
GCC_VERSION := 6.3.0
BINUTILS_VERSION := 2.27
# Build
TARGET ?= i686-elf
PREFIX := $(realpath build)
# Phony tasks
.PHONY: all clean gcc binutils
# Targets
BINUTILS_TARGETS := build/bin/${TARGET}-addr2line build/bin/${TARGET}-ar \
build/bin/${TARGET}-as build/bin/${TARGET}-c++filt \
build/bin/${TARGET}-elfedit build/bin/${TARGET}-gprof \
build/bin/${TARGET}-ld build/bin/${TARGET}-ld.bfd build/bin/${TARGET}-nm \
build/bin/${TARGET}-objcopy build/bin/${TARGET}-objdump \
build/bin/${TARGET}-ranlib build/bin/${TARGET}-readelf \
build/bin/${TARGET}-size build/bin/${TARGET}-strings \
build/bin/${TARGET}-strip
GCC_TARGETS := build/bin/${TARGET}-cpp build/bin/${TARGET}-gcc \
build/bin/${TARGET}-gcc-${GCC_VERSION} build/bin/${TARGET}-gcc-ar \
build/bin/${TARGET}-gcc-nm build/bin/${TARGET}-gcc-ranlib \
build/bin/${TARGET}-gcov build/bin/${TARGET}-gcov-tool
# Aliases
all: binutils gcc
gcc: ${GCC_TARGETS}
binutils: ${BINUTILS_TARGETS}
# Download the packages
packages/gcc-${GCC_VERSION}.tar.bz2:
curl ftp://ftp.gnu.org/gnu/gcc/gcc-${GCC_VERSION}/gcc-${GCC_VERSION}.tar.bz2 \
-o $#
packages/binutils-${BINUTILS_VERSION}.tar.bz2:
curl ftp://ftp.gnu.org/gnu/binutils/binutils-${BINUTILS_VERSION}.tar.bz2 \
-o $#
# Extract them
packages/gcc-${GCC_VERSION}/configure: packages/gcc-${GCC_VERSION}.tar.bz2
tar -xmjf $< -C packages
packages/binutils-${BINUTILS_VERSION}/configure: packages/binutils-${BINUTILS_VERSION}.tar.bz2
tar -xmjf $< -C packages
# Build them
${GCC_TARGETS}: packages/gcc-${GCC_VERSION}/configure
mkdir -p build/gcc
cd build/gcc && ../../packages/gcc-${GCC_VERSION}/configure \
--target=${TARGET} --prefix=${PREFIX} --disable-nls \
--enable-languages=c --without-headers && make all-gcc && \
make all-target-libgcc && make install-gcc && make install-target-libgcc
${BINUTILS_TARGETS}: packages/binutils-${BINUTILS_VERSION}/configure
mkdir -p build/binutils
cd build/binutils && ../../packages/binutils-${BINUTILS_VERSION}/configure \
--target=${TARGET} --prefix=${PREFIX} --with-sysroot --disable-nls \
--disable-werror && make && make install
# Clean everything
clean:
rm -rf build/*
rm -rf packages/*
It works when running make with no options, but when I use the jobs option, it fails (but not everytime): it download binutils and GCC in parallel.
When binutils is fully downloaded, it extracts it and compiles it, then the GCC download ends, but it doesn't do anything and there are no errors.
Also sometimes the compilation of GCC or binutils fails with strange errors (I will edit this post with some of them).
Not sure about the exact source of your specific build failures, but the Makefile is problematic: the 2 build rules have multiple targets. Make does not support this well, see here for an explanation.
Make with jobs fails because it starts multiple instances of the same recipe but these instances can't run together correctly.
${GCC_TARGETS}: packages/gcc-${GCC_VERSION}/configure
mkdir -p build/gcc
cd build/gcc && ../../packages/gcc-${GCC_VERSION}/configure ... make ...
This is trouble maker, I guess, because Make with jobs initiates multiple configure invocations in the same directory to run asynchronously. So you have multiple configure scripts running and adding bits to the same directory. And then multiple instances of Make are invoked in the same build directory. Perfect mess.
Something like:
${GCC_TARGETS}: packages/gcc-${GCC_VERSION}/configure
mkdir -p build/gcc/$(nodir $#) && cd build/gcc/$(nodir $#) ...
Should fix the problem by means of starting configure & make sequences in different directories. You need similar fix for ${BINUTILS_TARGETS} too.
I compiled the library GLEW. It seemed to work fine, here is the output of make install:
install -d -m 0755 "/usr/include/GL"
install -m 0644 include/GL/wglew.h "/usr/include/GL/"
install -m 0644 include/GL/glew.h "/usr/include/GL/"
install -m 0644 include/GL/glxew.h "/usr/include/GL/"
sed \
-e "s|#prefix#|/usr|g" \
-e "s|#libdir#|/usr/lib64|g" \
-e "s|#exec_prefix#|/usr/bin|g" \
-e "s|#includedir#|/usr/include/GL|g" \
-e "s|#version#|1.11.0|g" \
-e "s|#cflags#||g" \
-e "s|#libname#|GLEW|g" \
-e "s|#requireslib#|glu|g" \
< glew.pc.in > glew.pc
install -d -m 0755 "/usr/lib64"
install -m 0644 lib/libGLEW.so.1.11.0 "/usr/lib64/"
ln -sf libGLEW.so.1.11.0 "/usr/lib64/libGLEW.so.1.11"
ln -sf libGLEW.so.1.11.0 "/usr/lib64/libGLEW.so"
install -m 0644 lib/libGLEW.a "/usr/lib64/"
install -d -m 0755 "/usr/lib64"
install -d -m 0755 "/usr/lib64/pkgconfig"
install -m 0644 glew.pc "/usr/lib64/pkgconfig/"
Now I wanted to use it on a KDevelop project. I created my CMakeLists.txt and linked the library there using find_package:
cmake_minimum_required( VERSION 2.6 )
project(openglengine)
include_directories(headers)
set(SOURCE_FILES src/main.cpp)
set(CMAKE_CXX_FLAGS "--pedantic-errors -Wall -std=gnu++11")
add_executable(openglengine ${SOURCE_FILES} ${HEADER_FILES})
find_package(PkgConfig REQUIRED)
pkg_search_module(GLFW REQUIRED glfw3)
include_directories(${GLFW_INCLUDE_DIRS})
target_link_libraries(openglengine ${GLFW_STATIC_LIBRARIES})
find_package(GLEW)
if (GLEW_FOUND)
include_directories(${GLEW_INCLUDE_DIRS})
target_link_libraries (openglengine ${GLEW_LIBRARIES})
endif (GLEW_FOUND)
install(TARGETS openglengine RUNTIME DESTINATION ~/projects/OpenGLEngine/bin)
I get no build errors.
When I try to run the program here is the output:
error while loading shared libraries: libGLEW.so.1.11: cannot open shared object file: No such file or directory
Any help will be appreciated.
EDIT:
Using the command locate libGLEW I get this output:
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.6
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.6.0
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.10
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.10.0
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.6
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.6.0
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.a
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.so
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.so.1.11
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.so.1.11.0
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.a
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.so
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.so.1.11
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.so.1.11.0
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.a
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.so
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.so.1.11
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.so.1.11.0
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.a
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.so
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.so.1.11
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.so.1.11.0
/usr/lib64/libGLEW.a
/usr/lib64/libGLEW.so
/usr/lib64/libGLEW.so.1.11
/usr/lib64/libGLEW.so.1.11.0
Which show that I have the library. Does that mean that the command find_package may be not working? Which is strange because I get no link errors.
So, I managed to make it work by creating a symbolic link in /usr/lib/ for the library that was in /usr/lib64.
sudo ln -s /usr/lib64/libGLEW.so.1.11 /usr/lib/libGLEW.so.1.11
Now it works fine. Since I am no expert on linux I don't know if that will bring me problems in the future.
I don't know if the answer by #Ihahn will have any issues but, if the some program is not finding your shared libraries, then first find the folder that your library was installed and is not in your shared library folder and then run sudo ldconfig <location_where_your_library_or_program_was_installed>. Sometimes this happens when you're installing/building programs via make install.Reference here..