On Tue, Jul 29, 2008 at 10:44 AM, Marc Lehmann <[EMAIL PROTECTED]> wrote: > debian makes it impossible to install perls in other prefixes by forcing > libperl.so (a private library that should not be in the default search > path) into /usr/lib, where it clashes with every other libperl.
Impossible? Have you tried? Many people are running non-Debian perl installs in /opt, /usr/local or whatever. > Unfortunately, debian completely breaks this mechanism by moving it into > /usr/lib, where it clashes with all other libperls on the same system, as > /usr/lib is alwas in the default linker search path. i.e. > > -L/opt/perl/lib/CORE -lperl > > will link against the correct perl library (here in /opt/perl/lib) on > every system except on debian, as debian puts the libperl into the default > library search path, when libperl was never intended to be put there. I think that you have some other problem. -L<path> -lperl will search at compile time for libperl.so or libperl.a in <path> before it searches /usr/lib. When linking to a shared library in a directory outside of /usr/lib either LD_RUN_PATH must also be set correctly, or -rpath passed to the linker such that at runtime the library will be found in the correct directory. > (this is especially bad as debian uses some extremely bad choices for > configuration, such as enabling the windows process emulation on unix, > which serves no purpose except slow down perl considerably for no gain > whatsoever on unix, so compiling one's own is practically required) If by "windows process emulation?" you are referring to threads, I suggest that you go read the POSIX standard. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
