library tkes2;
{$mode objfpc}
{$PACKRECORDS C}
function somefn: integer; cdecl; export;
begin
 somefn:= 3;
end;
exports
 //I do not do as:
 // somefn name 'somefn'; // because of this cause error tkes2(17,1) Error: Asm: Duplicate label somefn
 //so I do as:
 somefn name '_somefn';
end.

#fpc tkes2 -Xp
Free Pascal Compiler version 2.2.0 [2008/11/09] for i386 Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: FreeBSD/ELF for i386
Compiling tkes2
Linking libtkes2.so
17 lines compiled, 0.1 sec

#ld -shared -soname libtkes2.so.1 -o libtkes2.so.1.0 -lc tkes2.o #cp tkes2.so /usr/local/libexec/firebird/udf/
#cp tkes2.so.1.0 /usr/local/libexec/firebird/udf/
#cd /usr/local/libexec/firebird/udf/
#ls -l
-rwxr-xr-x 1 root wheel 6022 12 ноя 04:07 libtkes2.so -rwxr-xr-x 1 root wheel 3219 12 ноя 04:32 libtkes2.so.1.0

# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.

in SQL:
DECLARE EXTERNAL FUNCTION FNTEST2
RETURNS INTEGER BY VALUE
ENTRY_POINT 'tkes2__somefn'
MODULE_NAME 'libtkes2'

select fntest2() from sometable;

invalid requiest BLR at offset 64
function FNTEST2 is not defined
module name or entrypoint could not be found

repeat:
DECLARE EXTERNAL FUNCTION FNTEST2
RETURNS INTEGER BY VALUE
ENTRY_POINT 'tkes2_somefn'
MODULE_NAME 'libtkes2'

select fntest2() from sometable;

invalid requiest BLR at offset 64
function FNTEST2 is not defined
module name or entrypoint could not be found

another try:

DECLARE EXTERNAL FUNCTION FNTEST2
RETURNS INTEGER BY VALUE
ENTRY_POINT '_somefn'
MODULE_NAME 'libtkes2'

select fntest2() from sometable;

invalid requiest BLR at offset 64
function FNTEST2 is not defined
module name or entrypoint could not be found

DECLARE EXTERNAL FUNCTION FNTEST2
RETURNS INTEGER BY VALUE
ENTRY_POINT 'somefn'
MODULE_NAME 'libtkes2'

select fntest2() from sometable;

invalid requiest BLR at offset 64
function FNTEST2 is not defined
module name or entrypoint could not be found

What is wrong?

Should there be a 'uses' line somewhere?

Здравствуйте, Jon.

No, I just trying to write UDF in FPC on FreeBSD platform.
this is my first try, there is no any 'uses';

I have tryed in C:

extern int fntest();

int fntest()
{
return 8;
}

this work, but fpc does not (((
I need fpc because of I have many functions in delphi on Win32 platform that I need to port to FreeBSD

Вы писали 12 ноября 2008 г., 11:33:37:

J> Should there be a 'uses' line somewhere?

J>
J> _______________________________________________ J> fpc-pascal maillist -
J> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Maybe with nm helps to show you how the function name is mangled.

Or use "fpc -s ..." and "gcc -S -fverbose-asm ..." on both source files for comparing the labels in the generated assembler code.

HTH,
Marc

Oops, I meant "fpc -a ...".

Marc

Здравствуйте, Marc.

Вы писали 12 ноября 2008 г., 21:20:23:

MS> Am Mittwoch, den 12.11.2008, 20:00 +0100 schrieb Marc Santhoff:

MS> Oops, I meant "fpc -a ...".

MS> Marc

C file:
testudf.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dyna 00001630 A _DYNAMIC
00001704 A _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
000016f4 d __CTOR_END__
000016f0 d __CTOR_LIST__
000016fc d __DTOR_END__
000016f8 d __DTOR_LIST__
0000162c r __FRAME_END__
00001700 d __JCR_END__
00001700 d __JCR_LIST__
0000171c A __bss_start
w __cxa_finalize@@FBSD_1.0
00000550 t __do_global_ctors_aux
000004a0 t __do_global_dtors_aux
00001624 d __dso_handle
00000537 t __i686.get_pc_thunk.bx
0000171c A _edata
00001720 A _end
00000584 T _fini
0000046c T _init
0000171c b completed.4685
00000540 T fntest
00000500 t frame_dummy
00001628 d p.4683

libtkes2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped U FINALIZE$_OBJPAS
U FPC_INITIALIZEUNITS
0000158c D FPC_RESOURCESTRINGTABLES
0000157c D FPC_THREADVARTABLES
U INIT$_OBJPAS
U INIT$_SYSTEM
00001564 D INITFINAL
00000530 T P$TKES2_SOMEFN$$LONGINT
00000544 T P$TKES2_main
00000544 T PASCALMAIN
U THREADVARLIST_OBJPAS
00001560 D THREADVARLIST_P$TKES2
U THREADVARLIST_SYSTEM
000015cc A _DYNAMIC
00001654 A _GLOBAL_OFFSET_TABLE_
00001660 A __bss_start
00001598 D __fpc_valgrind
00001594 D __heapsize
00001590 D __stklen
00001660 A _edata
00001660 A _end
00000550 T _somefn
00000530 T somefn

Здравствуйте, Marc.

Вы писали 12 ноября 2008 г., 21:20:23:

MS> Am Mittwoch, den 12.11.2008, 20:00 +0100 schrieb Marc Santhoff:

MS> Oops, I meant "fpc -a ...".

MS> Marc

# Compiler executable checksum: 420481ffe9facb411cc92bbca2cb4405

.text
.p2align 4,,15
.globl fntest
.type fntest, @function
fntest:
pushl %ebp #
movl %esp, %ebp #,
movl $8, %eax #, D.1541
popl %ebp #
ret
.size fntest, .-fntest
.ident "GCC: (GNU) 4.2.1 20070719 [FreeBSD]"

.file "tkes2"
# Begin asmlist al_begin
# End asmlist al_begin
# Begin asmlist al_stabs
# End asmlist al_stabs
# Begin asmlist al_procedures

.section .text
.balign 4,0x90
.globl P$TKES2_SOMEFN$$LONGINT
.type P$TKES2_SOMEFN$$LONGINT,@function
P$TKES2_SOMEFN$$LONGINT:
.globl somefn
.type somefn,@function
somefn:
pushl %ebp
movl %esp,%ebp
subl $4,%esp
movl $3,-4(%ebp)
movl -4(%ebp),%eax
leave
ret
.Le0:
.size P$TKES2_SOMEFN$$LONGINT, .Le0 - P$TKES2_SOMEFN$$LONGINT

.section .text
.balign 4,0x90
.globl PASCALMAIN
.type PASCALMAIN,@function
PASCALMAIN:
.globl P$TKES2_main
.type P$TKES2_main,@function
P$TKES2_main:
pushl %ebp
movl %esp,%ebp
call FPC_INITIALIZEUNITS
leave
ret
.Le1:
.size P$TKES2_main, .Le1 - P$TKES2_main

.section .text
.balign 4,0x90
.globl _somefn
.type _somefn,@function
_somefn:
jmp P$TKES2_SOMEFN$$LONGINT
.Le2:
.size _somefn, .Le2 - _somefn
# End asmlist al_procedures
# Begin asmlist al_globals

.section .data
.balign 4
.globl THREADVARLIST_P$TKES2
.type THREADVARLIST_P$TKES2,@object
THREADVARLIST_P$TKES2:
.long 0
.Le3:
.size THREADVARLIST_P$TKES2, .Le3 - THREADVARLIST_P$TKES2

.section .data
.balign 4
.globl INITFINAL
.type INITFINAL,@object
INITFINAL:
.long 2,0
.long INIT$_SYSTEM
.long 0
.long INIT$_OBJPAS
.long FINALIZE$_OBJPAS
.Le4:
.size INITFINAL, .Le4 - INITFINAL

.section .data
.balign 4
.globl FPC_THREADVARTABLES
.type FPC_THREADVARTABLES,@object
FPC_THREADVARTABLES:
.long 3
.long THREADVARLIST_SYSTEM
.long THREADVARLIST_OBJPAS
.long THREADVARLIST_P$TKES2
.Le5:
.size FPC_THREADVARTABLES, .Le5 - FPC_THREADVARTABLES .section .data
.balign 4
.globl FPC_RESOURCESTRINGTABLES
.type FPC_RESOURCESTRINGTABLES,@object
FPC_RESOURCESTRINGTABLES:
.long 0
.Le6:
.size FPC_RESOURCESTRINGTABLES, .Le6 - FPC_RESOURCESTRINGTABLES

.section .fpc
.balign 4
.ascii "FPC 2.2.0 [2008/11/09] for i386 - FreeBSD"

.section .data
.balign 4
.globl __stklen
.type __stklen,@object
__stklen:
.long 262144

.section .data
.balign 4
.globl __heapsize
.type __heapsize,@object
__heapsize:
.long 0

.section .data
.globl __fpc_valgrind
.type __fpc_valgrind,@object
__fpc_valgrind:
.byte 0
# End asmlist al_globals
# Begin asmlist al_const
# End asmlist al_const
# Begin asmlist al_typedconsts
# End asmlist al_typedconsts
# Begin asmlist al_rotypedconsts
# End asmlist al_rotypedconsts
# Begin asmlist al_threadvars
# End asmlist al_threadvars
# Begin asmlist al_imports
# End asmlist al_imports
# Begin asmlist al_exports
# End asmlist al_exports
# Begin asmlist al_resources
# End asmlist al_resources
# Begin asmlist al_rtti
# End asmlist al_rtti
# Begin asmlist al_dwarf
# End asmlist al_dwarf
# Begin asmlist al_dwarf_info
# End asmlist al_dwarf_info
# Begin asmlist al_dwarf_abbrev
# End asmlist al_dwarf_abbrev
# Begin asmlist al_dwarf_line
# End asmlist al_dwarf_line
# Begin asmlist al_picdata
# End asmlist al_picdata
# Begin asmlist al_resourcestrings
# End asmlist al_resourcestrings
# Begin asmlist al_end
# End asmlist al_end

Hm, the function name is there, both show it as text section entry (fntest and _somefn), looks okay to me.

Another test could be to make a short testing program (maybe in C) that loads your library and calls the function. If that works, the calling statement from SQL is not correct or loading fails.

HTH anyhow,
Marc

Another observation:

In any case you get the error message:

function FNTEST2 is not defined module name or entrypoint could not be found

If the function name is there and written correctly, make sure the module (= your library) is found. I'm not used to making UDFs, but somehow the search path and maybe the libraries found there can be listed similar to using "ldconfig -r" but for the firebird stuff.

Marc

Здравствуйте, Marc.

Вы писали 12 ноября 2008 г., 22:13:32:

MS> Another observation:

MS> In any case you get the error message:

> function FNTEST2 is not defined > module name or entrypoint could not be found

MS> If the function name is there and written correctly, make sure the MS> module (= your library) is found. I'm not used to making UDFs, but MS> somehow the search path and maybe the libraries found there can be MS> listed similar to using "ldconfig -r" but for the firebird stuff.

MS> Marc

"C" programm 'testudf.c' I have compiled with gcc works fine. Firebird see it and I can call 'fntest' function

When I compile my 'tkes.pp'. Firebird do not found function I need.

In both cases (C, FPC) libs are located in
/usr/local/libexec/firebird/udf directory and have same premissions

also I have tryed to test my libtkes2.so.

I write test.pp
{$linklib libtkes2.so}
function somefn(): integer; stdcall; external 'libtkes2' name 'somefn';
begin
  Writeln( somefn() );
end.

in this case dynamic library are located and somefn is called

This seems that Firebird does not understand .so module compiled by FPC

also I have tryed this:
fpc -Cn tkes2.pp
gcc tkes2.o -o libtkes2.so -shared
in this case Firebird also does not see somefn:
DETAILS:
libtkes2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped U FINALIZE$_OBJPAS
U FPC_INITIALIZEUNITS
000019ac D FPC_RESOURCESTRINGTABLES
0000199c D FPC_THREADVARTABLES
U INIT$_OBJPAS
U INIT$_SYSTEM
00001984 D INITFINAL
00000860 T P$TKES2_SOMEFN$$LONGINT
00000874 T P$TKES2_main
00000874 T PASCALMAIN
U THREADVARLIST_OBJPAS
00001980 D THREADVARLIST_P$TKES2
U THREADVARLIST_SYSTEM
000019f0 A _DYNAMIC
00001acc A _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
00001abc d __CTOR_END__
00001ab8 d __CTOR_LIST__
00001ac4 d __DTOR_END__
00001ac0 d __DTOR_LIST__
000019ec r __FRAME_END__
00001ac8 d __JCR_END__
00001ac8 d __JCR_LIST__
00001ae4 A __bss_start
w __cxa_finalize@@FBSD_1.0
00000890 t __do_global_ctors_aux
000007c0 t __do_global_dtors_aux
00001970 d __dso_handle
000019b8 D __fpc_valgrind
000019b4 D __heapsize
00000857 t __i686.get_pc_thunk.bx
000019b0 D __stklen
00001ae4 A _edata
00001b00 A _end
000008c4 T _fini
00000788 T _init
00000880 T _somefn
00001af0 b completed.4685
00000820 t frame_dummy
00001974 d p.4683
00000860 T somefn

Will stdcall default to cdecl?

Then I'd say the fault is clearly on the firebird side.

One last thing I'd try is to use another name (like with ld: using -lmine is searching for "libmine.so", not only "mine.so"), if that fails, too, it time for one of fpc's developers to comment or the firebird people to investigate.

Marc

Здравствуйте, Marc.

Вы писали 12 ноября 2008 г., 23:12:43:

MS> Am Mittwoch, den 12.11.2008, 22:55 +0200 schrieb KES:

MS> Will stdcall default to cdecl?

I have tryied as sdecl as stdcall, results are same =(

MS> Then I'd say the fault is clearly on the firebird side.

MS> One last thing I'd try is to use another name (like with ld: using MS> -lmine is searching for "libmine.so", not only "mine.so"), if that MS> fails, too, it time for one of fpc's developers to comment or the MS> firebird people to investigate.

what do you mean?

MS> Marc

KES wrote

Здравствуйте, Marc. Вы писали 12 ноября 2008 г., 23:12:43:

Try to give your library another name, preferably not having the string "lib" in it. If the linker gets called it searches "libm" for a request to link to "m". But I do not think that'll help ...

Better would be to push the verbosity of firebirds error messages up (-vv or something like that) and investigate why it does not find the lib.

Best tools for this job are syscall loggers like ktrace/strace/truss/... (look in the ports tree), chances are good to find the problem in their logging output.

Marc

Здравствуйте, Marc.

Вы писали 13 ноября 2008 г., 21:43:38:

MS> Am Donnerstag, den 13.11.2008, 18:59 +0200 schrieb KES:

> Здравствуйте, Marc. > > Вы писали 12 ноября 2008 г., 23:12:43:

MS> Try to give your library another name, preferably not having the string MS> "lib" in it. If the linker gets called it searches "libm" for a request MS> to link to "m". But I do not think that'll help ...

MS> Better would be to push the verbosity of firebirds error messages up MS> (-vv or something like that) and investigate why it does not find the MS> lib.

MS> Best tools for this job are syscall loggers like ktrace/strace/truss/... MS> (look in the ports tree), chances are good to find the problem in their MS> logging output.

MS> Marc

Log file of linking:

[0.104] procedure/function somefn:LongInt;CDecl
[0.105] unit TKES can't be shared linked, switching to static linking [0.105] Searching file tkes.o... found
[0.105] unit SYSTEM can't be shared linked, switching to static linking [0.105] Searching file /usr/local/lib/fpc/2.2.0/units/i386-freebsd/rtl/system.o... found [0.116] unit OBJPAS can't be shared linked, switching to static linking [0.116] Searching file /usr/local/lib/fpc/2.2.0/units/i386-freebsd/rtl/objpas.o... found [0.116] Linking libtkes.so

Why FPC can not link TKES as shared?

Здравствуйте, Marc.

Вы писали 13 ноября 2008 г., 21:43:38:

MS> Am Donnerstag, den 13.11.2008, 18:59 +0200 schrieb KES:

> Здравствуйте, Marc. > > Вы писали 12 ноября 2008 г., 23:12:43:

MS> Try to give your library another name, preferably not having the string MS> "lib" in it. If the linker gets called it searches "libm" for a request MS> to link to "m". But I do not think that'll help ...

MS> Better would be to push the verbosity of firebirds error messages up MS> (-vv or something like that) and investigate why it does not find the MS> lib.

MS> Best tools for this job are syscall loggers like ktrace/strace/truss/... MS> (look in the ports tree), chances are good to find the problem in their MS> logging output.

MS> Marc

MS> _______________________________________________ MS> fpc-pascal maillist -
MS> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

I have tryied my example to compile in Delphi. Then I use DLL in FireBird on Win32. All works fine. So my source file is good and therefore FreePascal can not compile shared library that can be recognized by FireBird (((

Is there work arounds?

Did you specify cdecl as the calling convention for non-windows ? If it works on windows, it almost surely does not work straight out of the box on unices, because the calling convention will be wrong.

Michael.

Здравствуйте, Michael.

Вы писали 15 ноября 2008 г., 0:10:13:

MVC> Did you specify cdecl as the calling convention for non-windows ? MVC> If it works on windows, it almost surely does not work straight out MVC> of the box on unices, because the calling convention will be wrong.

MVC> Michael.

This is last my try:

library MyUDF;
function somefn: integer; cdecl; export;
begin
 somefn:= 3;
end;
exports
 somefn name '_somefn';
end.

On win32 it works, on FreeBSD does not

KES wrote

Здравствуйте, Michael.

Zdravstvuyte...

I compiled the library, and checked the contents:

home: >objdump -t libmyudf.so

00004a20 g F .text 00000005 _somefn

So the symbol is present, as you declared it in your library. That part seems OK.

How do you declare your function in Firebird ?
Does it have the _ ?
and the correct casing ?

Michael.

Здравствуйте, Michael.

Вы писали 15 ноября 2008 г., 2:52:48:

KES wrote

> Здравствуйте, Michael.

MVC> Zdravstvuyte...

MVC> I compiled the library, and checked the contents:

home: >>objdump -t libmyudf.so

MVC> 00004a20 g F .text 00000005 _somefn

MVC> So the symbol is present, as you declared it in your library. MVC> That part seems OK.

MVC> How do you declare your function in Firebird ? MVC> Does it have the _ ?
MVC> and the correct casing ?

MVC> Michael.

I have tryied with and without _

DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER
ENTRY_POINT 'somefn'
MODULE_NAME 'myudf'

DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER
ENTRY_POINT '_somefn'
MODULE_NAME 'myudf'

The Firebird message gives two possible causes:
module name OR entry point not found

In your case, it could be that it is the module itself which cannot be located. I noticed you copy tkes2 to the udf folder while you tell firebird the module name is libtkes2.

NB: This does not explain the ls -l which shows libtkes2 entries, unless these are old entries

HTH

Did you try changing the name myudf to libmyudf.so or libmyudf ? I don't think that the 'lib' is prefixed automatically.

Michael.

Здравствуйте, Stephano.

Вы писали 15 ноября 2008 г., 9:52:09:

S> The Firebird message gives two possible causes: S> module name OR entry point not found

S> In your case, it could be that it is the module itself which cannot be S> located. I noticed you copy tkes2 to the udf folder while you tell S> firebird the module name is libtkes2.

I have tryied both libtkes2 and tkes2 as Marc Santhoff adviced on 13 November

S> NB: This does not explain the ls -l which shows libtkes2 entries, unless S> these are old entries

This I have wrote 12 November:

Здравствуйте, Michael.

Вы писали 15 ноября 2008 г., 12:23:55:

MVC> Did you try changing the name myudf to libmyudf.so or libmyudf ? MVC> I don't think that the 'lib' is prefixed automatically.

MVC> Michael.

Yes I did, Marc Santhoff advice me this on 13 Novemter

Is the above used in a script? If yes, then it is linking into libtkes2.so, but copying to the udf directory tkes2.so (which might not even exist).

Здравствуйте

Lets try all from beginning

1. Test how firebird recognize libxxx and xxx and xxx.so libraries (because of C variant of UDF works I will try gcc)

a) source file:
extern int c_test();

int c_test()
{
return 8;
}

Здравствуйте

Lets try all from beginning

1. Test how firebird recognize libxxx and xxx and xxx.so libraries (because of C variant of UDF works I will try gcc)

a) source file:
extern int c_test();

int c_test()
{
return 8;
}

b) home# gcc -c testudf.c
c) home# gcc testudf.o -o testudf.so -shared
d) home# nm testudf.so
00001630 A _DYNAMIC
00001704 A _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
000016f4 d __CTOR_END__
000016f0 d __CTOR_LIST__
000016fc d __DTOR_END__
000016f8 d __DTOR_LIST__
0000162c r __FRAME_END__
00001700 d __JCR_END__
00001700 d __JCR_LIST__
0000171c A __bss_start
w __cxa_finalize@@FBSD_1.0
00000550 t __do_global_ctors_aux
000004a0 t __do_global_dtors_aux
00001624 d __dso_handle
00000537 t __i686.get_pc_thunk.bx
0000171c A _edata
00001720 A _end
00000584 T _fini
0000046c T _init
00000540 T c_test
0000171c b completed.4685
00000500 t frame_dummy
00001628 d p.4683

e) ls -l
-rwxr-xr-x 1 root wheel 4520 15 ноя 21:29 testudf.so f) cp testudf.so /usr/local/libexec/firebird/udf
g) Because of FireBird is started from inetd:
home# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.
h)
DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER BY VALUE
ENTRY_POINT 'c_test'
MODULE_NAME 'testudf'
i) select fntest() from rdb$database
result 8

2. Now I test different names for UDF
a) home# cd /usr/local/libexec/firebird/udf
b) home# mv testudf.so libtestudf.so
c) home# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.

d) select fntest() from rdb$database
result 8

e) home# mv libtestudf.so testudf
f) home# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.

g) select fntest() from rdb$database
result 8

h) home# mv testudf libtestudf
i) home# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.

j) select fntest() from rdb$database
k) invalid requiest BLR at offset 60
function FNTEST is not defined
module name or entrypoint could not be found

So when I write:
... MODULE_NAME 'testudf'
firebird will see testudf.so/libtestudf.so/testudf and do not see libtestudf

PS.
#rm libtestudf
#cd to my directory with sources

3. Now I try to compile by FPC:
a) home# cat testudf.pp
library testudf;

function pp_test(): integer; cdecl; export;
begin
 pp_test:= 7;
end;
exports
 pp_test name 'pp_test2';
begin
end.

b) home# fpc testudf.pp
Target OS: FreeBSD/ELF for i386
Compiling testudf.pp
Linking libtestudf.so
11 lines compiled, 0.1 sec

c) nm libtestudf.so > libtestudf.txt see in attached file libtestudf.txt
d) home# cp libtestudf.so /usr/local/libexec/firebird/udf e) home# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.
f) Change definition in SQL. So now it looks like: DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER BY VALUE
ENTRY_POINT 'pp_test'
MODULE_NAME 'testudf'
g) select fntest() from rdb$database
h) invalid requiest BLR at offset 60
function FNTEST is not defined
module name or entrypoint could not be found

i) change definition in SQL. So now it looks like: DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER BY VALUE
ENTRY_POINT 'pp_test2'
MODULE_NAME 'testudf'
j) select fntest() from rdb$database
k) invalid requiest BLR at offset 60
function FNTEST is not defined
module name or entrypoint could not be found

4. Compiling with fpc -Xc
a) nm testudf.o
home# nm testudf.o
U FPC_INITIALIZEUNITS
00000020 D FPC_RESOURCESTRINGTABLES
00000014 D FPC_THREADVARTABLES
U INIT$_SYSTEM
00000004 D INITFINAL
00000000 T P$TESTUDF_PP_TEST$$SMALLINT
00000014 T P$TESTUDF_main
00000014 T PASCALMAIN
00000000 D THREADVARLIST_P$TESTUDF
U THREADVARLIST_SYSTEM
0000002c D __fpc_valgrind
00000028 D __heapsize
00000024 D __stklen
00000000 T pp_test
00000020 T pp_test2

b) home# cp libtestudf.so /usr/local/libexec/firebird/udf c) home# /etc/rc.d/inetd restart
Stopping inetd.
Starting inetd.
d) DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER BY VALUE
ENTRY_POINT 'pp_test2'
MODULE_NAME 'testudf'
e) select fntest() from rdb$database
f) invalid requiest BLR at offset 60
function FNTEST is not defined
module name or entrypoint could not be found

g) DECLARE EXTERNAL FUNCTION FNTEST
RETURNS INTEGER BY VALUE
ENTRY_POINT 'pp_test'
MODULE_NAME 'testudf'
h) select fntest() from rdb$database
i) invalid requiest BLR at offset 60
function FNTEST is not defined
module name or entrypoint could not be found

CONCLUSION: FPC generate wrong object file???

Not necessarily. Please try to load the library from a plain C program.

My guess is that dlopen() will return an error.

Then do the same for the library with a pascal program.

Michael.

Здравствуйте, Michael.

Вы писали 15 ноября 2008 г., 23:28:10:

MVC> Not necessarily. Please try to load the library from a plain C program.

MVC> My guess is that dlopen() will return an error.

MVC> Then do the same for the library with a pascal program.

MVC> Michael.

I do not know how to load the library from a plain C program. Can you help me?

Something like this should do it:

home: >cat testl.c
#include <dlfcn.h>
#include <stdio.h>
int main () {
  void * p;
  void * ps;
  p=dlopen("testudf.so",RTLD_NOW);
  if (p==NULL) {
    printf("loading library failed %s\n",dlerror());
  } else {
    printf("loading library OK\n");
    ps = dlsym(p,"fn_test");
    if (ps==NULL) {
      printf("symbol not found\n");
    } else {
      printf("Symbol found OK\n");
    }
   dlclose(p);
  }
}

home: >gcc -ldl testl.c
home: >./a.out
loading library failed testudf.so: cannot open shared object file: No such file or directory

Of course, you must correct the names.

Michael.

In our previous episode, Michael Van Canneyt said:

home: >gcc -ldl testl.c home: >./a.out loading library failed testudf.so: cannot open shared object file: No such file or directory

(skip the -ldl, it is a linuxism)

Здравствуйте, Michael.

Вы писали 16 ноября 2008 г., 0:29:22:

MVC> Something like this should do it:

home: >>cat testl.c
MVC> #include <dlfcn.h>
MVC> #include <stdio.h>
MVC> int main () {
MVC> void * p;
MVC> void * ps;
MVC> p=dlopen("testudf.so",RTLD_NOW);
MVC> if (p==NULL) {
MVC> printf("loading library failed %s\n",dlerror()); MVC> } else {
MVC> printf("loading library OK\n");
MVC> ps = dlsym(p,"fn_test");
MVC> if (ps==NULL) {
MVC> printf("symbol not found\n");
MVC> } else {
MVC> printf("Symbol found OK\n");
MVC> }
MVC> dlclose(p);
MVC> }
MVC> }

home: >>gcc -ldl testl.c
home: >>./a.out
MVC> loading library failed testudf.so: cannot open shared object file: No such file or directory

MVC> Of course, you must correct the names.

MVC> Michael.

home# ./a.out
loading library failed /usr/lib/libtestudf.so: Undefined symbol "main"

in output of nm libtetudf.so
I have noticed this:
0001d950 t gcc2_compiled.
U main
00039758 B operatingsystem_parameter_argc
"U main" what this mean??

Now I try your example for .so compiled by gcc
home# gcc -c testudf.c
home# gcc testudf.o -o testudf.so -shared
home# gcc so_load.c
The so_load.c file is test1.c
home# ./a.out
loading library failed Shared object "testudf.so" not found, required by "a.out" home# cp testudf.so /usr/lib
home# ./a.out
loading library OK
Symbol found OK
home#

Any suggestions?

Здравствуйте, KES.

Вы писали 16 ноября 2008 г., 22:25:39:

K> Здравствуйте, Michael.

K> Вы писали 16 ноября 2008 г., 0:29:22:

MVC>> Something like this should do it:

home: >>>cat testl.c
MVC>> #include <dlfcn.h>
MVC>> #include <stdio.h>
MVC>> int main () {
MVC>> void * p;
MVC>> void * ps;
MVC>> p=dlopen("testudf.so",RTLD_NOW);
MVC>> if (p==NULL) {
MVC>> printf("loading library failed %s\n",dlerror()); MVC>> } else {
MVC>> printf("loading library OK\n");
MVC>> ps = dlsym(p,"fn_test");
MVC>> if (ps==NULL) {
MVC>> printf("symbol not found\n");
MVC>> } else {
MVC>> printf("Symbol found OK\n");
MVC>> }
MVC>> dlclose(p);
MVC>> }
MVC>> }

home: >>>gcc -ldl testl.c
home: >>>./a.out
MVC>> loading library failed testudf.so: cannot open shared object file: No such file or directory

MVC>> Of course, you must correct the names.

MVC>> Michael.

K> home# ./a.out
K> loading library failed /usr/lib/libtestudf.so: Undefined symbol "main"

K> in output of nm libtetudf.so
K> I have noticed this:
K> 0001d950 t gcc2_compiled.
K> U main
K> 00039758 B operatingsystem_parameter_argc
K> "U main" what this mean??

K> Now I try your example for .so compiled by gcc
K> home# gcc -c testudf.c
K> home# gcc testudf.o -o testudf.so -shared
K> home# gcc so_load.c
K> The so_load.c file is test1.c
K> home# ./a.out
K> loading library failed Shared object "testudf.so" not found, required by "a.out" K> home# cp testudf.so /usr/lib
K> home# ./a.out
K> loading library OK
K> Symbol found OK
K> home#

K> Any suggestions?

some additional tests:

home# fpc -Cn testudf.pp
Target OS: FreeBSD/ELF for i386
Compiling testudf.pp
Closing script ppas.sh
11 lines compiled, 0.1 sec
home# gcc testudf.o -o libtestudf.so -shared
home# cp libtestudf.so /usr/lib
home# gcc so_load.c
home# ./a.out
loading library failed /usr/lib/libtestudf.so: Undefined symbol "FPC_INITIALIZEUNITS"

In first case it does not found "main" in seconde FPC_INITIALIZEUNITS

Maybe I need some options?

Apparently, the FPC library startup code expects there to be a "main" symbol, (normally the main program entry point) and it isn't there in FreeBSD.

That is why the library cannot be loaded. I don't know how to solve this, I expect Marco Van de Voort or Ales Katona to be able to answer that.

Michael.

Здравствуйте, Michael.

Вы писали 17 ноября 2008 г., 12:01:39:

MVC> Apparently, the FPC library startup code expects there to be a "main" symbol, MVC> (normally the main program entry point) and it isn't there in FreeBSD.

MVC> That is why the library cannot be loaded. I don't know how to solve this, MVC> I expect Marco Van de Voort or Ales Katona to be able to answer that.

for example in C shared library there is no 'main' entry point: testudf.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripp 00001630 A _DYNAMIC
00001704 A _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
000016f4 d __CTOR_END__
000016f0 d __CTOR_LIST__
000016fc d __DTOR_END__
000016f8 d __DTOR_LIST__
0000162c r __FRAME_END__
00001700 d __JCR_END__
00001700 d __JCR_LIST__
0000171c A __bss_start
w __cxa_finalize@@FBSD_1.0
00000550 t __do_global_ctors_aux
000004a0 t __do_global_dtors_aux
00001624 d __dso_handle
00000537 t __i686.get_pc_thunk.bx
0000171c A _edata
00001720 A _end
00000584 T _fini
0000046c T _init
00000540 T c_test
0000171c b completed.4685
00000500 t frame_dummy
00001628 d p.4683

I think FPC must not expect 'main' entry point

KES wrote

I think FPC must not expect 'main' entry point

The "main" of an FPC shared library contains the code to run the initialisation routines of all units used by the library. The label of this code is however not called "main" (I can't remember that it ever was), and the FreeBSD startup code for is indeed wrong in calling it.

For the FreeBSD maintainers: I guess you should use similar init/fini code as what is used for Linux (compiler/t_linux.pas, search for initname).

Jonas

Здравствуйте, Jonas.

Вы писали 21 ноября 2008 г., 19:19:33:

KES wrote

> I think FPC must not expect 'main' entry point

JM> The "main" of an FPC shared library contains the code to run the JM> initialisation routines of all units used by the library. The label of JM> this code is however not called "main" (I can't remember that it ever JM> was), and the FreeBSD startup code for is indeed wrong in calling it.

JM> For the FreeBSD maintainers: I guess you should use similar init/fini JM> code as what is used for Linux (compiler/t_linux.pas, search for JM> initname).

fpc -Ss does not help ((

That switch is unrelated, it's about parsing TP-style object constructors and destructors.

The problem you have needs to be fixed in the compiler, you cannot change this behaviour using a command line switch. As far as I can tell, the problem is simply that nobody ever added support for shared libraries under FreeBSD. There is no startup code for them in the run time library, and no special case for them in the target-specific files of the compiler.

The reason you get that error, is because it always uses the startup code for programs (and those do always have a main function).

Jonas