Subject Re: [firebird-support] incompatability - UDF
Author Helen Borrie
At 10:30 PM 2/03/2005 +0000, Ray Holme wrote:


>I have created UDFs for Interbase for years, then firebird 1.0.3
>
>On the Linux (fedora) platform - two strange things happen.
>
> 1) if I declare the module_name as "SISudf"
> the real library name must be libSISudf.so
>
> before it was simply SISudf
>
> also note that the names for fbudf.so and ib_udf.so do not have
>"lib" in front
>
> since I must use IB solaris - it would be nice for
>compatablility if the module_name could be controlled (OK I can
>macroize that in the ddl if required)
>
> 2) MORE serious - even with the new name (built the old way) I
>cannot access the functions - I get:
>
>Statement failed, SQLCODE = -104
>
>invalid request BLR at offset 2
>-function GET_BIT is not defined
>-module name or entrypoint could not be found
>
> - it found the module for sure as I renamed it till it did.
> - the entry point should work - unless there are new ways to build
>a UDF
>
>Does anyone have an example makefile for building a 1.5 firebird UDF
>file works on the Linux platform (fedora should make little
>difference!)
>
>If so, please send me an example of the makefile and any simple
>function as you have it declared NOW. If you have a way to control the
>names as request in #1 - I would love that too.

You seem to be dancing in the dark here. May I suggest that you repost
this message to firebird-devel, but take pains to state

-- exactly which version of the server you are using

-- which kit you used to install it

-- the exact name, version and location of the client library you are
*actually using* to access the database

-- an assurance that your UDF declarations (entry_point and module_name)
exactly match the exported entry points and the library name, respectively,
for case

-- the UdfAccess setting in firebird.conf at the point where you last
started the server (edits to firebird.conf are read once, at startup..)

-- any facts pertinent to the threading model in your environment v.v. the
threading model of the engine build v.v. the threading model on the system
that built your UDF library

./heLen