Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-12

Dynlibs.LoadLibrary on 64bit Debian (Ubuntu)

11 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrew Brunner

I'm running into another issue where I create all classes from scratch to avoid using Classes unit inside library and now my library won't load. The only FPC related unit I use is SysUtils.

If I strip out my all my units as uses then the Application LoadLibrary will return a handle.

I tried to use DGB and backtrace right after the call to LoadLibrary but it got nothing. I use Lazarus to build my projects and the compiler options for extra Debug Info is set for both SO and App.

I want to write a bunch of libraries this Holiday break. And I don't see how I can get these working if something as simple as LoadLibrary won't work. Is there a GetLastError that Linux stores that I can read and determine what's going wrong? What are my options? Are there any tricks to get this to work?

Thanks for any feedback.

Reply by email

Jonas Maebe
to Andrew Brunner
Andrew Brunner wrote
'm running into another issue where I create all classes from scratch to avoid using Classes unit inside library and now my library won't load. The only FPC related unit I use is SysUtils.

I cannot reproduce this crash following http://bugs.freepascal.org/view.php?id=12814

I completed the main program (please always submit fully compilable code, not just snippets) as follows:

{$mode delphi}
uses
   dynlibs;
procedure Test();
var
   FLib : TLibHandle;
begin
   FLib:=Dynlibs.LoadLibrary('./libMatrixMemoryManager.so');
   DynLibs.UnloadLibrary(FLib); // WILL CRASH HERE.
end;
begin
   test;
end.

Note that I replaced "MatrixMemoryManager.so" with "libMatrixMemoryManager.so". I get a crash if loadlibrary fails and returned 0. You should check for this condition in your code. Other than that, it works fine:

~/fpc/test/tw12814$ ppcxf1 -l MatrixMemoryManager.pp
Free Pascal Compiler version 2.2.3 [2008/12/17] for x86_64
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling MatrixMemoryManager.pp
Linking libMatrixMemoryManager.so
18 lines compiled, 0.4 sec
~/fpc/test/tw12814$ ppcxf1 -l tt.pp
Free Pascal Compiler version 2.2.3 [2008/12/17] for x86_64
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling tt.pp
Linking tt
15 lines compiled, 0.2 sec
~/fpc/test/tw12814$ ./tt
~/fpc/test/tw12814$ echo $?
0
~/fpc/test/tw12814$ cat MatrixMemoryManager.pp
library MatrixMemoryManager;
{$mode objfpc}{$H+}
  uses cMem,SysUtils,Classes;
var
   List:TList;
   function Startup:boolean; stdcall; export;
   begin
     List:=TList.Create;
     Result:=True;
   end;
   function Shutdown:boolean; stdcall; export;
   begin
     FreeAndNil(List);
     Result:=True;
   end;
   exports Startup, Shutdown;
begin
end.

This is on Scientific Linux 5.2 (free distro based on Red Hat Enterprise Linux 5.2). Are you sure that you are using 2.2.3 and not 2.3.1?

Jonas

Reply by email

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote 7 lines
On 23 Dec 2008, at 14:54, Andrew Brunner wrote: > 'm running into another issue where I create all classes from scratch > to avoid using Classes unit inside library and now my library won't > load. The only FPC related unit I use is SysUtils. I cannot reproduce this crash following http://bugs.freepascal.org/view.php?id=12814

BTW: the binutils in Ubuntu 8.10 appear to be buggy: http://bugs.freepascal.org/view.php?id=12832 . Maybe in your case ld is not crashing, but simply generating wrong code. If you are using Ubuntu 8.10, you may want to downgrade your binutils just like the person who reported the referenced bug.

Jonas

Reply by email

Jonas Maebe
to Andrew Brunner
Andrew Brunner wrote 5 lines
> This is on Scientific Linux 5.2 (free distro based on Red Hat > Enterprise > Linux 5.2). Are you sure that you are using 2.2.3 and not 2.3.1? Yes, I did use build 2.3.1 from SVN.

Your bug report indicates version "2.2.3" in the details view.

I'll try 2.2.3 build b/c I'm having so many different Issues with this one and re-post back.

2.2.x is the fixes branch, 2.3.x is trunk. It is unadvisable to use trunk unless you really want to be bleeding edge (with the emphasis on "bleeding" in case of dynamic libraries on linux/x86_64)

Jonas

Reply by email

Andrew Brunner
to Andrew Brunner: Yes, I did use build 2.3.1 from SVN. I'll try 2.2.3 build b/c I'm having so many…

I just installed fpc 2.2.3 and updated my links and re-built the so and test app. And still had a problem with LoadLibrary returning 0.

So I went and downloaded the latest version of binutils (2.19) and compiled it.

Next, I rebuilt-Lazarus.

Then, I re opened the existing projects and built-all and still... loadlibrary returned 0.

Next, I created a brand new Library Project and it worked perfectly with the Classes and other things.

So, I'm up and running with an entirely different problem. The 2.2.3 (2.2.2 fixes) edition seems to have a problem with arrays... I've got a memory map of pointers based on the current processID.

TMemoryMap=Array[THandle] of Pointer. This does work on Delphi. But it does not work on FPC.

Andrew Brunner wrote 8 lines
> This is on Scientific Linux 5.2 (free distro based on Red Hat Enterprise > Linux 5.2). Are you sure that you are using 2.2.3 and not 2.3.1? Hi Jonas, Yes, I did use build 2.3.1 from SVN. I'll try 2.2.3 build b/c I'm having so many different Issues with this one and re-post back.

Reply by email

Andrew Brunner
to Jonas Maebe: Your bug report indicates version "2.2.3" in the details view. 2.2.x is the fixes branch,…
Jonas Maebe wrote
Your bug report indicates version "2.2.3" in the details view.

I noticed that. I don't recall paying much attention to the version or perhaps it wasn't available in the combobox.
It was listed in the more detailed version.

2.2.x is the fixes branch, 2.3.x is trunk. It is unadvisable to use trunk unless you really want to be bleeding edge (with the emphasis on "bleeding" in case of dynamic libraries on linux/x86_64)

I had explored the SVN today using a browser... I checked out a number of revisions. 2.2.2 and fixes. I'm assuming fixes is an entire distribution of FPC although I did a 2.2.2 install and then did a fixes2.2.2 install. I had to go down from 2.3.1 so some symbolic links and Lazarus had to be tweaked.

But thanks for that hint on the Ubuntu problem.

Reply by email

Andrew Brunner
to Andrew Brunner

I've been struggling with an issue of
Dynlibs.LoadLibrary(completepath/something.so) always returning zero for libraries in subfolders that are traced back to samba shares.

Example Library Project is built on

/home/atbrunner/Source/Libraries/Test/project1.so

but /home/atbrunner/Source is a smbfs mount in fstab pointing to \\fileserver\raid\developer\source\lazarus\ share on my network.

So what's with Dynlibs or Linux for that matter, not able to load libraries from sub folders inside mounts? Is *this a known issue?

If I copy the project1.so into my home folder, update the Application to load the lib from that path, all is good. Any ideas? Is there a config setting for binutils to "resolve" mounts?

I want to close out this issue and report in bug track what's up with the entire matter...

Reply by email

Jonas Maebe
to Andrew Brunner
Andrew Brunner wrote
So what's with Dynlibs or Linux for that matter, not able to load libraries from sub folders inside mounts? Is *this a known issue?

No, but "sub folders inside mounts" has no meaning under unix (every folder on your disk is a "sub folder inside a mount").

If I copy the project1.so into my home folder, update the Application to load the lib from that path, all is good. Any ideas? Is there a config setting for binutils to "resolve" mounts?

dlopen() (which is what dynlibs calls under unix) is unrelated to binutils (it's part of glibc). mounts do not need resolving. Everything is a "mount" under unix (even the root directory).

I want to close out this issue and report in bug track what's up with the entire matter...

What you can do is call dlerror when you get 0 back from loadlibrary, as follows:

function dlerror: pchar; cdecl; external;

...

if dynlibs.loadlibrary(...) = 0 then
   writeln(dlerror);

Maybe it will tell you something more.

Jonas

Reply by email

Joost van der Sluis
to Andrew Brunner: I've been struggling with an issue of Dynlibs.LoadLibrary(completepath/something.so)…

Op woensdag 24-12-2008 om 13:42 uur [tijdzone -0600], schreef Andrew Brunner:

I've been struggling with an issue of Dynlibs.LoadLibrary(completepath/something.so) always returning zero for libraries in subfolders that are traced back to samba shares.

This sounds as if you have SE linux enabled and the option set to disallow execution from files from samba-shares.

Try is 'setenforce off' solves the problem.

Joost.

Reply by email

Andrew Brunner
to Joost van der Sluis

Hi Joost,

The the problem was a Linux problem. I'm running debian, Ubuntu 8.10, but the problem was with the entries in FSTab not having the propper case for the remote shares. I matched the cases in the complete paths (server side) and Rebooted. Now at least I could test for crashes.

Unfortunately, I had already upgraded my binutils before I could test so I need to re-install from scratch to revert back to my old bin utils?

I don't have issues with loading/unloading at the present.

Joost van der Sluis wrote 17 lines
Op woensdag 24-12-2008 om 13:42 uur [tijdzone -0600], schreef Andrew Brunner: > I've been struggling with an issue of > Dynlibs.LoadLibrary(completepath/something.so) always returning zero > for libraries in subfolders that are traced back to samba shares. This sounds as if you have SE linux enabled and the option set to disallow execution from files from samba-shares. Try is 'setenforce off' solves the problem. Joost. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply by email