#1876: Complete shared library support
---------------------------------+------------------------------------------
Reporter: simonmar | Owner: duncan
Type: task | Status: new
Priority: high | Milestone: 6.12.1
Component: Compiler | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Difficult (1 week)
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by Pete):
* cc: 1...@234.cx (added)
Comment:
"Although we could use LD_LIBRARY_PATH to include the appropriate
directory, that feels like a dirty hack: the standard Linux practice seems
to be to put any shared libraries the linker needs to find where it will
find them by default."
Most packages I've seen install shared libraries in $PREFIX/lib. If you
accept the default $PREFIX, this means they will go in /usr/local/lib, and
the linker is normally set so it will find them there. If a package (deb,
rpm or whatever) is being built, then $PREFIX will usually be set to /usr.
In this case, the libraries will go in /usr/lib and again the linker will
find them.
If you decide to install the package in a private directory, the linker
won't find the libraries. In this case you can set the executable's rpath
to the directory where the libraries are to be found. The downside is
that this makes the executables non-portable. If Fred installs the
libraries in ~fred/lib and Jim installs them in ~jim/lib, they won't be
able to run each other's executables. The rpath will be set correctly for
the person who compiled the executable, but no one else. At this point
you have to set LD_LIBRARY_PATH and work round it that way.
The Debian package of ALSA takes a different approach. It installs its
libraries in /usr/lib/alsa-lib/ and installs
/etc/ld.so.conf.d/libasound2.conf which points to them. (This file
contains a single line, '/usr/lib/alsa-lib'.) This approach makes sense,
I imagine, if you are installing a lot of libraries and don't want to
clutter up /usr/lib.
I was just doing some experiments to make sure I'd got this right. I
created foo.c:
#include <stdio.h>
void blah() {
printf("Hello World!\n");
}
and bar.c:
extern void blah();
main() {
blah();
}
First of all I build foo.c into a shared library:
$ gcc -fPIC -shared foo.c -o libfoo.so
I can then link bar.c in two ways. Here is the first option:
$ gcc bar.c -o bar -L. -lfoo
$ ./bar
./bar: error while loading shared libraries: libfoo.so: cannot open shared
object file: No such file or directory
$ LD_LIBRARY_PATH=. ./bar
Hello World!
Second option:
$ gcc bar.c -o bar -Wl,--rpath=/home/pc -L. -lfoo
$ ./bar
Hello World!
I hope this is helpful. I'm not a functional programming expert, so I
can't implement this myself. On the other hand, I'm happy to help with
any of these operating system issues. My email is 1...@234.cx if you want
anything from me.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1876#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
