We know this module's function is Dynamically load C libraries into Perl code .
But how's its own c library loaded into Perl in the first place?
I judge it should have its own c library because I don't find the function dl_load_file right inside DynaLoader.pm,so it must be in some c library...
Dynaloader is statically linked to Perl (managed by Configure), so that it is always available. It wouldn't work very well if it had to be available itself to load itself.
The source for Dynloader is at /ext/Dynaloader/ in the Perl distribution, which contains a number of different implementations of dl_load_file for the various architectures on which Perl might run.
So yes, dl_load_file is in a library, but it ends up inside perl when perl gets built.
Related
I tried to configure perl-5.18.2.
In checking C library phase, I got following messages.
Checking for GNU C Library...
You are not using the GNU C Library
I can use /mingw/bin/nm to extract the symbols from your C libraries. This
is a time consuming task which may generate huge output on the disk (up
to 3 megabytes) but that should make the symbols extraction faster. The
alternative is to skip the 'nm' extraction part and to compile a small
test program instead to determine whether each symbol is present. If
you have a fast C compiler and/or if your 'nm' output cannot be parsed,
this may be the best solution.
You probably shouldn't let me use 'nm' if you are using the GNU C Library.
Shall I use /mingw/bin/nm to extract C symbols from the libraries? [y] /mingw/bi
n/x86_64-w64-mingw32-nm.exe
I can't seem to find your C library. I've looked in the following places:
/lib
/usr/lib
None of these seems to contain your C library. I need to get its name...
Where is your C library?
Where is my C library?
I've tried /mingw/bin/nm.exe too.
http://search.cpan.org/dist/perl-5.18.2/README.win32:
The INSTALL file in the perl top-level has much information that is only relevant to people building Perl on Unix-like systems. In particular, you can safely ignore any information that talks about "Configure".
Instead, follow the instructions in the README.win32 file.
I have a C library and I need to access its functions in a Perl program.
I researched this on the internet and find that this wrapper can be implemented using XS, but I saw that XS is not consistent if needed to run the code on different OS.
I also found module FFI::Raw on CPAN which might do the job. Does anyone use FFI::Raw in production? What do you suggest to use, FFI::Raw or XS?
I have a project written in C which I wish to convert to Perl. A friend of mine suggested to use LLVM. I compiled my C code to LLVM assembly using Clang. Now I'm trying to convert this intermediate representation into Perl but I can't seem to find any backend for it. Would someone point me in the right direction?
No, there isn't such a backend. At least not directly. Emscripten converts LLVM IR to Javascript, and maybe you can use something else to convert that to Perl.
It's a pretty bad idea for moving a project from one language to another. The code will be completely unreadable and un-maintainable. Either do a honest rewrite or wrap your C as a library with Perl's foreign-function interface tools and use it from Perl.
Converting to Perl is a no go. It hasn't been done because emulating C in Perl would be insanely slow. They have completely different type systems, for starters. However, it's wholly unnecessary to convert the code to Perl to call it from Perl. You can load compiled C code from Perl.
What you'll have to do is tell Perl how to call those C functions. Perl deals with scalars and so on, but C deals with ints and so on. This is done using XS.
perlxstut contains the documentation on how to do all this.
What is the difference between library files and modules in Perl?
It's all Perl code to perl. All distinctions are purely idiomatic.
Perl code meant for inclusion that uses a package directive:
Called "module".
Usually has the extension .pm. Must have this extension for use to find them.
Should always be loaded with require, possibly via use.
Must therefore return a true value.
More modular, better supported by CPAN.
Perl code meant for inclusion that doesn't use a package directive:
Called "library". (At least historically. These days, "library" might also be used to refer to a module or distribution.)
Usually has the extension .pl.
Should always be loaded with do.
Pollutes the caller's namespace.
Usually indicative of a substandard design. Avoid these!
Perl code meant for direct execution by interpreter:
Called "script".
Usually has the extension .pl, or none at all.
Will probably start with a shebang (#!) line so they can be started without specifying perl.
Library files (I'm assuming you mean require 'foo.pl' stuff here) are an obsolete (pre-Perl 5) form of external module. For the most part, you shouldn't need to care any more, although there are still some Perl 4 installations around and therefore still some Perl code that remains backward compatible with them (and there's some code that's simply never been updated and still loads getcwd.pl etc.).
Nothing. They are both files that contain Perl code. Here are some of the possible circumstantial differences, though.
A perl executable is more likely to have a #!/bin/perl shbang.
Old .pl Perl libraries (hence the 'p' + 'l') are more likely to expect to be required than .pm modules.
Perl 5 style (.pm) modules are more likely to use Exporter -- although even newer module eschew exporting anything.
Unfortunately, I'm a totally noob when it comes to creating packages, exporting, etc in Perl. I tried reading some of the modules and often found myself dozing off from the long chapters. It would be helpful if I can find what I need to understand in just one simple webpage without the need to scroll down. :P
Basically I have two modules, A & B, and A will use some function off from B and B will use some functions off from A. I get a tons of warning about function redefined when I try to compile via perl -c.
Is there a way to do this properly? Or is my design retarded? If so what would be a better way? As the reason I did this is to avoid copy n pasting the other module functions again into this module and renaming them.
It's not really good practice to have circular dependencies. I'd advise factoring something or another to a third module so you can have A depends on B, A depends on C, B depends on C.
So... the suggestion to factor out common code into another module is
a good one. But, you shouldn't name modules *.pl, and you shouldn't
load them by require-ing a certain pathname (as in require
"../lib/foo.pl";). (For one thing, saying '..' makes your script
depend on being executed from the same working directory every time.
So your script may work when you run it as perl foo.pl, but it won't
work when you run it as perl YourApp/foo.pl. That is generally not good.)
Let's say your app is called YourApp. You should build your
application as a set of modules that live in a lib/ directory. For
example, here is a "Foo" module; its filename is lib/YourApp/Foo.pm.
package YourApp::Foo;
use strict;
sub do_something {
# code goes here
}
Now, let's say you have a module called "Bar" that depends on "Foo".
You just make lib/YourApp/Bar.pm and say:
package YourApp::Bar;
use strict;
use YourApp::Foo;
sub do_something_else {
return YourApp::Foo::do_something() + 1;
}
(As an advanced exercise, you can use Sub::Exporter or Exporter to
make use YourApp::Foo install subroutines in the consuming package's
namespace, so that you don't have to write YourApp::Foo:: before
everything.)
Anyway, you build your whole app like this. Logical pieces of
functionally should be grouped together in modules (or even better,
classes).
To make all this run, you write a small script that looks like this (I
put these in bin/, so let's call it bin/yourapp.pl):
#!/usr/bin/env perl
use strict;
use warnings;
use feature ':5.10';
use FindBin qw($Bin);
use lib "$Bin/../lib";
use YourApp;
YourApp::run(#ARGV);
The key here is that none of your code is outside of modules, except a
tiny bit of boilerplate to start your app running. This is easy to
maintain, and more importantly, it makes it easy to write automated
tests. Instead of running something from the command-line, you can
just call a function with some values.
Anyway, this is probably off-topic now. But I think it's important
to know.
The simple answer is to not test compile modules with perl -c... use perl -e'use Module'
or perl -e0 -MModule instead.
perl -c is designed for doing a test compile of a script, not a module. When you run it
on one of your
When recursively using modules, the key point is to make sure anything externally referenced is set up early. Usually this means at least making use #ISA be set in a compile time construct (in BEGIN{} or via "use parent" or the deprecated "use base") and #EXPORT and friends be set in BEGIN{}.
The basic problem is that if module Foo uses module Bar (which uses Foo), compilation of Foo stops right at that point until Bar is fully compiled and it's mainline code has executed. Making sure that whatever parts of Foo Bar's compile and run-of-mainline-code
need are there is the answer.
(In many cases, you can sensibly separate out the functionality into more modules and break the recursion. This is best of all.)