On Mon, 27 Mar 2006, Nick Glencross wrote:
> Andy,
>
> I totally agree, and this still works. We would then get a compile line like:
>
> gcc ... -L.../blib/lib -lparrot -L/usr/local/lib -lgmp -lreadline
>
> So that libparrot is found in blib/lib, and the other libraries in
> /usr/local/lib.
>
> What's evil with some builds of perl is that -L/usr/local/lib is added
> to to the link flags so that you get:
>
> gcc ... -L/usr/local/lib ... -L.../blib/lib -lparrot -L/usr/local/lib
> -lgmp -lreadline
>
> which now finds libparrot system-wide, and causes various breakages
> depending on how old it is.
Ah, I see what you mean, though since I'd actually want the
-L/usr/local/lib, I wouldn't call adding it "evil". I'd simply have said
the Makefile should put the appropriate directories for parrot before all
the other -L flags. Yes, that should get you past the first hurdle, at
least on Linux. I don't know if it works anywhere else. It doesn't work
on Solaris currently.
I think that's only scratching the surface of the problem, however. We
worried about this sort of thing *a lot* with shared libraries on perl5,
and found it's a twisty maze of flags that look alike but actually work
differently. Here's a relevant snippet from the perl5 INSTALL file.
(I've left in lots of stuff that's probably obvious, but that sets the
stage for the "potential problem with the shared perl library" section
below, which I think is particularly relevant if parrot is going to
install a shared libparrot into /usr/local/lib.
=head3 Building a shared Perl library
[ . . . ]
To build a shared libperl, the environment variable controlling shared
library search (LD_LIBRARY_PATH in most systems, DYLD_LIBRARY_PATH for
NeXTSTEP/OPENSTEP/Darwin, LIBRARY_PATH for BeOS, LD_LIBRARY_PATH/SHLIB_PATH
for HP-UX, LIBPATH for AIX, PATH for Cygwin) must be set up to include
the Perl build directory because that's where the shared libperl will
be created. Configure arranges makefile to have the correct shared
library search settings. You can find the name of the environment
variable Perl thinks works in your your system by
grep ldlibpthname config.sh
However, there are some special cases where manually setting the
shared library path might be required. For example, if you want to run
something like the following with the newly-built but not-yet-installed
./perl:
cd t; ./perl misc/failing_test.t
or
./perl -Ilib ~/my_mission_critical_test
then you need to set up the shared library path explicitly.
You can do this with
LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
for Bourne-style shells, or
setenv LD_LIBRARY_PATH `pwd`
for Csh-style shells. (This procedure may also be needed if for some
unexpected reason Configure fails to set up makefile correctly.) (And
again, it may be something other than LD_LIBRARY_PATH for you, see above.)
You can often recognize failures to build/use a shared libperl from error
messages complaining about a missing libperl.so (or libperl.sl in HP-UX),
for example:
18126:./miniperl: /sbin/loader: Fatal Error: cannot map libperl.so
There is also an potential problem with the shared perl library if you
want to have more than one "flavor" of the same version of perl (e.g.
with and without -DDEBUGGING). For example, suppose you build and
install a standard Perl 5.8.0 with a shared library. Then, suppose you
try to build Perl 5.8.0 with -DDEBUGGING enabled, but everything else
the same, including all the installation directories. How can you
ensure that your newly built perl will link with your newly built
libperl.so.8 rather with the installed libperl.so.8? The answer is
that you might not be able to. The installation directory is encoded
in the perl binary with the LD_RUN_PATH environment variable (or
equivalent ld command-line option). On Solaris, you can override that
with LD_LIBRARY_PATH; on Linux, you can only override at runtime via
LD_PRELOAD, specifying the exact filename you wish to be used; and on
Digital Unix, you can override LD_LIBRARY_PATH by setting the
_RLD_ROOT environment variable to point to the perl build directory.
In other words, it is generally not a good idea to try to build a perl
with a shared library if $archlib/CORE/$libperl already exists from a
previous build.
A good workaround is to specify a different directory for the
architecture-dependent library for your -DDEBUGGING version of perl.
You can do this by changing all the *archlib* variables in config.sh to
point to your new architecture-dependent library.
=cut
> > (I'm by no means an expert on this, but given quite a bit of thought
> to the problem. My solution is either to remove -L's which Perl
> supplies, or move them later in the link line)
I'm no expert either, and my experience getting this to work for perl5
is undoubtedly quite dated, but I would be quite surprised --
pleasantly surprised, but quite surprised nonetheless -- if it had
actually gotten much easier :-).
>
> Nick
>
--
Andy Dougherty [EMAIL PROTECTED]
