testing 'make install'

Reini Urban rurban at x-ray.at
Wed Jan 21 15:12:25 UTC 2009


2009/1/21 Andy Dougherty <doughera at lafayette.edu>:
> On Tue, 20 Jan 2009, chromatic wrote:
>
>> On Tuesday 20 January 2009 11:08:40 Andy Dougherty wrote:
>>
>> > I don't see anything in here about supporting different versions.  Any
>> > idea how that's going to work?  For stand-alone installations, of course,
>> > different versions can be installed completely separately, something like
>> > --prefix=/opt/parrot-0.8.2 (though that really needs my previous rpath
>> > patch to be useful) but for the various Linux distributions that may
>> > someday want to have both (say) parrot-1.0 and parrot-1.5 simultaneously
>> > installed under /usr, what's the plan?
>>
>> It'd be nice to take advantage of shared library versioning, at least on
>> platforms where the compiler and linker and dynamic loader all support it --
>> but I have no idea how to do that in a cross-platform way.  Do you think it's
>> possible?
>
> Maybe, but it'd need experts from each new platform to adapt.  I never
> really learned that stuff.  I do note that I can find very few examples of
> using shared library versioning in any deep way.  For example, on my
> Debian system, I have both python2.4 and python2.5 packages installed, and
> what I get in /usr/lib is:
>
>    /usr/lib/libpython2.4.so.1.0
>    /usr/lib/libpython2.5.so.1.0

This will be easy to fix, just link to the long name, not to the alias.

The real problem is that the packager needs to use a versioned prefix for
the libdir and the bins, like:
  /usr/lib/parrot-1.0.1
  /usr/bin/parrot1.0.1

perl5 e.g. has support for this in the installer pl, we not yet.
The postgresq7.x packagers had to patch the sources all around
to be able to support 7.x and 8.x packages together.
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/


More information about the parrot-dev mailing list