Обсуждение: pl/perl won't build under 7.1.3
Hi: Why won't pl/perl build under the install for postgresql 7.1.3? My perl installation only has libperl in the archive format (libperl.a) and the perl makefile calls for libperl.so...building perl form scratch is not an option. Is there a quick hack to allow pl/perl to build using libperl.a? -wiseguy -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
"-wiseguy" <no-one@all.net> writes: > Hi: > > Why won't pl/perl build under the install for postgresql 7.1.3? My perl > installation only has libperl in the archive format (libperl.a) and the perl > makefile calls for libperl.so...building perl form scratch is not an option. > Is there a quick hack to allow pl/perl to build using libperl.a? You need a dynamic library for dynamic extensions, you can't use a static library. -- Trond Eivind Glomsrød Red Hat, Inc.
"Jim Buttafuoco" <jim@spectrumtelecorp.com> writes: > Hi, > > I "fixed" the Makefile.PL script under src/pl/plperl and > removed the if ($Config{'useshrplib'} ne 'true') { ... } code. > > This will link in the static libperl.a file. The only down side > of this is your libplperl.so file is going to be larger. That's not the only downside, on most architectures it won't work. Code used like this should be compiled with -fpic, and static libraries rarely are. -- Trond Eivind Glomsrød Red Hat, Inc.
Hi, I "fixed" the Makefile.PL script under src/pl/plperl and removed the if ($Config{'useshrplib'} ne 'true') { ... } code. This will link in the static libperl.a file. The only down side of this is your libplperl.so file is going to be larger. Let me know if this works for you also. Jim PS. Running on RedHat Linux version 4.x to 7.2 with the above hack. > "-wiseguy" <no-one@all.net> writes: > > > Hi: > > > > Why won't pl/perl build under the install for postgresql 7.1.3? My perl > > installation only has libperl in the archive format (libperl.a) and the perl > > makefile calls for libperl.so...building perl form scratch is not an option. > > Is there a quick hack to allow pl/perl to build using libperl.a? > > You need a dynamic library for dynamic extensions, you can't use a > static library. > > -- > Trond Eivind Glomsrød > Red Hat, Inc. > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > >
On Sun, 2001-11-25 at 15:07, -wiseguy wrote: > Hi: > > Why won't pl/perl build under the install for postgresql 7.1.3? My perl > installation only has libperl in the archive format (libperl.a) and the perl > makefile calls for libperl.so...building perl form scratch is not an option. > Is there a quick hack to allow pl/perl to build using libperl.a? On some systems, you can exlpode libperl.a and rebuild is as a .so -- this works on Linux x86. I have taken the approach of building a separate libperl.so. It is change of just a few lines to the perl rpm spec on redhat. Then I install the .so file and use --forcperl with Lamar's RPM spec. You didn't say what platform you are using, so I don't know if any of the specific changes are useful to you. If they are , let me know and I can send you a diff. -- Karl DeBisschop Director, Software Engineering & Development Learning Network / Information Please www.learningnetwork.com / www.infoplease.com
Ok, I believe you. I am going to try on Solaris 8 and Tru64 now. I believe this is a real pain because I don't know of anyone that "ships" perl with a shared lib. > "Jim Buttafuoco" <jim@spectrumtelecorp.com> writes: > > > Hi, > > > > I "fixed" the Makefile.PL script under src/pl/plperl and > > removed the if ($Config{'useshrplib'} ne 'true') { ... } code. > > > > This will link in the static libperl.a file. The only down side > > of this is your libplperl.so file is going to be larger. > > That's not the only downside, on most architectures it won't > work. Code used like this should be compiled with -fpic, and static > libraries rarely are. > > -- > Trond Eivind Glomsrød > Red Hat, Inc. > >
"Jim Buttafuoco" <jim@spectrumtelecorp.com> writes: > Ok, I believe you. I am going to try on Solaris 8 and Tru64 now. I > believe this is a real pain because I don't know of anyone that "ships" > perl with a shared lib. It's easy enough to get a shared perl lib if you build from source: just say yes when the Configure script asks if you want one. Precompiled distributions tend not to do this, though. regards, tom lane
Tom and all, I really have stopped "building from source" for most base packages and try to use what is provided by the vendor (make's upgrades easier). I think if we can build plperl with the static library and it works then we should do so. Again I will test with Solaris 8 (using the perl that is shipped with it) and Tru64 (again using the perl that is shipped with it) tonight and let you know if it works Jim > "Jim Buttafuoco" <jim@spectrumtelecorp.com> writes: > > Ok, I believe you. I am going to try on Solaris 8 and Tru64 now. I > > believe this is a real pain because I don't know of anyone that "ships" > > perl with a shared lib. > > It's easy enough to get a shared perl lib if you build from source: > just say yes when the Configure script asks if you want one. > > Precompiled distributions tend not to do this, though. > > regards, tom lane > >