I have downloaded strawberry PERL and writing one application with CGI Perl Apache on Winxp sp3).
One of the libraries (written by someone else) which I using uses XML::LibXML. When i load the page it gives Internal Server Error. From Apache error log i can see this error:
Can't load 'C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll' for module XML::LibXML: load_file:The specified module could not be found at C:/strawberry/perl/lib/DynaLoader.pm line 190.
C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll exists with all permissions.
Also this library works properly on Linux. My application also works fine if I remove all code that needs LibXML.
Can anyone tell me when can be possible issue here.
If you peek into the source for DynaLoader you'll find
Many dynamic extension loading problems will appear to come from
this section of code: XYZ failed at line 123 of DynaLoader.pm.
Often these errors are actually occurring in the initialisation
C code of the extension XS file. Perl reports the error as being
in this perl code simply because this was the last perl code
it executed.
You should have also gotten (but may not have noticed) the following dialog, which provides a more accurate error message:
The problem isn't that perl can't find LibXML.dll; it's that LibXML.dll can't find the real libxml. (The former is just a wrapper that provides Perl bindings for the latter.) To fix that you need to ensure that Strawberry Perl's c\bin folder is in your PATH. In your case, that would be C:\strawberry\c\bin.
You might have to check the environment variable settings in the windows,
make sure that the installation path of the module is present in the PATH variable.
The reason it works in linux is that make files usually set the environment variables for you in linux in windows it may not have set properly.
For eg;
go to Control Panel\System and Security\System click change settings then advanced tab in user variable section see if there is a variable called perl5lib.
if not create an new perl5lib variable and add the path of your library ( usuall C:\Perl\site\lib but may be different in your case)
I had the same issue after installing Strawberry perl. It was working fine when I run the script from server, but not remotely from a automation tool. The issue was because of the Environment variables not updated when we run it remotely. So I did server reboot, which resolved the issue.
I encountered the same problem recently, in my case it was not related to PATH variable (it was already correct). The thing is I was executing my script from Git Bash console and as it turned out git-bash perl was being used instead of Strawberry (see git-bash perl should not be first in path). Switching to standard Windows CMD terminal helped.
Related
I have been trying to compile a script that was written in perl by someone other than myself into an executable format that can be used without having perl installed. There seems to be some sort of issue with Crypt::SSLeay packaging but I'm not sure what the error means. Here is a screenshot of the error message.
I've tried using PAR pp and cava to package, both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error seen in the screenshot. It's been the same error each time after changing compiler settings, and I'm not sure what to do at this point. If I have left anything out that may assist in answer please let me know and I will be happy to provide, coding is not my field so I am still learning and this is my first encounter with Perl.
First off, you probably do not need and should not use Crypt::SSLeay. However, both the modern Net::SSLeay and Crypt::SSLeay require OpenSSL binaries to be installed on the machine to run.
both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error ...
That's because the target machine does not have OpenSSL installed in the same location on which compiled the modules you are bundling.
I have memory related problem in my application on solaris9 environment where Tcl_DeleteInterp() function calls lot of free() and mutex_unlock() functions. To debug the problem i followed the below steps to compile tcl on solaris server (with TCL_MEM_DEBUG flag) but still i couldn't use the 'memory' command in my interpreter.
Ran configure script on server (./configure –prefix=<directory needs to be installed> --enable-symbols=mem)
Make clean all
Make install (tcl libraries and tlcsh exe is copied to the path specified in step1)
Compilation generated two libraries (libtcl8.4g.so and libtclstub8.4g.a), I copied libtcl8.4g.so as libtcl8.4.so to my app
Copied tcl8.4 directory as well.
I also copied the tclsh8.4 to $PROVHOME/bin and created soft link as tclsh-> tclsh8.4.
From my application i linked the debug symbol enabled libraries to the place where exactly i created the Tcl interpreter.
Initialized the Tcl interpreter to using Tcl_InitMemory() function (so that the memory command will be registered in the supplied(arg) interpreter.
When i used the interpreter exe (tclsh) separately i could execute the memory command, but when i used the same exe on my application its not working. Can someone help me what could be the possible reason for this problem ?
Also help me how can i cross verify the libraries that they are compiled with TCL_MEM_DEBUG flag.
Will the Tcl source code tar file contain Solaris directory where i have to build the libraries or should i use the unix source code for solaris platform as well ?
Thanks
Are you using [mem] interactively (which does expansion of unambiguous short command names) and forgetting to use the full name ([memory]) in your scripts?
You're using Tcl embedded in your code? You need to call Tcl_InitMemory (passing in the handle to the interpreter where you want the memory command created) after creation of the interpreter and before you run user scripts, i.e., straight after the Tcl_CreateInterp gives you the handle (which should in turn come after the Tcl_FindExecutable call that initializes the shared parts of the library).
You must also make sure that everything is built with that flag set so that the correct memory allocation APIs are used in both your code when it integrates with Tcl, and you must make sure that you are linking against the debugging build. It's probably the linking that has gone wrong, but I've not done that level of development on Solaris for many years.
I think you'll find that “Getting a list of used libraries by a running process (unix)” is relevant to your problems.
I want to generate a ER Diagram sort of, of my spatial database i created inside of Postgresql. As i am also new to Postgresql, i am not too sure if the diagramming functionality can be done using whats offered by the PgAdmin (not referring to the Graphical Query Builder). However, it seems to me there is none. I read around that there is a perl based tool called postgresql_autodoc that can run through PostgreSQL system tables and return HTML, Dot, Dia and DocBook XML which describes the database. Now this is not exactly what i wanted but its the closest option i have. So i have successfully installed, ActivePerl 5.8 and DBD-Pg 2.10.0 for Perl 5.8 (DBD PG is a Perl DBI driver for the PostgreSQL database) and i have also downloaded the postgresql_autodoc.pl file. I have also added the path for Perl. But when i try to run the postgresql_autodoc.pl via the command prompt, i was getting this error: Possible Unintended Interpolation of #TEMPLATE in string at C:/Perl/bin/postgresql_autodoc.pl line 1831. Global symbol "#TEMPLATE" requires explicit package name at C:/Perl/bin/postgresql_autodoc.pl line 1831. Execution of C:/Perl/bin/postgresql_autodoc.pl aborted due to compilation errors.
I tried to view the postgresql_autodoc.pl using notepad++ however i have no experience with the perl language and so i cant figure out what is really wrong. All i could do is locate line 1831 but i dont know what i should do to fix this problem.
The postgresql_autodoc.pl file was downloaded from: http://www.rbt.ca/autodoc/
I would appreciate if anyone can help me here!
Thanks in advance
Barbara
That thingy, ##TEMPLATE-DIR##, is a string that is replaced when you build and install the module -- meaning you're not supposed to run it directly from the unpacked archive.
Most Perl modules are installed with a more or less simple three-step installation process, something like perl Makefile.PL ; make ; make install. However, this package is slightly different, you seem only to need make install.
Note that I have no experience with installing Perl modules on Windows with ActiveState. So the above may not work (e.g. if there's no make utility which is usually not part of Perl -- though it might be part of the ActiveState Perl distribution).
But there's a workaround. You can simply do what the install script does and replace the ##TEMPLATE-DIR## string yourself. It can be done easily with any text editor by replacing the two occurrences of ##TEMPLATE-DIR## with the path to where the postgresql_autodoc.pl script has been unpacked to -- meaning it's the path the script will look for the *.tmpl files in.
Note that Windows path names can be written with forward slashes in Perl, meaning C:/Temp/postgresql_autodoc should be OK.
I need to run 2 versions of perl on Windows 7.
The first one is bundled with VMware vCLI, it is Active State Perl 5.8.8.
The one I need for script dev is Stawberry 5.12.4 (something like that).
When I type perl -v It calls the AS perl which does not seem to support things like named captures and other things I took for granted in perl.
Both perls are installed I just don't know how to call Stawberry instead of AS perl.
Any idea?
Your specific problem can be addressed by editing the PATH environment variable, as noted by David Heffernan.
System control panel
> Advanced system settings
> Environment variables
> Path
> Edit...
More broadly, here's the general approach I am currently using to manage multiple versions of Perl, Python, etc. on Windows 7. I would appreciate tips for better ways to do this.
I create a Perl installation area like this:
C:\usr\perls\
5.10\
5.12\
etc.
current # Symbolic link.
In that same area I create a symbolic link (current) referring to the version I want as my default, and I make sure that all Perl references in my PATH environment variable use current rather than specific version numbers.
# Open cmd window as an administrator.
cd C:\usr\perls
mklink /D current 5.12
Under that approach, I can quickly modify my system's default Perl by changing one symbolic link rather than making multiple edits to PATH, which is a more tedious.
In addition, I add a directory to my PATH containing batch scripts to invoke specific Perls.
C:\usr\bin
perl5.10.bat
perl5.12.bat
etc.
Those scripts look like this example:
# C:\usr\perls\5.12\perl\bin\perl.exe %*
I'd do this by changing the PATH environment variable. Make it point to the 5.12 version and you may find that the VMware code continues working because it knows where to find it its Perl. If not, make a .bat file that sets PATH to refer to the 5.12 installation and use that to launch into a cmd window from which calls to perl invoke 5.12.
My eclipse tries to compile/build Perl files in my Java project and fails. I installed Perl EPIC just for syntax colouring, how can I get it to ignore errors?
I tried going into Project->Properties->Builders, and uncheck Perl Epic, this didn't change anything.
I'm using Eclipse :Helios Service Release 1
Build id: 20100917-0705
On Windows XP
I have basically the same issue as this question,
How can I set up Eclipse to edit Perl without the runtime checking?
I've been looking into similar issue for quite some time too. Apparently the Epic Perl plugin goes wildly checking anything/folder/file it finds inside the project, so like mine where I have config files, data directories, it goes inside and tries to validate "perl stuff", which evidently is an annoyance: the error log view displays a lot of useless information.
Did you try to uncheck the "Perl Auto Builder" ?
I'm not parsing this sentence in the context of your question: "My eclipse tries to compile/build perl files in my java project and fails."
Are you saying that you are running perl as a java project, and getting the inevitable error message because it is not java? Just wondering why you don't want to have your perl program set up as a perl project possibly referenced by your java project, assuming that that is what you are trying to do.
Generally, when I set up a perl project, I edit its properties and set its includes to match the current directory or local module paths. Assuming that there are self-written modules I must call, and they are not located on this machine (e.g. I wouldn't have FOO::smb on a windows machine -- it makes no sense. When I am developing for linux, I will put all my functions in there for convenience's sake)
In that case, I create a FOO directory in the workspace, and create a dummy FOO::smb module with however many stub functions in it to get me going and let my syntax highlighting and error checkign do their proper jobs for me. If I write dummy subs to match the real modules well enough, I can debug my scripts somewhat before uploading them. I figure that I should be well enough aware of what they are supposed to do anyway.
I will go so far as to dummy out CPAN modules assuming that installing them on my development workstation makes no sense or is impossible. Highlighting and syntax checking are both invaluable tools, and finding a way to make both of them work saves my sanity.