View Issue Details

IDProjectCategoryView StatusLast Update
0007833FPCCompilerpublic2020-02-18 12:53
ReporterLars(L505) Assigned ToMarco van de Voort  
Status closedResolutionno change required 
Summary0007833: FreeBSD DSO Library - main undefined
DescriptionWhen using LoadLibrary on freebsd, nilhandle is returned even if the library exists. I checked with dlerror() using the dl.pp unit in uses clause and the error is:
  undefined symbol "main"

Temporary hack: define a procedure called main() in the library, export it - and the handle is no longer nilhandle.
Tagsdynamic library
Fixed in Revision
Attached Files


has duplicate 0015422 closedJonas Maebe Shared libraries problems on FreeBSD 


2006-11-17 11:25


prog.pas (201 bytes)


2006-11-17 11:29

reporter   ~0009826

Last edited: 2006-11-17 21:04

I suspect this also occurs on NetBSD, OpenBSD and other BSD operating systems, but I have just tried FreeBSD.

Also, once main() is exported, returning an integer from a simple function works okay.

function returnint: longint;
  result:= 5;

Standard out such as writeln() does not work from the library side.

2006-11-17 20:57


dyn.pas (223 bytes)

Jonas Maebe

2009-12-26 11:28

manager   ~0033324

See also the duplicate issue 0015422 for more information

Marco van de Voort

2009-12-27 22:02

manager   ~0033362

Last edited: 2009-12-27 22:07

Trial and error copying of Linux code is IMHo not the smart thing to do. It often causes little problems where details differ.

Focus should be in finding where in the (FreeBSD) source this is done. Either the object code that takes care of this in csu/libc or the relevant code in (?)


2009-12-28 04:06

reporter   ~0033365

Last edited: 2009-12-28 04:11

This copied part has nothing in common with the "main" function. As I said in 0015422, I copied just init function. Totally different problem and for it we don't need to find something in libc or Just to implement different prt for libraries as done in linux. And of course I do not recommend to blindly copy from linux source.

Btw, I don't think that 0015422 is duplicate. I just mentioned there, that problem with "main" is still not resolved and described one is completely different.

P.S. copied part is workaround not real solution too. But at least with those workarounds we can make software. In such cases it's better than nothing.

Graeme Geldenhuys

2013-05-31 11:46


Graeme Geldenhuys

2013-05-31 11:54

reporter   ~0067957

I've just tested with FPC 2.6.3 (r23886) under 64-bit FreeBSD 9.1 and dynamic linking of libraries work just fine. Attached is my test program.

Comments compared to original test program:
 - stdout does work from within the library
 - main() is not required in the library
 - loading, getting a proc address, calling the proc with parameters, retrieving
   the result etc all works in my test program.

I even used another program on SourceForge (DoubleCommander - a file manager). It is written for LCL and there release notes mentioned this bug. Yet when I compiled doublcmd now, I could load the dynamic libraries they complained about.

Seems somewhere along the lines the issue with FreeBSD was fixed, but this report was never updated.

What was strange though, is that the program using the library required the SysUtils unit otherwise at runtime nothing happened.

Here is the output of my test program:

[x86_64-freebsd]$ ./prog
libhan = 34366482432
Result (from within dll) = 6
p (in main program) = 6


Sergei Gorelkin

2013-06-01 11:34

developer   ~0067980

Last edited: 2013-06-01 11:39

View 2 revisions

It also needs testing on i386, because linking, both static and dynamic, is quite different between i386 and x86_64.

And preferably one needs to look at dynamic symbol table of the shared library and verify that it actually does not contain an unresolved 'main' symbol.

Graeme Geldenhuys

2013-06-01 21:52

reporter   ~0067989

OK, just tested under 32-bit FreeBSD 9.0 using FPC 2.6.2 release.
Compiling and linking of both *.pas files, from my test project, had no problems.

Running the 'prog' executable gave the wrong results (1 instead of 6), but then I noticed the following...

  TDLLTestProc = function(const x, y: integer): integer;

in the 'prog.pas' was defined without stdcall, like was done in the library. I added the ' stdcall;' at the end, recompiled prog.pas and ran it.

Now it produced the exact same result (excluding the libhan value of course). Dynamic loading of library, parameter handling, correct return result and stdout from the library works.

So it definitely works here on both 32-bit and 64-bit FreeBSD.

Marco van de Voort

2020-02-18 12:53

manager   ~0121159

I seemed to have missed Graeme's comment about stdcall earlier -> probably the cause -> resolved.

Issue History

Date Modified Username Field Change
2006-11-17 11:25 Lars(L505) New Issue
2006-11-17 11:25 Lars(L505) File Added: prog.pas
2006-11-17 11:29 Lars(L505) Note Added: 0009826
2006-11-17 11:33 Vincent Snijders FPCOldBugId => 0
2006-11-17 11:33 Vincent Snijders FPCTarget => -
2006-11-17 11:33 Vincent Snijders Summary reeBSD DSO Library - main undefined => FreeBSD DSO Library - main undefined
2006-11-17 20:57 Lars(L505) File Added: dyn.pas
2006-11-17 21:04 Lars(L505) Note Edited: 0009826
2006-11-17 21:04 Lars(L505) Note Edited: 0009826
2006-11-17 22:54 Florian Status new => assigned
2006-11-17 22:54 Florian Assigned To => Marco van de Voort
2009-01-08 11:57 Marco van de Voort Tag Attached: dynamic library
2009-12-26 11:28 Jonas Maebe Relationship added has duplicate 0015422
2009-12-26 11:28 Jonas Maebe Note Added: 0033324
2009-12-27 22:02 Marco van de Voort Note Added: 0033362
2009-12-27 22:07 Marco van de Voort Note Edited: 0033362
2009-12-28 04:06 kaukas Note Added: 0033365
2009-12-28 04:11 kaukas Note Edited: 0033365
2013-05-31 11:46 Graeme Geldenhuys File Added: freebsd_libraries.tar.gz
2013-05-31 11:54 Graeme Geldenhuys Note Added: 0067957
2013-06-01 11:34 Sergei Gorelkin Note Added: 0067980
2013-06-01 11:39 Sergei Gorelkin Note Edited: 0067980 View Revisions
2013-06-01 21:52 Graeme Geldenhuys Note Added: 0067989
2020-02-18 12:53 Marco van de Voort Status assigned => closed
2020-02-18 12:53 Marco van de Voort Resolution open => no change required
2020-02-18 12:53 Marco van de Voort Note Added: 0121159