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
Related
With this zip file, this Node script successfully outputs the files:
const child_process = require('child_process')
const util = require('util')
const exec = util.promisify(child_process.exec)
exec(`unzip -Z1 metamorpR.zip`).then(zip_contents => {
if (zip_contents.stderr) {
throw new Error(`unzip error: ${zip_contents.stderr}`)
}
console.log(zip_contents.stdout)
})
metamorpR.z5
Варианты Прохождения.txt
Интерактивная Литература.pdf
But when I run the script from within Docker, it doesn't.
Using this Dockerfile:
FROM node:16-alpine
RUN apk add --no-cache unzip
COPY . .
ENTRYPOINT ["node", "unzip.js"]
Build and run (substitute in your container image name):
docker build .
docker run --rm 1dc072
Output:
metamorpR.z5
??????? ????????.txt
???????????? ??????????.pdf
I think this means the locales aren't set correctly within the Docker image? Any ideas how to fix this?
TL;DR
unzip on alpine doesn't appear to support locales. unzip on debian doesn't appear to support locales either. unzip on ubuntu supports using locales (however there exists no official node ubuntu image).
On ubuntu:
FROM ubuntu:18.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && \
apt-get install -y --no-install-recommends \
locales \
unzip && \
apt-get clean
RUN sed -i -e 's/# ru_RU.UTF-8 UTF-8/ru_RU.UTF-8 UTF-8/' /etc/locale.gen && \
locale-gen && \
update-locale LANG=ru_RU.UTF-8 LC_ALL=ru_RU.UTF-8 && \
ldconfig
ENV LANG=ru_RU.UTF-8
COPY metamorpR.zip /metamorpR.zip
CMD ["unzip", "-l", "metamorpR.zip"]
... there are no issues in the unzip file name output:
... however the same build FROM node:16-bullseye won't produce the same results:
You could apply this patch during the build, then generate the locales, however unzip doesn't appear to use the locales:
FROM node:16-alpine
RUN apk add --no-cache unzip wget
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub && \
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.34-r0/glibc-2.34-r0.apk && \
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.34-r0/glibc-bin-2.34-r0.apk && \
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.34-r0/glibc-i18n-2.34-r0.apk && \
apk add glibc-2.34-r0.apk glibc-bin-2.34-r0.apk glibc-i18n-2.34-r0.apk && \
rm /glibc-2.34-r0.apk /glibc-bin-2.34-r0.apk /glibc-i18n-2.34-r0.apk && \
/usr/glibc-compat/bin/localedef -i ru_RU -f UTF-8 ru_RU.UTF-8
ENV LANG=ru_RU.UTF-8
COPY metamorpR.zip /metamorpR.zip
CMD ["unzip", "-l", "metamorpR.zip"]
Thanks to #masseyb's answer, I was able to get it working with this Dockerfile, which basically just installs Node manually into an Ubuntu image. The main downside is the image is twice the size, but it's comparatively simple so that's an acceptable downside to me.
FROM ubuntu:20.04
RUN apt-get update && \
apt install -y curl locales unzip && \
curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && \
apt install -y nodejs && \
rm -rf /var/lib/apt/lists/* && \
localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8
ENV LANG en_US.UTF-8
COPY . .
ENTRYPOINT ["node", "unzip.js"]
Apparently some versions of unzip that is available from Ubuntu repositories can handle automatic decoding of filenames if you specify the -a switch.
I am trying to setup CI in GitLab.
Building OS: Alpine Linux Container, actually it is Docker-In-Docker
image. (see Dockerfile below)
Targeting OS: x86_64-unknown-linux-gnu
Building Tool: cross https://github.com/rust-embedded/cross
Error: undefined reference to `__res_init'
Full log : https://github.com/rust-embedded/cross/files/4894721/build.log
Here is Dockerfile of Alpine running cross
FROM docker:stable-dind
RUN apk add --no-cache ca-certificates gcc mingw-w64-gcc libc-dev musl-dev
# Copied from https://github.com/rust-lang/docker-rust/blob/6314c6bc3d54d5b9284458c6a9061ef5766c9607/1.44.1/alpine3.12/Dockerfile
ENV RUSTUP_HOME=/usr/local/rustup \
CARGO_HOME=/usr/local/cargo \
PATH=/usr/local/cargo/bin:$PATH \
RUST_VERSION=1.44.1
RUN set -eux; \
url="https://static.rust-lang.org/rustup/archive/1.21.1/x86_64-unknown-linux-musl/rustup-init"; \
wget "$url"; \
echo "0c86d467982bdf5c4b8d844bf8c3f7fc602cc4ac30b29262b8941d6d8b363d7e *rustup-init" | sha256sum -c -; \
chmod +x rustup-init; \
./rustup-init -y --no-modify-path --profile minimal --default-toolchain $RUST_VERSION; \
rm rustup-init; \
chmod -R a+w $RUSTUP_HOME $CARGO_HOME; \
rustup --version; \
cargo --version; \
rustc --version;
RUN cargo install cross
RUN rustup target add x86_64-pc-windows-gnu
RUN rustup target add x86_64-unknown-linux-gnu
ENV CROSS_DOCKER_IN_DOCKER=true
RUN mkdir ~/.cargo/ && \
printf "\n[target.x86_64-pc-windows-gnu]" >> ~/.cargo/config && \
printf "\nlinker = \"/usr/bin/x86_64-w64-mingw32-gcc\"" >> ~/.cargo/config
I am using a docker container to execute a python script located at my host machine. The script should make a new directory at a target location.
When the target location is located under $HOME or $HOME/*, everything works. However, when I want to create a directory at /media/my_name/external_drive, the terminal says that PermissionError: [Errno 13] Permission denied: '/media/my_name'
Here is the code I run
sudo docker-compose run --rm --user="$(id -u):$(id -g)" main process_all.py
Here is docker-compose.yml:
version: '2.3'
services:
main:
build: .
volumes:
- .:/app
- /etc/localtime:/etc/localtime:ro
environment:
- PYTHONIOENCODING=utf_8
init: true
network_mode: host
Here is the dockerfile
FROM ubuntu:16.04
# Install some basic utilities
RUN apt-get update && apt-get install -y \
curl \
ca-certificates \
sudo \
git \
bzip2 \
axel \
&& rm -rf /var/lib/apt/lists/*
# Create a working directory
RUN mkdir /app
WORKDIR /app
# Create a non-root user and switch to it
RUN adduser --disabled-password --gecos '' --shell /bin/bash user \
&& chown -R user:user /app
RUN echo "user ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-user
USER user
# All users can use /home/user as their home directory
ENV HOME=/home/user
RUN chmod 777 /home/user
# Install Miniconda
RUN curl -so ~/miniconda.sh https://repo.continuum.io/miniconda/Miniconda3-4.4.10-Linux-x86_64.sh \
&& chmod +x ~/miniconda.sh \
&& ~/miniconda.sh -b -p ~/miniconda \
&& rm ~/miniconda.sh
ENV PATH=/home/user/miniconda/bin:$PATH
# Create a Python 3.6 environment
RUN /home/user/miniconda/bin/conda install conda-build \
&& /home/user/miniconda/bin/conda create -y --name py36 python=3.6.4 \
&& /home/user/miniconda/bin/conda clean -ya
ENV CONDA_DEFAULT_ENV=py36
ENV CONDA_PREFIX=/home/user/miniconda/envs/$CONDA_DEFAULT_ENV
ENV PATH=$CONDA_PREFIX/bin:$PATH
# Ensure conda version is at least 4.4.11
# (because of this issue: https://github.com/conda/conda/issues/6811)
ENV CONDA_AUTO_UPDATE_CONDA=false
RUN conda install -y "conda>=4.4.11" && conda clean -ya
# Install FFmpeg
RUN conda install --no-update-deps -y -c conda-forge ffmpeg=3.2.4 \
&& conda clean -ya
# Install NumPy
RUN conda install --no-update-deps -y numpy=1.13.3 \
&& conda clean -ya
# Install build tools
RUN sudo apt-get update \
&& sudo apt-get install -y build-essential gfortran libncurses5-dev \
&& sudo rm -rf /var/lib/apt/lists/*
# Build and install CDF
RUN cd /tmp \
&& curl -O https://spdf.sci.gsfc.nasa.gov/pub/software/cdf/dist/cdf36_4/linux/cdf36_4-dist-all.tar.gz \
&& tar xzf cdf36_4-dist-all.tar.gz \
&& cd cdf36_4-dist \
&& make OS=linux ENV=gnu CURSES=yes FORTRAN=no UCOPTIONS=-O2 SHARED=yes all \
&& sudo make INSTALLDIR=/usr/local/cdf install
# Install other dependencies from pip
COPY requirements.txt .
RUN pip install -r requirements.txt
# Create empty SpacePy config (suppresses an annoying warning message)
RUN mkdir /home/user/.spacepy && echo "[spacepy]" > /home/user/.spacepy/spacepy.rc
# Copy scripts into the image
COPY --chown=user:user . /app
# Set the default command to python3
CMD ["python3"]
Untested, going by memory but I would debug the issue with an interactive version of your container.
Something like:
sudo docker run -t -i --rm --user="$(id -u):$(id -g)" main /bin/bash
You'll get a bash shell. Then you can debug it by
cd /media
ls -l
What I think you'll find is that the drive is probably not mounted. Or, the user doesn't have permission to access it.
With regards to mounts, either pass it through from the host or create a volume mount. I'm a little bit unsure about what you can do there because since I last used docker many changes around mounting and volume drivers were introduced. But the documentation on the docker website is pretty good. So experiment.
This is the cmd line reference for docker: https://docs.docker.com/engine/reference/run/
The key is to use the -t -i parameters to make it interactive.
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..