I have a Perl Script that I've written that connects to Oracle. The script works perfectly on my machine with PERL64 installed. I tried to turn this script into an EXE using ActiveState PerlApp. Again, works perfectly on my machine. Once the executable is on a machine that does not contain Perl it is missing DLL's needed to connect to Oracle.
use DBI;
# CONFIG VARIABLES
our $database = "database.app.net";
our $host = "server.app.net";
our $port = "1522";
our $user = "SVC_app";
our $pw = 'Password';
# DATA SOURCE NAME
our $dsn = "dbi:Oracle:$host:$port/$database";
# PERL DBI CONNECT
our $connect = DBI->connect($dsn, $user, $pw);
# PREPARE THE QUERY
our $query = 'SELECT Blah FROM database."table" where "blah" = ?';
our $query_handle = $connect->prepare($query);
# EXECUTE THE QUERY
$query_handle->execute($value);
# BIND TABLE COLUMNS TO VARIABLES
$query_handle->bind_columns(undef, \$return);
# LOOP THROUGH RESULTS
while($query_handle->fetch()) {
#print "$return";
}
The error i receive is :
Can't load 'auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified module could not be found at/DynaLoader.pm line 224.
Thanks in advance
There are two cases:
If you do NOT have the DLL files on the target machine, it's not going to work. DLL files aren't linked into the executables (as the name says, they're Dynamic Link Libraries, not static libraries)
If you DO have the DLL files on the target machine, but they're not found then there are a few possible explanations. The files may not be in the PATH, for instance. Or the files may not have the correct permissions, especially if you're calling your executable from something like a service (which by default runs on a system account which has different permissions).
Also, keep in mind that Window is a bit picky about DLL files. It may say that Oracle.dll is missing, but what is actually missing may be one of its dependencies. Maybe OCI.dll ?
And if you have more than one DLL file with the same name, try and make sure which one is loaded, because it may not be the right version.
If the files are there, there's only one version of them, they're in the PATH and it still cannot find them, you can try registering the files manually by running the regsvr32 command on the required DLL.
You need to separately install the Oracle client on any machine that you are running your EXE on.
PerlApp in the ActiveState's PDK will not wrap Oracle clients into the EXE because doing so will violate Oracle's re-distribution agreement.
Related
I am using an API called Piepan, which allows me to write Lua scripts for Mumble bots. For context, it is written in Golang using an alternative mumble implementation called Gumble. Piepan scripts are executed via cmd prompt through a piepan.exe.
I can require most libraries, like inspect.lua, and I can easily require luasocket in non-piepan scripts (scripts executed via lua.exe), but if I try to require luasocket (or what I really want, a redis library that depends on luasocket), I get an error. This is less of an error and more of a missing feature from the API, which the creator acknowledges. The creator suggests to someone else with this problem that they simply use Gumble, but I cannot do that as I am only a Lua programmer.
Here's the code of me just trying to require luasocket:
local socket = require ("include-test.socket")
(I've also tried include-test.socket.core and just socket.core)
In accordance with this stackoverflow answer, I moved my files to resemble the user's own directory, so it looks like this:
Piepan folder
-piepan exe and dlls (not luasocket dlls)
-include-test (folder)
--Script for piepan
--socket.lua
--socket folder
---core.dll
Despite the directory looking how I imagine it should based on other users' Q/As, I get this error:
.\include-test\socket.lua:13: module socket.core not found:
no field package.preload['socket.core']
Lstat : The system cannot find the path specified.
GetFileAttributesEx .\socket\core.lua: The system cannot find the path specified.
GetFileAttributesEx C:\Users\Michael\piepan\lua\socket\core.lua: The system cannot find the path specified.
GetFileAttributesEx C:\Users\Michael\piepan\lua\socket\core\init.lua: The system cannot find the path specified.
GetFileAttributesEx C:\Program Files (x86)\Lua\5.1\lua\socket\core.luac: The system cannot find the path specified.,
I've also tried including the following line, inspired by this stackoverflow answer.
package.cpath = package.cpath .. ';include-test/?.dll'
to no avail.
I am looking for any available solution, whether that be moving around dlls or compiling the original Piepan w/ extra files as needed.
(To clarify, I need a workaround that allows me to require the redis library within the same script I run through piepan. Using an outside script with the redis library to then, say, launch piepan and do something there, is not helpful to me.)
I have a huge set of files that I want to raw copy in my rootfs. However, do_rootfs always tries to compile / install some files not in raw mode but checking their dependencies (and therefore fails with no package provides /usr/local/bin/...).
I just want to copy executable and other sort of files in raw mode.
Any ideas?
As #jku pointed out, more details would be helpful. From the limited information using the following in your layer:
do_configure[noexec] = "1"
do_compile[noexec] = "1"
do_install[noexec] = "1"
Will do exactly what the name suggests; will not execute the particular function such as configuring, compiling or installing on the required object.
I have an assortment of PowerShell modules written in PowerShell (as opposed to C#) and I include documentation-comments in the code so that users get a full API description from Get-Help.
As I was writing a new module the help text seemed to get stuck at some point in time; any subsequent updates I have done to the help text in that file have not shown up after I saved the file, re-imported the module, or even restarted PowerShell then re-imported the module.
I next created a test module to see if I could replicate the issue. I set up psm1 and psd1 files, imported the module, and ran get-help, seeing the help from the psm1 file. I then added one line of text to the psm1 file, saved it, re-imported it... and the new line appeared in get-help!
I vaguely recall reading some time ago that you must bump the version in the psd1 file for new help to be recognized but my test case showed that is not necessarily needed (and I really don't want to have to bump the version).
I also vaguely recall reading that imported modules are cached somewhere and one could just delete the cached files to get it to recognize the new text--but I cannot recall where to find these.
So my goal is to be able to see the revised help text saved in the psm1 file in my real module without incrementing the module version. Ideas?
I was having similar issues when renaming and updating functions in some of my modules. A bit of searching turned up http://www.powertheshell.com/how-module-command-discovery-works-in-psv3/. In particular, the last bit about outdated caches mentions
PS> Get-Module -ListAvailable -Refresh
Running that solved my caching woes
PS> Get-Help Get-Module -Parameter Refresh
-Refresh [<SwitchParameter>]
Refreshes the cache of installed commands. The command cache is created when the session starts. It enables
the Get-Command cmdlet to get commands from modules that are not imported into the session.
This parameter is designed for development and testing scenarios in which the contents of modules have
changed since the session started.
When the Refresh parameter is used in a command, the ListAvailable parameter is required.
If you import a module that was already imported, it won't replace the functions that were previously imported. You need to remove the module first with Remove-Module, then import it again. I find it convenient to have this function in my profile:
function reload {
param(
[parameter(Mandatory=$true)]$Module
)
Write-Host;
try {
Remove-Module $Module -ea Stop;
} catch {
Write-Warning $error[0].Exception.Message;
Write-Host;
} finally {
Import-Module $Module -Verbose;
}
Write-Host;
}
I'm attempting to set up mod_lua module for Apache, but have encountered difficulty regarding accessing third party Lua modules. Say I have a hello_world.lua in Apache's htdocs folder that has something like this:
require "apache2"
function handle(r)
r.content_type = "text/html"
r:write "Hello World from <strong>mod_lua</strong>."
return apache2.OK
end
And I go to "http://localhost/hello_world.lua", that will function as expected. But if I try to add a line such as:
require "socket"
Or
require "cgilua"
I get the following output:
Error!
attempt to call a nil value
However, some modules do work, such as:
require "base"
That functions as expected.
If I navigate to base.lua in the filesystem (c:\program files\lua\5.1\lua\base.lua) and remove this file, then attempt to run my script I get the same error as stated above. So this must be the directory that mod_lua is checking for modules. Modules dlls are not in this folder, instead they are in c:\program files\lua\5.1\clibs\, which I set up the environment variable LUA_CPATH to point to.
Luasocket and cgilua are both present in this folder, yet they cause an error when I try to require them in my script.
From what I can gather, it works fine with any pure lua modules, but anything that has cmodules as well (socket, etc) causes problems.
Additional info:
OS: Windows 7 Home Premium
LUA_PATH = c:\program files\lua\5.1\lua\
LUA_CPATH = c:\program files\lua\5.1\clibs\
Apache version: 2.2.22
mod_lua version: http://www.corsix.org/content/mod-lua-win32#comment-3214
What needs to be done to be able to require modules in scripts run by mod_lua?
It looks like you need to add LuaPackageCPath and/or LuaPackagePath directives to your site configuration (in the global configuration file, or .htaccess, ...).
In your case, I'd assume that
LuaPackagePath c:\program files\lua\5.1\lua\
LuaPackageCPath c:\program files\lua\5.1\clibs\
should do the trick.
I've encountered a scenario where I'm building a Perl module as part of another Build system on a Windows machine. I use the --install_base option of Module::Build to specify a temporary directory to put module files until the overall build system can use them. Unfortunately, that other Build system has a problem if any of its files that it depends on are read only - it tries to delete any generated files before rebuilding them, and it can't clean any read-only files (it tries to delete it, and it's read only, which gives an error.) By default, Module::Build installs its libraries with the read-only bit enabled.
One option would be to make a new step in the build process that removes the read-only bit from the installed files, but due to the nature of the build tool that will require a second temporary directory...ugh.
Is it possible to configure a Module::Build based installer to NOT enable that read-only bit when the files are installed to the --install_base directory? If so, how?
No, it's not a configurable option. It's done in the copy_if_modified method in Module::Build::Base:
# mode is read-only + (executable if source is executable)
my $mode = oct(444) | ( $self->is_executable($file) ? oct(111) : 0 );
chmod( $mode, $to_path );
If you controlled the Build.PL, you could subclass Module::Build and override copy_if_modified to call the base class and then chmod the file writable. But I get the impression you're just trying to install someone else's module.
Probably the easiest thing to do would be to install a copy of Module::Build in a private directory, then edit it to use oct(666) (or whatever mode you want). Then invoke perl -I /path/to/customized/Module/Build Build.PL. Or, (as you said) just use the standard Module::Build and add a separate step to mark everything writable afterwards.
Update: ysth is right; it's ExtUtils::Install that actually does the final copy. copy_if_modified is for populating blib. But ExtUtils::Install also hardcodes the mode to read-only. You could use a customized version of ExtUtils::Install, but it's probably easier to just have a separate step.