Shared .so library with TRichMemo component

[Dibo]

Hi,

I can open LCL form in dll library on Windows, but I have a problem with .so library on Linux. When I put TRichMemo component on empty form and try to compile project I get this error:

/usr/bin/ld: /home/dibo/Programowanie/Lazarus/components/richmemo/lib/x86_64-linux/richmemo.o: relocation R_X86_64_32S against `TC_RICHMEMO_RTFLOADSTREAM' can not be used when making a shared object; recompile with -fPIC

/home/dibo/Programowanie/Lazarus/components/richmemo/lib/x86_64-linux/richmemo.o: could not read symbols: Bad value

Compiling with -fPIC switch doesn't help. Project with empty form is compiling without errors.

Ubuntu 10.4 64bit. Lazarus 0.9.29 from SVN revision 27282. FPC 2.5.1 from SVN revision 100908.

Regards.

[Dibo]

Is .so library only works if the host is also written in Lazarus? Because I have this very simple .so:

Code: Pascal  [Select][+][-]

1. library project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. {$R *.res}
6.  
7. function testresult: Integer; cdecl; export;
8. begin
9.   Result := 10;
10. end;
11.  
12. exports testresult;
13.  
14. begin
15. end.
16.  

And host in GCC (i don't know C++ so I found demo howto load library)

Code: C  [Select][+][-]

1. static void helloWorld (GtkWidget *wid, GtkWidget *win)
2. {
3.     void *handle;
4.     int (*cosine);
5.     char *error;
6.     int x;
7.     handle = dlopen ("/home/dibo/Programowanie/codeblocsk/test/Test/bin/Debug/libproject1.so", RTLD_LAZY);
8.     if (!handle) {
9.         fprintf (stderr, "%s\n", dlerror());
10.         exit(1);
11.     }
12.     dlerror();    /* Clear any existing error */
13.     cosine = dlsym(handle, "testresult");
14.     if ((error = dlerror()) != NULL)  {
15.         fprintf (stderr, "%s\n", error);
16.         exit(1);
17.     }
18.     x = (*cosine);
19.     printf ("%d\n", x);
20.     dlclose(handle);
21.     return 0;
22. }
23.  

It found .so and "testresult" function but this function result some -456766 value instead of 10

[JuhaManninen]

64-bit is the problem now. Pascal and C have different default sizes for integer types. C always uses the native register size, Pascal uses max 32 bits for Integer and Cardinal.
Solution: use PtrInt and PtrUInt instead. They match with C types.

There may be other potential problems with 64-bit. I only know this one.

Juha

[Dibo]

Hm, it's probably a different problem, because i create procedure in .so which create some text file. This work on host written in Lazarus. But on C++ and python doesn't work:

Code: Pascal  [Select][+][-]

1. library project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   Classes;
7.  
8. {$R *.res}
9.  
10. procedure CreateCustomFile; cdecl; export;
11. var
12.   s: TStringList;
13. begin
14.   s := TStringList.Create;
15.   try
16.     s.Add('sdfsdf');
17.     s.SaveToFile('/home/dibo/test.txt');
18.   finally
19.     s.Free;
20.   end;
21. end;
22.  
23. exports CreateCustomFile;
24.  
25. begin
26. end.
27.  

Code: Python  [Select][+][-]

1. import ctypes
2. libc = ctypes.cdll.LoadLibrary("/home/dibo/Programowanie/Lazarus/Projects/archiwum_r/test_dll/dcu/libproject1.so") # doctest: +LINUX
3. libc.CreateCustomFile
4.  

Python exit without error, so it seems that it found procedure and execute it but nothing happened.

[JuhaManninen]

Python exit without error, so it seems that it found procedure and execute it but nothing happened.

Have you tested with some similar shared library made with C, to isolate the problem?
I guess you have...
cdecl; export;  is somehow not enough. You should ask fpc-pascal mailing list for more advice.


Juha

[Dibo]

Python exit without error, so it seems that it found procedure and execute it but nothing happened.

Have you tested with some similar shared library made with C, to isolate the problem

Yes, I created test .so in GCC and it works in python and lazarus host.

[Dibo]

Ehhh, problem was that I call libc.CreateCustomFile instead of libc.CreateCustomFile() . From today, I love Pascal syntax more.

But I still have problem posted on first topic (when on form is TRichMemo).

[JuhaManninen]

You could ask also from lazarus mailing list if  TRichMemo has something preventing it to work from a shared lib. There may not be many people who know this and they maybe read the mailing list instead of forum.

Juha

[Dibo]

Ok. I do