Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
I am neophyte on Mac especially on terminal. Though I've read lots of materials, I am still very confused and do not know what I should do.
I need to use aspell on MAC. I followed a tutorial (http://wiki.lyx.org/Mac/MacSpelling) to install it and I've installed Xcode and gcc. In one step, it required me to "type ./configure, followed by ". I did it, but terminal showed:
-bash: ./configure: No such file or directory
This webpage (http://ubuntuforums.org/showthread.php?t=1849525) showed the configure in under "/usr/local/src/configure" but when I cd to this directory I found I do not have the /src/ folder.
/usr/local$ ls
CODEOFCONDUCT.md README.md include/ opt/
CONTRIBUTING.md SUPPORTERS.md info/ share/
Cellar/ bin/ lib/
LICENSE.txt etc/ libexec/
Library/ git/ man/
What show I do? How can I use the ./configure?
Thank you so much.
You likely don't have the command line development tools installed.
Try
xcode-select --install
It also looks like you have homebrew installed. I believe that there is a formula for aspell, so you can try
brew install aspell
The aspell-0.60.6.1 tarball does have a configure script inside its own source tree (so it is located at aspell-0.60.6.1/configure). So you should start with something like (to do outside of /usr/local/, for example in your $HOME/freesoftsource/ directory if you have one, or maybe even simply in your $HOME if you dare).
wget ftp://ftp.gnu.org/gnu/aspell/aspell-0.60.6.1.tar.gz
tar xzvf aspell-0.60.6.1.tar.gz
cd aspell-0.60.6.1
./configure
You may want to add some options to the ./configure above.
You should read aspell installing instructions
N.B. As with most GNU software using configure, the location of the source tree (extracted from the source tar archive as above) does not matter much.
My OS (Ubuntu 12.04) comes with a pre-packaged Qt4 libraries and other relevant stuffs. But I wanted to use the latest vanilla Qt 5.2.1, I have installed it and it's working fine, suppose I have compiled this framework which depends on Qt.
What I had to do is to add the Qt 5.2.1 libraries to the $LD_LIBRARY_PATH. My Qt 5.2.1 home path is /opt/Qt5.2.1/5.2.1/gcc_64, and thus my $LD_LIBRARY_PATH contains /opt/Qt5.2.1/5.2.1/gcc_64/lib (and /opt/Qt5.2.1/Tools/QtCreator/lib for qtcreator related stuffs)
However, recently I am trying to compile the latest gnu octave. It's configure script looks for the Qt cflags (i.e. -l/-I/-L flags) by invoking the pkg-config.
What I came to know that pkg-config looks for the appropriate .pc files to get the exact information related to all compilation/linking flags. My system (Ubuntu) maintains a list of all required .pc file locations in /var/lib/dpkg/info/pkg-config.list. But I do not have any $PKG_CONFIG_PATH environment variable on Ubuntu 12.04 (I am not sure why).
My newly installed Qt5 has a set of .pc files in /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/.
So, how do I make pkg-config to recognize the development libraries in the newly installed Qt 5.2.1 ?
I know that this could be solved by just installing the Qt4 -dev packages from the Ubuntu repo, but I do not want to do that. I need the vanilla Qt 5.2.1 for other purposes.
NOTE:
I have added the the path /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/ to the pkg-config.list but the pkg-config does not update the compilation flags accordingly.
Adding the path (/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/) to $PKG_CONFIG_PATH does not work as well.
Here is the octave configure script output.
This problem is because Octave is searching for QtCore.pc, QtGUI.pc, and QtNetwork.pc but Qt5 seems to have renamed them as Qt5Core.pc, Qt5GUI.pc, and Qt5Network.pc. One solution is to create symlinks for them:
cd /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
ln -s ./Qt5Core.pc ./QtCore.pc
ln -s ./Qt5GUI.pc ./QtGUI.pc
ln -s ./Qt5Network.pc ./QtNetwork.pc
cd octave_build_dir
export $PKG_CONFIG_PATH="/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/"
./configure # with fingers crossed
I am unsure of the why the reason of name change. I wonder if there should be some sort of mechanism in place where the unversion versions would be in the $PKG_CONFIG_PATH, and changing your preferences would change the link to correct version.
Finally, your config.log and config.status would have been more useful than just the output of configure. The mentioned files will have the actual commands and output of your configure.
The carandraug's answer is correct, but I didn't need to symlink .pc files(Qt 5.9.5). To prevent removing other pkg-config addresses, export PKG_CONFIG_PATH like below:
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
And to execute it at startup and systemwide(no need to export in every terminal session), put these lines at the bottom line in ".bashrc":
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
export PKG_CONFIG_PATH
I asked IT to install Mono on CentOS using the following commands:
$yum install bison gettext glib2 freetype fontconfig libpng libpng-devel libX11 libX11-devel glib2-devel libgdi* libexif glibc-devel urw-fonts java unzip gcc gcc-c++ automake autoconf libtool make bzip2 wget
$cd /usr/local/src
$wget http://download.mono-project.com/sources/mono/mono-3.2.5.tar.bz2
$tar jxf mono-3.2.5.tar.bz2
$cd mono-3.2.5
$./configure --prefix=/opt/mono
$make && make install
However, when I run mono myapp.exe I get
-bash: mono: command not found
I know nothing about Linux - I feel like I'm in Japan. Assuming Linux has a path variable or something like it, maybe mono isn't in the path?
I can't even find an executable called mono in /usr/local/src, just a mono folder. Mind you I can't work out how to even search for a file so I might not be looking properly.
How can I tell whether its installed correctly? Maybe its just not available to the non-admin account I use?
I'm lost. Help!
If mono is properly installed, you should not get a message like -bash: mono: command not found. If something is installed then it most typically is in the $PATH.
On my system the executable is located on /usr/bin/mono (as most things are) but things may be different on a RPM-based system.
Your ./configure, however, got the prefix /opt/mono, so probably your executable also is located under that special path. (And thus mono isn't properly installed.) Why did you install it there? Anyway. If this is the fact, then you can execute it using sth like
/opt/mono/bin/mono foo.exe
to find the executable below your prefix path you could use
find /opt/mono -name mono
to see all directory entries which are named exactly mono. One of those should be your executable.
If your programm is properly installed you will usually find it's executable using "which"
which programm
like:
which firefox
/usr/bin/firefox
There are many guides and tutorials out there that recommend installing in /opt/mono in order to not conflict with the mono supplied by official distribution packages (which would be installed in /usr).
However what most of those guides miss is that /opt/mono is a non-standard prefix that will not be taken in account by the system when trying to find the executables (the system looks at the $PATH environment variable).
There are 2 possible solutions to this:
Instead of using the prefix /opt/mono use /usr/local (which is actually what ./configure or ./autogen.sh uses by default if you don't supply any prefix!). This prefix is normally included in the $PATH environment variable of most distributions.
Use your custom mono installation from a Parallel Environment. This is a bit more complicated to set up, but it's specially recommended for people who want to install two versions of mono in parallel (i.e. a very modern version, and a more stable version supplied by the official distribution packages), and have good control of when they can use one or another.
The reason that many internet tutorials recommend /opt/mono instead of /usr/local is actually because most of them are based on the wiki page (referenced above) that explains how to set up a Mono Parallel Environment, but they of course don't include the other steps to properly set up such an environment (they just borrowed the bit about how to call configure).
Program is part of the Xenomai test suite, cross-compiled from Linux PC into Linux+Xenomai ARM toolchain.
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
Is the .1 at the end part of the filename? What does that mean anyway?
Your library is a dynamic library.
You need to tell the operating system where it can locate it at runtime.
To do so,
we will need to do those easy steps:
Find where the library is placed if you don't know it.
sudo find / -name the_name_of_the_file.so
Check for the existence of the dynamic library path environment variable(LD_LIBRARY_PATH)
echo $LD_LIBRARY_PATH
If there is nothing to be displayed, add a default path value (or not if you wish to)
LD_LIBRARY_PATH=/usr/local/lib
We add the desired path, export it and try the application.
Note that the path should be the directory where the path.so.something is. So if path.so.something is in /my_library/path.so.something, it should be:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
export LD_LIBRARY_PATH
./my_app
Reference to source
Here are a few solutions you can try:
ldconfig
As AbiusX pointed out: If you have just now installed the library, you may simply need to run ldconfig.
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent
shared libraries found in the directories specified on the command
line, in the file /etc/ld.so.conf, and in the trusted directories
(/lib and /usr/lib).
Usually your package manager will take care of this when you install a new library, but not always, and it won't hurt to run ldconfig even if that is not your issue.
Dev package or wrong version
If that doesn't work, I would also check out Paul's suggestion and look for a "-dev" version of the library. Many libraries are split into dev and non-dev packages. You can use this command to look for it:
apt-cache search <libraryname>
This can also help if you simply have the wrong version of the library installed. Some libraries are published in different versions simultaneously, for example, Python.
Library location
If you are sure that the right package is installed, and ldconfig didn't find it, it may just be in a nonstandard directory. By default, ldconfig looks in /lib, /usr/lib, and directories listed in /etc/ld.so.conf and $LD_LIBRARY_PATH. If your library is somewhere else, you can either add the directory on its own line in /etc/ld.so.conf, append the library's path to $LD_LIBRARY_PATH, or move the library into /usr/lib. Then run ldconfig.
To find out where the library is, try this:
sudo find / -iname *libraryname*.so*
(Replace libraryname with the name of your library)
If you go the $LD_LIBRARY_PATH route, you'll want to put that into your ~/.bashrc file so it will run every time you log in:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
Update
While what I write below is true as a general answer about shared libraries, I think the most frequent cause of these sorts of message is because you've installed a package, but not installed the -dev version of that package.
Well, it's not lying - there is no libpthread_rt.so.1 in that listing. You probably need to re-configure and re-build it so that it depends on the library you have, or install whatever provides libpthread_rt.so.1.
Generally, the numbers after the .so are version numbers, and you'll often find that they are symlinks to each other, so if you have version 1.1 of libfoo.so, you'll have a real file libfoo.so.1.0, and symlinks foo.so and foo.so.1 pointing to the libfoo.so.1.0. And if you install version 1.1 without removing the other one, you'll have a libfoo.so.1.1, and libfoo.so.1 and libfoo.so will now point to the new one, but any code that requires that exact version can use the libfoo.so.1.0 file. Code that just relies on the version 1 API, but doesn't care if it's 1.0 or 1.1 will specify libfoo.so.1. As orip pointed out in the comments, this is explained well at here.
In your case, you might get away with symlinking libpthread_rt.so.1 to libpthread_rt.so. No guarantees that it won't break your code and eat your TV dinners, though.
You need to ensure that you specify the library path during
linking when you compile your .c file:
gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl,-R/usr/local/lib
The -Wl,-R part tells the resulting binary to also look for the library
in /usr/local/lib at runtime before trying to use the one in /usr/lib/.
Try adding LD_LIBRARY_PATH, which indicates search paths, to your ~/.bashrc file
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library
It works!
The linux.org reference page explains the mechanics, but doesn't explain any of the motivation behind it :-(
For that, see Sun Linker and Libraries Guide
In addition, note that "external versioning" is largely obsolete on Linux, because symbol versioning (a GNU extension) allows you to have multiple incompatible versions of the same function to be present in a single library. This extension allowed glibc to have the same external version: libc.so.6 for the last 10 years.
cd /home/<user_name>/
sudo vi .bash_profile
add these lines at the end
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH
Another possible solution depending on your situation.
If you know that libpthread_rt.so.1 is the same as libpthread_rt.so then you can create a symlink by:
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
Then ls -l /lib should now show the symlink and what it points to.
I had a similar error and it didn't fix with giving LD_LIBRARY_PATH in ~/.bashrc .
What solved my issue is by adding .conf file and loading it.
Go to terminal an be in su.
gedit /etc/ld.so.conf.d/myapp.conf
Add your library path in this file and save.(eg: /usr/local/lib).
You must run the following command to activate path:
ldconfig
Verify Your New Library Path:
ldconfig -v | less
If this shows your library files, then you are good to go.
running:
sudo ldconfig
was enough to fix my issue.
I had this error when running my application with Eclipse CDT on Linux x86.
To fix this:
In Eclipse:
Run as -> Run configurations -> Environment
Set the path
LD_LIBRARY_PATH=/my_lib_directory_path
Wanted to add, if your libraries are in a non standard path, run ldconfig followed by the path.
For instance I had to run:
sudo ldconfig /opt/intel/oneapi/mkl/2021.2.0/lib/intel64
to make R compile against Intel MKL
All I had to do was run:
sudo apt-get install libfontconfig1
I was in the folder located at /usr/lib/x86_64-linux-gnu and it worked perfectly.
Try to install lib32z1:
sudo apt-get install lib32z1
If you are running your application on Microsoft Windows, the path to dynamic libraries (.dll) need to be defined in the PATH environment variable.
If you are running your application on UNIX, the path to your dynamic libraries (.so) need to be defined in the LD_LIBRARY_PATH environment variable.
The error occurs as the system cannot refer to the library file mentioned. Take the following steps:
Running locate libpthread_rt.so.1 will list the path of all the files with that name. Let's suppose a path is /home/user/loc.
Copy the path and run cd home/USERNAME. Replace USERNAME with the name of the current active user with which you want to run the file.
Run vi .bash_profile and at the end of the LD_LIBRARY_PATH parameter, just before ., add the line /lib://home/usr/loc:.. Save the file.
Close terminal and restart the application. It should run.
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared
object file: No such file or directory
Try this. Fix permissions on files:
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
I use Ubuntu 18.04
Installing the corresponding -dev package worked for me,
sudo apt install libgconf2-dev
Before installing the above package, I was getting the below error:
turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared object
file: No such file or directory
Try this. Fix permissions on files:
sudo su
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
chown -R root:root *
A similar problem can be found here.
I've tried the mentioned solution and it actually works.
The solutions in the previous questions may work. But the following is an easy way to fix it.
It works by reinstalling the package libwbclient
in fedora:
dnf reinstall libwbclient
You can read about libraries here:
https://domiyanyue.medium.com/c-development-tutorial-4-static-and-dynamic-libraries-7b537656163e