Related
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
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
I have recently installed Hombrew on Yosemite with Xcode installed and would like to better understand what brew doctor is warning me about. I understand that these warnings are nothing to worry about (until they are) and am not asking how or whether to respond to them; but I would like to do the best I can to understand the likely causes so that I can be prepared when issues come up (and also to head off issues that others in my office may encounter on similar systems).
Are any of the items below from obvious sources on a 10.10 machine with Xcode and non-brew Fortran installed? Do any of these items ring a bell?
Warning: Some directories in /usr/local/share/man aren't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew. If a brew tries to add locale information to one of these
directories, then the install will fail during the link step.
You should probably `chown` them:
/usr/local/share/man/de
/usr/local/share/man/de/man1
/usr/local/share/man/mann
Warning: Broken symlinks were found. Remove them with `brew prune`:
/usr/local/lib/libasan.dylib
/usr/local/lib/libatomic.dylib
/usr/local/lib/libcilkrts.dylib
/usr/local/lib/libgcc_s_ppc64.1.dylib
/usr/local/lib/libgcc_s_x86_64.1.dylib
/usr/local/lib/libgfortran.dylib
/usr/local/lib/libgmp.dylib
/usr/local/lib/libgmpxx.dylib
/usr/local/lib/libgomp.dylib
/usr/local/lib/libitm.dylib
/usr/local/lib/libmpc.dylib
/usr/local/lib/libmpfr.dylib
/usr/local/lib/libquadmath.dylib
/usr/local/lib/libssp.dylib
/usr/local/lib/libstdc++.dylib
/usr/local/lib/libubsan.dylib
/usr/local/lib/ppc64/libgfortran.2.0.0.dylib
/usr/local/lib/ppc64/libgfortran.2.dylib
/usr/local/lib/ppc64/libgfortran.dylib
/usr/local/lib/x86_64/libgfortran.2.0.0.dylib
/usr/local/lib/x86_64/libgfortran.2.dylib
/usr/local/lib/x86_64/libgfortran.dylib
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
/opt/ImageMagick/bin/Magick++-config
/opt/ImageMagick/bin/Magick-config
/opt/ImageMagick/bin/MagickCore-config
/opt/ImageMagick/bin/MagickWand-config
/opt/ImageMagick/bin/Wand-config
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/fakemysql.h
/usr/local/include/fakepq.h
/usr/local/include/fakesql.h
/usr/local/include/gmp.h
/usr/local/include/gmpxx.h
/usr/local/include/graphviz/arith.h
/usr/local/include/graphviz/cdt.h
/usr/local/include/graphviz/cgraph.h
/usr/local/include/graphviz/color.h
/usr/local/include/graphviz/geom.h
/usr/local/include/graphviz/graphviz_version.h
/usr/local/include/graphviz/gvc.h
/usr/local/include/graphviz/gvcext.h
/usr/local/include/graphviz/gvcjob.h
/usr/local/include/graphviz/gvcommon.h
/usr/local/include/graphviz/gvconfig.h
/usr/local/include/graphviz/gvplugin.h
/usr/local/include/graphviz/gvplugin_device.h
/usr/local/include/graphviz/gvplugin_layout.h
/usr/local/include/graphviz/gvplugin_loadimage.h
/usr/local/include/graphviz/gvplugin_render.h
/usr/local/include/graphviz/gvplugin_textlayout.h
/usr/local/include/graphviz/gvpr.h
/usr/local/include/graphviz/pack.h
/usr/local/include/graphviz/pathgeom.h
/usr/local/include/graphviz/pathplan.h
/usr/local/include/graphviz/textspan.h
/usr/local/include/graphviz/types.h
/usr/local/include/graphviz/usershape.h
/usr/local/include/graphviz/xdot.h
/usr/local/include/itcl.h
/usr/local/include/itcl2TclOO.h
/usr/local/include/itclDecls.h
/usr/local/include/itclInt.h
/usr/local/include/itclIntDecls.h
/usr/local/include/itclMigrate2TclCore.h
/usr/local/include/itclTclIntStubsFcn.h
/usr/local/include/mpc.h
/usr/local/include/mpf2mpfr.h
/usr/local/include/mpfr.h
/usr/local/include/mysqlStubs.h
/usr/local/include/odbcStubs.h
/usr/local/include/pqStubs.h
/usr/local/include/tcl.h
/usr/local/include/tclDecls.h
/usr/local/include/tclOO.h
/usr/local/include/tclOODecls.h
/usr/local/include/tclPlatDecls.h
/usr/local/include/tclThread.h
/usr/local/include/tclTomMath.h
/usr/local/include/tclTomMathDecls.h
/usr/local/include/tdbc.h
/usr/local/include/tdbcDecls.h
/usr/local/include/tdbcInt.h
/usr/local/include/tk.h
/usr/local/include/tkDecls.h
/usr/local/include/tkPlatDecls.h
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libasan.la
/usr/local/lib/libatomic.la
/usr/local/lib/libcilkrts.la
/usr/local/lib/libgfortran.la
/usr/local/lib/libgmp.la
/usr/local/lib/libgmpxx.la
/usr/local/lib/libgomp.la
/usr/local/lib/libitm.la
/usr/local/lib/libmpc.la
/usr/local/lib/libmpfr.la
/usr/local/lib/libquadmath.la
/usr/local/lib/libssp.la
/usr/local/lib/libssp_nonshared.la
/usr/local/lib/libstdc++.la
/usr/local/lib/libsupc++.la
/usr/local/lib/libubsan.la
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/libcdt.pc
/usr/local/lib/pkgconfig/libcgraph.pc
/usr/local/lib/pkgconfig/libgvc.pc
/usr/local/lib/pkgconfig/libgvpr.pc
/usr/local/lib/pkgconfig/libpathplan.pc
/usr/local/lib/pkgconfig/libxdot.pc
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libatomic.a
/usr/local/lib/libcilkrts.a
/usr/local/lib/libgfortran.a
/usr/local/lib/libgmp.a
/usr/local/lib/libgmpxx.a
/usr/local/lib/libgomp.a
/usr/local/lib/libitm.a
/usr/local/lib/libmpc.a
/usr/local/lib/libmpfr.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libssp.a
/usr/local/lib/libssp_nonshared.a
/usr/local/lib/libstdc++.a
/usr/local/lib/libsupc++.a
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
There is a variety of warnings here, probably all with a very similar cause: having installed software from source (by compiling with configure; make; make install, or sometimes unpacking a very specific (e.g. scientific) package, such as fortran). That would be mostly software with a unix background, and the software decided to install itself in /usr/local.
I don't know your background, so I'm going to expand somewhat (I'll probably miss a few things or may have a few things (somewhat) incorrect):
In unix & linux, a piece of software is often distributed across various subdirectories, and not inside a single package (which is more Mac style). It can consist of binary that goes into /usr/local/bin/, a library with routines used by the binary that is put in /usr/local/lib/, some header file for function declarations that lives in /usr/local/include/, a manual page that is put in /usr/local/man/ or additional (e.g. configuration) data that could go into /usr/local/share/. Practically any combination can exist.
That looks a bit scattered, but it works. It does mean that pieces of different software live in the same subdirectory, as you can see form the various lists of filenames.
Note that /usr/local/ is in so far unique, that it tends to be a preferred directory to install extra software: software that the system (OS) can do without. This is also why Homebrew likes to install software there. Other software managers avoid the unix default of /usr/local/ and install in /opt/local/ (Macports) or /sw/ (Fink). But the fact that Homebrew picks the default "extra" software installation part can mean it clashes with other installed software.
Your system software lives in plain /usr/, or /System/ and /Library/, and stays out of /usr/local/; if you remove /usr/local/ completely, your system will still work.
So, with that in mind, the warnings:
Warning: Some directories in /usr/local/share/man aren't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew. If a brew tries to add locale information to one of these
directories, then the install will fail during the link step. You
should probably chown them:
/usr/local/share/man/de
/usr/local/share/man/de/man1
/usr/local/share/man/mann
Other software installed its manual pages here, likely with the sudo command (you may simply have had a dialog asking for your password; sudo then happened under the hood). In that case, those specific directories are "owned" by "root", and not by the usual Homebrew user (your login). That would mean Homebrew can't, in a future event, not write in those directories, if it ever comes across software that likes its manual pages there, since it's not owned by the Homebrew user.
You can alleviate this by changing the permissions to yourself:
$ sudo chown -R <user>:<group> /usr/local/share/man/de
$ sudo chown -R <user>:<group> /usr/local/share/man/mann
(do an $ ls -l $HOME to find your <user> and <group> to fill in: it's the hopefully obvious columns.)
Warning: Broken symlinks were found. Remove them with `brew prune`:
A sym(bolic )link is just a pointer to a file that exist somewhere else. If it's broken, the original file doesn't exist anymore, or the symlink is pointing to the wrong place. You can see what it is pointing at by doing for example:
ls -l /usr/local/lib/libasan.dylib
The .dylib files are all dynamic libraries: library files that contain functions, and are meant to be used by other programs (but, specifically, not fully included inside that program; see later on static libraries). A broken library file is a potentially bad thing: new software that wants to use those files may think "ah, I can use this library" and then things go bad during compilation, when it turns out the file doesn't exist anymore. So, it may be wise to prune (remove) the symbolic links. (A symbolic link can normally be safely removed, even if it points correctly: it's only a pointer, the original file is left untouched.)
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
configure is part of the chain to build software from source on the command line. It looks around on your system for existing libraries, and also ask for the configuration of programs using these -config scripts. Homebrew had a look around, and found such scripts outside the usual directories. Thus, configure could find multiple versions of the same config script, get confused which one to use and use the wrong one.
In this case, it's all ImageMagick stuff. Depending how you use it, you could opt to remove the entire /opt/ImageMagick/ directory (and perhaps you're then left with an empty /opt/ directory, in which case you can also remove /opt/; it's not part of the usual system).
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
These are all related, and related to the dynamic libraries mentioned before. The .a files are static libraries: they (also) contain often-used functions, but those files get included inside the binary when compiling software from source (thus, the binary becomes bigger than with dynamic libraries). The .h files are header files, which tell programs what the library files contain; the .la have some extra information on the .a library files.
The warning tells you that Homebrew may get confused when installing new software: perhaps it will try to use these libraries, but they happen to be the (oh so slightly) wrong version and things don't work. You don't know until you bump into it, unfortunately.
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
pkgconfig files are similar to those config scripts mentioned earlier: they contain configuration information if you need some earlier installed software to build new software. Again, as before: versions may mismatch slightly and then things could not work as intended (it doesn't install, or crashes, or makes your computer pass the Turing test).
As for how you may have gotten all those files in /usr/local.? Probably you installed a package that puts everything in /usr/local/ as well. As mentioned, it is a default place to put things. Since it features libgfortran and libgomp, I'm inclined to think about some scientific package.
All in all, most warnings are about potential incompatibilities: Homebrew, like most package/software managers, tries to hold some grip (not too tight though) on what it installs and what is around, because backwards incompatibilities and such can mean that newly installed software from source ("brewed" software) doesn't properly install or run. As an example, Macports is more strict (at least it was years ago when I used it), and will download matching, known compatible, versions of required extra software (thus, you could end up with four different versions of a C compiler).
Homebrew tries to be lenient with respect to installed libraries and such, but it does warn you that bad things can happen, either during compilation or later on.
Is there a way to get a list of filenames/paths that make install copies to the filesystem? Some packages come with a MANIFEST file, but not the ones that I am working with.
I was just investigating this myself while compiling a custom version of QEMU. I used the following method to work out what was installed and where (as well as using it as a basis for a .deb file):
mkdir /tmp/installer
./configure --target-list=i386-softmmu
make
sudo make install DESTDIR=/tmp/installer
cd /tmp/installer
tree .
Tree is a utility that recursively displays the contents of a directory in a visually appealing manner - sudo apt-get install tree for Debian / Ubuntu users
Hope that helps someone... it took me a bit of poking around to nut it out, but I found it quite a useful way of visualising what was going on.
The most fool-proof way is to use chroot: have "make install" run inside a chroot jail; compute a list of the files that you had before the installation, and compare that to the list of files after the installation.
Many installations will support either a --prefix configuration option, and/or a DESTDIR environment variable. You can use those for a lighter-wait version of chroot (trusting that the installation will fail if it tries to write to a location outside these if you run installation as a fairly unprivileged user).
Another approach is to replace the install program. Many packages support an INSTALL environment variable that, well, is the install program to use; there are tracing versions of install around.
make uninstall might show the files as it removes them if the author of the compiling instructions provides the information to allow an uninstall (it has been awhile since I have done one so I can't say for sure).
Also make -n install will do a "dry run" of the install process and it may be reasonable to extract the information from its results.
It differs for every project that you run 'make install' on. The files which are installed are controlled by the install target in the Makefile being used. Your best bet is to open the Makefile and search for 'install:' - from there you can see what files will be copied out to your system.
Take a snapshot of the contents of the install location before installing
Install
Compare the current contents with the old contents.
Example:
./configure --prefix /usr/local
make -j`nproc`
find /usr/local | sort -u > /tmp/snapshot1
make install
find /usr/local | sort -u > /tmp/snapshot2
comm -3 /tmp/snapshot{1,2} # this prints the files added by `make install` to stdout
If the install program you're using doesn't support DESTDIR or --prefix (or an equivalent), I have found that it may be possible to identify new files as follows:
Start with as clean a system as possible (a fresh VM image is preferable)
Compile the software, wait a few minutes.
Install the software package.
Find files modified within the past 5 minutes: sudo find / -mmin -5 -type f (the find command has a ton of parameters for querying based on file modification / creation times, but this worked pretty well for me; you just need to narrow the time span so that you pick up the files created by the installer but nothing else).
Does anyone know how to uninstall MacRuby? I was using RubyCocoa then decided to try out MacRuby, after installing MacRuby, RubyCocoa has stopped working. So I would like to remove MacRuby, but I cannot find any documentation on how to uninstall it.
The given answers won't remove everything. You'll still have XCode templates, examples and a few other dangling sym links: to rb_nibtool and the macruby man page.
To clean this up you need the .pkg file used to install MacRuby in the first place. This gives you a list of all files installed which you can delete. I did this:
$ xar -xf macruby_nightly.pkg
$ lsbom macrubynightly.pkg/Bom # not a typo, the above archive contains this folder
It would be nice if there were a better way to do this...
There is an easier way to list files in an installed package:
$ pkgutil --pkgs # list IDs of all installed packages
$ pkgutil --pkgs |grep -i ruby # get all related to ruby
$ pkgutil --files com.apple.macruby.macruby.MacRuby-0.pkg # show all files for MacRuby-0.8
If you delete the files, be sure to remove the receipt, as well (/Library/Receipts):
$ sudo pkgutil --forget com.apple.macruby.macruby.MacRuby-0.pkg
If you don't remove the receipt, you could have trouble reinstalling later (usually only for previous versions of the same package).
You can also delete all the files using pkgutil:
$ sudo pkgutil --unlink com.apple.macruby.macruby.MacRuby-0.pkg
The docs are not great (for me, at least) and I was a little scared to try it - it looked like it wanted to be overly-aggressive in deleting/unlinking things it didn't "own" (e.g., it tried to unlink /usr).
In the end, I made sure that Time Machine was working and ran the command. It deletes all the files and leaves behind all the empty directories. That's dumb, but safe enough. I'm sure someone has written a script to wrap all this up into a single safe operation, but I just cleaned up by hand.
Also, '--unlink' does not imply '--forget', so you also still need to run that after.
Dj2 is right, to uninstall MacRuby:
$ rm -rf /Library/Frameworks/MacRuby.framework
$ rm /usr/local/bin/mac*
$ rm /usr/local/bin/hotcocoa
However, MacRuby and RubyCocoa can live side by side in perfect harmony ;)
I believe everything for MacRuby is installed into /Library/Frameworks/MacRuby.framework. While I haven't tried it myself, removing that directory should remove MacRuby from the system.
MacRuby shouldn't interact with RubyCocoa in such a way as to cause it to stop working. It maybe the case that something else on your system changed at about the same time as the MacRuby install.
This is from Matt Aimonetti's "MacRuby: The Definitive Guide" (O'Reilly):
"MacRuby does not come with an uninstaller. If you want to remove MacRuby from your computer, delete the MacRuby binary files, which use the mac prefix and are located in /usr/local/bin/. Then remove MacRuby itself: /Library/Frameworks/MacRuby.framework."
http://ofps.oreilly.com/titles/9781449380373/index.html
There is a gist to do the whole uninstall: https://gist.github.com/Watson1978/1927952 and it works very nicely!