no versioning in filename of libperl.a

p5pRT commented 23 years ago

Migrated from rt.perl.org#7324 (status was 'resolved')

Searchable as RT7324$

p5pRT commented 23 years ago

From br@panix.com

Created by br@panix.com

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.

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.

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.6.0: Configured by fn at Thu May 25 16:23:55 EDT 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=netbsd, osvers=1.4.2, archname=i386-netbsd uname='netbsd juggler.panix.com 1.4.2 netbsd 1.4.2 (panix-std) #0: tue apr 25 21:40:45 edt 2000 root@juggler.panix.com:develnetbsd1.4.2srcsysarchi386compilepanix-std i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O', gccversion=egcs-2.91.60 19981201 (egcs-1.1.1 release) cppflags='-fno-strict-aliasing -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=y, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-lm -lc -lposix -lcrypt libc=/usr/lib/libc.so.12.40, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags='-Wl,-R/lib ' cccdlflags='-DPIC -fPIC ', lddlflags='-Bshareable -L/usr/local/lib' Locally applied patches: @INC for perl v5.6.0: /pkg/perl-5.6.0/lib/perl-5.6.0/i386-netbsd /pkg/perl-5.6.0/lib/perl-5.6.0 /pkg/perl-5.6.0/lib/site_perl/5.6.0/i386-netbsd /pkg/perl-5.6.0/lib/site_perl/5.6.0 /pkg/perl-5.6.0/lib/site_perl . Environment for perl v5.6.0: HOME=/var/home/br LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/sbin:/usr/sbin:/net/staff/bin/script/:/usr/hlocal/source/sbin:/net/staff/bin/i386:/var/home/br/bin PERL_BADLANG (unset) SHELL=/usr/local/bin/zsh ```

p5pRT commented 23 years ago

From @doughera88

On Mon\, 23 Jul 2001 br@panix.com wrote:

This is a bug report for perl from br@panix.com\, 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 libperl.so 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.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Tue\, 24 Jul 2001\, Andy Dougherty wrote:

On Mon\, 23 Jul 2001 br@panix.com wrote:
     /usr/local/lib/libperl\.a is generally the latest
/usr/local/lib/libperl.a shouldn't generally exist

I would like to know how that can happen at all infact. Is it possible that this is something to do with some binary distrubution ?

I have a badly messed around with R00t Hat 7 and I have :

/home/gellyfish/perl/libperl.a /home/gellyfish/perl-5.6.1/libperl.a /home/gellyfish/Apachetoolbox-1.5.27/apache_1.3.20/src/modules/perl/libperl.a /usr/lib/perl5/5.6.0/i386-linux/CORE/libperl.a /usr/lib/perl5/5.6.1/i686-linux/CORE/libperl.a

I think you would have to go out of your way to get libperl.a into /usr/local/lib - enlighten me :)

/J\

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Tue\, Jul 24\, 2001 at 09:56:11PM +0100\, Jonathan Stowe wrote:

I think you would have to go out of your way to get libperl.a into /usr/local/lib - enlighten me :)

After consulting with my colleagues\, it appears that that's exactly what happened. :-(

Perl / perl5