Front page | perl.perl5.porters |
Postings from December 2015
On Tue, Dec 01, 2015 at 05:22:32AM +0100, Hanno Böck wrote:
> Hi,
>
> The Makefile.SH in perl contains some code that will in certain
> situations create a wrapper script called preload used during
> compilation.
>
> I think this is
> a) not needed
> b) doesn't really work how it's intended
> c) can cause problems.
>
>
> The point of the wrapper seems to be to make sure that during the
> compilation perl uses the newly compiled libperl and not a libperl that
> might be already installed on the system.
Correct.
> However the Makefile is already setting LD_LIBRARY_PATH, so that should
> not happen.
Unfortunately, LD_LIBRARY_PATH is not enough (on Linux, which is the
only OS for which the preload trick is used.) The perl binary is linked
with -rpath pointing to the install location. If there is already an
installed libperl.so in that install location, LD_LIBRARY_PATH won't
override it. You need to use LD_PRELOAD to override it.
If you have have previously-installed-but-incompatible libperl.so in
$archlib, the preload trick allows you to build, test, and install a
new perl anyway. If you remove the preload trick, such a build will
possibly crash when it tries to run the new ./perl. (In my tests,
the first such place was during the pod/buildtoc step.)
So the short story is that the preload script does address a need,
and LD_LIBRARY_PATH is not sufficient.
> Finally why I actually found this and why I think it causes problems: I
> tried to compile Perl with Address Sanitizer. This can cause the
> compilation to fail if this preload script is created. The reason is
> that if you LD_PRELOAD a library that was build with address sanitizer
> and then call any executable not built with address sanitizer it will
> crash. This caused gcc to crash. This does not happen with the
> LD_LIBRARY_PATH, because then only the libraries needed will be
> preloaded.
That is indeed unfortunate.
So we are left with the possibility of failure either with or without
preload. Fortunately, there is a workaround for both cases -- don't
build a new libperl.so if there is an already-existing one already
installed in $archlib. Use a different prefix.
I recommend leaving the preload trick in place. Without it, you run
the risk of not testing the freshly-built libperl.so.
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next