| Subject | Re: [firebird-support] UDF Meltdown |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-07-15T00:17:15Z |
At 08:17 AM 15/07/2008, you wrote:
On Linux, take care that the entry_point and module_name arguments AND any calls are case-correct. At both compile and execution time your PSQL modules must be able to find both the module and the entry point *as declared* - this is hard-wired into the BLR of the PSQL module. (which is a good reason NOT to configure UdfAccess as Full!)
The "right" thing is to use the Restrict option and provide the paths to the UDF libraries. The default setting is 'Restrict UDF', which assumes that you used the Firebird convention for locating the libraries, i.e., in directory UDF beneath the Firebird root directory. Here 'UDF' is a relative path location.
If you have used a Linux distro that locates things differently from the Firebird convention then you will need to add these locations to the Restrict list the UDF path location. If the location is not within the firebird root then a full path is required, NOT a relative path.
Also check that the executables can be found. Some distros move shared objects out of the firebird root directory into "some other place", according to their own conventions, e.g. /usr/lib
Ensure that (1) SS is running as user 'firebird' ; (2) you have a system user 'firebird' and a 'firebird' group and (3) that firebird:firebird has sufficient read and execute permissions on both the UdfAccess Restrict directories and the executable files within them.
In the declarations, make sure that the format of the library name is correct for the configured UdfAccess mode, e.g.
MODULE_NAME '/usr/local/lib/myfuncs' is wrong for Full (needs to be '/usr/local/lib/myfuncs.so'); while 'myfuncs.so' is wrong if the setting is Restrict (should be 'myfuncs'). There are quite a few permutations of "invalid"....
As always, GET THE PERMISSIONS RIGHT.
./heLen
>Hi All,That figures. At declaration time the module_name and entry_point arguments are stored but not checked - deliberately, since this would prevent the database from being portable.
>
>A few years ago I developed a database in Firebird 1.5.5 and was using the rFunc UDF Library. No problems at all. It started out on a Windows 2000 Advanced Server and later migrated to a Red Hat Linux server. No problems with the migration, and rFunc has a linux compiled UDF.
>
>I am now developing a new database, and I am extremely behind. I first used the latest FirebirdSS 2.1.0.17798 32-bit on a recent CentOS installation. Installed the rFunc library as well as the FreeAdhocUDF libraries for Linux on it. It worked at first, but then shortly started giving me errors when I attempted to compile and commit the transaction to create my procedures. The standard BLR error which indicates it cannot find the module or entry point for my UDF.
>
>I never get errors when declaring the UDF functions. I only get the error when creating the procedures or running the old procedures.
On Linux, take care that the entry_point and module_name arguments AND any calls are case-correct. At both compile and execution time your PSQL modules must be able to find both the module and the entry point *as declared* - this is hard-wired into the BLR of the PSQL module. (which is a good reason NOT to configure UdfAccess as Full!)
>This is not a good idea as it requires you to provide the full local path to the UDF library in all declarations. Not only does this make your database totally specific to a single platform and host machine, it will also break existing compiled SPs that call the UDFs.
>I have used three different version of FirebirdSS 2.x now on both Win32 and 32-bit and 64-bit Linux operating systems (CentOS, Red Hat Linux enterprise) and continually get the same errors when attempting to use the UDF functions. I have created all new databases from scratch with a single declared UDF function and a single stored procedure attempting to use that function.
>
>I have edited the Firebird.conf file to give everything �full� access
The "right" thing is to use the Restrict option and provide the paths to the UDF libraries. The default setting is 'Restrict UDF', which assumes that you used the Firebird convention for locating the libraries, i.e., in directory UDF beneath the Firebird root directory. Here 'UDF' is a relative path location.
If you have used a Linux distro that locates things differently from the Firebird convention then you will need to add these locations to the Restrict list the UDF path location. If the location is not within the firebird root then a full path is required, NOT a relative path.
Also check that the executables can be found. Some distros move shared objects out of the firebird root directory into "some other place", according to their own conventions, e.g. /usr/lib
> and have tried various different configurations for it as well.Don't overlook the fact that configuration changes won't be seen by Superserver until after a server restart.
Ensure that (1) SS is running as user 'firebird' ; (2) you have a system user 'firebird' and a 'firebird' group and (3) that firebird:firebird has sufficient read and execute permissions on both the UdfAccess Restrict directories and the executable files within them.
In the declarations, make sure that the format of the library name is correct for the configured UdfAccess mode, e.g.
MODULE_NAME '/usr/local/lib/myfuncs' is wrong for Full (needs to be '/usr/local/lib/myfuncs.so'); while 'myfuncs.so' is wrong if the setting is Restrict (should be 'myfuncs'). There are quite a few permutations of "invalid"....
>Personally, I don't like to have to mess around with the default for UdfAccess. If you have to call UDFs then just put the SO's straight into $firebirdroot/UDF. If your Linux version insists on putting SO's somewhere else, then search them out and make symlinks in ../UDF for them.
>I am at my wits end here and frankly have no idea why the UDF libraries refuse to work at all now. I just don�t get it.
As always, GET THE PERMISSIONS RIGHT.
./heLen