develooper Front page | perl.perl5.porters | Postings from July 2001

Re: [ID 20010723.007] no versioning in filename of libperl.a

Thread Previous | Thread Next
Andy Dougherty
July 24, 2001 08:06
Re: [ID 20010723.007] no versioning in filename of libperl.a
Message ID:
On Mon, 23 Jul 2001 wrote:

> This is a bug report for perl from,
> generated with the help of perlbug 1.28 running under perl v5.6.0.
> -----------------------------------------------------------------
> [Please enter your report here]
> On several systems that I use, /usr/local/bin/perl is not usually
> the latest installed perl interpreter, because if it were, older
> perl scripts would break.
> However, /usr/local/lib/libperl.a is generally the latest, because
> we have no option for it not to be -- this file's name contains no
> version information.

/usr/local/lib/libperl.a shouldn't generally exist, for just this reason.
The perl library is typically kept in a version-specific and
architecture-specific directory.  In the perl source, see
Porting/pumpkin.pod, especially the section

	=head2 Shared location

for some more thoughts on this matter.  Perl's libperl is not really a
library with a fixed API like libc is.

> The mismatch causes the build of INN to blow up.  It may cause
> other problems too, though I haven't seen any yet.  INN's configure
> script doesn't let me specify paths to a perl binary and a perl
> library; I'm not sure it should, because every application that
> uses both would have to do this, and if perl fixed the library
> naming, it wouldn't be necessary.

If you can suggest a _portable_ library naming scheme that does what you
suggest and does not break anything else, we'd be happy to hear it.

    Andy Dougherty
    Dept. of Physics
    Lafayette College, Easton PA 18042

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About