Hello,
I noticed that libperl.a (used to be part of the perl package in older opensuse releases) is no longer available.
Was this library moved to a different package?
Maybe it is possible to recreate it from the still existing libperl.so?
Any hints?
Josef Wolf escribió:
Was this library moved to a different package?
No, it was removed, it has absolutely no use.
Any hints?
Use Shared libraries, there is no reason to use static libperl.
Thanks for the answer, Christian!
On Thu, Jul 31, 2008 at 04:15:20PM -0400, Cristian Rodríguez wrote:
Josef Wolf escribió:
Was this library moved to a different package?
No, it was removed, it has absolutely no use.
I think I have a use for it: I have a home-grown XS library which provides functionality from a C library to perl. Linking everything into one binary saves lots of pain when it comes to deployment of such a program.
Any hints?
Use Shared libraries, there is no reason to use static libperl.
Please remember that with shared libs, you have to recompile on the host where the final program is to be run. Here is a quote from perlembed manpage:
! The cardinal rule: COMPILE THE PROGRAMS IN EXACTLY THE SAME WAY ! THAT YOUR PERL WAS COMPILED. (Sorry for yelling.)
I have lots of boxes where no compiler is installed at all. Then there are boxes running a different distro than the development machine runs. Linking statically into one binary makes life a lot easier in such situations.
Josef Wolf escribió:
Thanks for the answer, Christian!
On Thu, Jul 31, 2008 at 04:15:20PM -0400, Cristian Rodríguez wrote:
Josef Wolf escribió:
Was this library moved to a different package?
No, it was removed, it has absolutely no use.
I think I have a use for it: I have a home-grown XS library which provides functionality from a C library to perl. Linking everything into one binary saves lots of pain when it comes to deployment of such a program.
It does not really work the way you expect.. see:
http://people.redhat.com/drepper/no_static_linking.html
On Thu, Jul 31, 2008 at 07:28:18PM -0400, Cristian Rodríguez wrote:
Josef Wolf escribió:
Thanks for the answer, Christian!
On Thu, Jul 31, 2008 at 04:15:20PM -0400, Cristian Rodríguez wrote:
Josef Wolf escribió:
Was this library moved to a different package?
No, it was removed, it has absolutely no use.
I think I have a use for it: I have a home-grown XS library which provides functionality from a C library to perl. Linking everything into one binary saves lots of pain when it comes to deployment of such a program.
It does not really work the way you expect.. see:
OK, at least the security aspects have a point.
The question now becomes, how to (painless) deploy a perl XS library which makes callbacks into perl. That means, the XS library needs access to the my_perl variable, which is declared as
static PerlInterpreter *my_perl;
in the original libperl.so
Any hints?
Am Freitag 01 August 2008 08:45:06 schrieb Josef Wolf:
The question now becomes, how to (painless) deploy a perl XS library which makes callbacks into perl. That means, the XS library needs access to the my_perl variable, which is declared as
static PerlInterpreter *my_perl;
in the original libperl.so
Any hints?
You'd access it in exactly the same way that you access any other variable. Declare it "external" in your code and simply use it. The linker will take care of the rest
The "static" there has nothing to do with linking. It simply means that the variable isn't created dynamically every time a function is called, it is created once and keeps its value. Static or dynamic linking doesn't enter into it at all
By the way, your previous comment about having to compile locally on all machines is wrong. The remark in the man page you quoted is about using the same compiler flags as was used for perl. That doesn't mean it has to be rebuilt every time it is installed
Anders
On Fri, Aug 01, 2008 at 08:45:06AM +0200, Josef Wolf wrote:
The question now becomes, how to (painless) deploy a perl XS library which makes callbacks into perl. That means, the XS library needs access to the my_perl variable, which is declared as
static PerlInterpreter *my_perl;
in the original libperl.so
Any hints?
It should be available via the "aTHX" variable/macro. If not, try Perl_get_context().
Cheers, Michael.
On Fri, Aug 01, 2008 at 10:46:39AM +0200, Michael Schroeder wrote:
On Fri, Aug 01, 2008 at 08:45:06AM +0200, Josef Wolf wrote:
The question now becomes, how to (painless) deploy a perl XS library which makes callbacks into perl. That means, the XS library needs access to the my_perl variable, which is declared as
static PerlInterpreter *my_perl;
in the original libperl.so
Any hints?
It should be available via the "aTHX" variable/macro. If not, try Perl_get_context().
Thanks for the hint, Michael. I could get it working with this!
Thanks for your reply, Anders!
On Fri, Aug 01, 2008 at 09:37:59AM +0200, Anders Johansson wrote:
Am Freitag 01 August 2008 08:45:06 schrieb Josef Wolf:
The question now becomes, how to (painless) deploy a perl XS library which makes callbacks into perl. That means, the XS library needs access to the my_perl variable, which is declared as
static PerlInterpreter *my_perl;
in the original libperl.so
Any hints?
You'd access it in exactly the same way that you access any other variable. Declare it "external" in your code and simply use it. The linker will take care of the rest
The "static" there has nothing to do with linking. It simply means that the variable isn't created dynamically every time a function is called, it is created once and keeps its value. Static or dynamic linking doesn't enter into it at all
The "static" there has pretty much to do with linking. Because of the "static" keyword the variable is not visible/accessible outside of the compilation unit. Therefore it is only accessible by libperl.so but not accessible by my XSUBs.
By the way, your previous comment about having to compile locally on all machines is wrong. The remark in the man page you quoted is about using the same compiler flags as was used for perl. That doesn't mean it has to be rebuilt every time it is installed
How can I be sure that debian/ubuntu/mandrake/redhat/whatever use the same compiler flags and linker flags as suse? They can even change the flags between releases. So I have to build and maintain a dist package for every release of every distro I want to support. And I have to rebuild every time a distro ships a new release. That would be even more pain than rebuild every time it is installed.
On Friday 01 August 2008 18:56:49 Josef Wolf wrote:
The "static" there has pretty much to do with linking. Because of the "static" keyword the variable is not visible/accessible outside of the compilation unit. Therefore it is only accessible by libperl.so but not accessible by my XSUBs.
And linking statically changes this how?
"static" affects scope, yes, but how you link it is irrelevant
How can I be sure that debian/ubuntu/mandrake/redhat/whatever use the same compiler flags and linker flags as suse? They can even change the flags between releases. So I have to build and maintain a dist package for every release of every distro I want to support. And I have to rebuild every time a distro ships a new release. That would be even more pain than rebuild every time it is installed.
You could use the build service for it. It is capable of building for multiple distributions.
I am not familiar with the peculiarities of building perl addons, but after a quick read of the "perlxstut" man page (and a quick test), it looks like the h2xs command will generate a Makefile.PL that extracts the compilation information you need and puts it into a Makefile. That, combined with the build service, should allow you to build packages for all distributions that will get automatically updated and rebuilt if there are updates to the dependencies
Anders
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Josef Wolf wrote:
Thanks for your reply, Anders!
On Fri, Aug 01, 2008 at 09:37:59AM +0200, Anders Johansson wrote:
Am Freitag 01 August 2008 08:45:06 schrieb Josef Wolf:
<snip>
By the way, your previous comment about having to compile locally on all machines is wrong. The remark in the man page you quoted is about using the same compiler flags as was used for perl. That doesn't mean it has to be rebuilt every time it is installed
How can I be sure that debian/ubuntu/mandrake/redhat/whatever use the same compiler flags and linker flags as suse? They can even change the flags between releases. So I have to build and maintain a dist package for every release of every distro I want to support. And I have to rebuild every time a distro ships a new release. That would be even more pain than rebuild every time it is installed.
I doubt if you can...
I rather think you are asking this question in the wrong place. I would suggest subscribing to the Perl developer lists which will probably will give you better information than this list on how to deal with this issue.
As far as I can understand it you have an application in which you call a Perl script from, rather than using something like Perl::Inline which does the opposite. I have little knowledge personally of the former approach.
Perl has a couple of tools for cross platform building of Perl modules for the latter approach (Module::Build and ExtUtils::MakeMaker) without which CPAN would probably be unworkable. Any C or C++ code in the Perl Module is compiled on the installation and testing of the module.
But for the former creating a portable package would require that you create suitable make script(s) and source package(s) that may need to include the source code for the library you are missing. (Not having compiler support on some of the host systems complicates matter somewhat). The key here is to distribute with the instructions/scripts to build your code.
- -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone.
Bjarne Stroustrup ==============================================================================
-
Anders Johansson -
Cristian Rodríguez -
G T Smith -
Josef Wolf -
Michael Schroeder