Dynamic Library from FPC Units
lazarus / 33-macOS - Mac OS X

----------------------------------------------------------------------
Kevan S. Hashemi · 2020-05-10 00:24

Dear FPC,

I posted this question earlier on the General Programming board, but
now see I should have posted it here. Apologies for duplication.

Can I use FPC to compile units or library files into a dynamic library
that I can then load into another program? (the other program is the
TclTk interpreter, or Wish.) When I apply FPC to a library file, I get
a file with unresolved symbols, and with "nm" I get this error:

/Library/Developer/CommandLineTools/usr/bin/nm: liblibtest.dylib
truncated or malformed object (no LC_ID_DYLIB load command in dynamic
library filetype)

In the Programmer's Manual, Chapter 12, it says FPC does not support
shared libraries on MacOS. Am I missing something simple?

Even if FPC won't make the dynamic library, I could use the "ld"
linker directly, but I can't find the FPC run-time library to link to.

Best, Kevan

----------------------------------------------------------------------
trev · 2020-05-10 04:49

Refer duplicated post discussion at
https://forum.lazarus.freepascal.org/index.php/topic,49733.0.html

----------------------------------------------------------------------
Jonas Maebe · 2020-05-10 09:31

Quote from: Kevan S. Hashemi on May 10, 2020, 02:24:31 amCan I use FPC
to compile units or library files into a dynamic library that I can
then load into another program? (the other program is the TclTk
interpreter, or Wish.) When I apply FPC to a library file, I get a
file with unresolved symbols, and with "nm" I get this error:

/Library/Developer/CommandLineTools/usr/bin/nm: liblibtest.dylib
truncated or malformed object (no LC_ID_DYLIB load command in dynamic
library filetype)

I've never seen this myself. Which version of macOS and Xcode command
line tools are you using? Also, how exactly are you compiling your
library? (provide all command line options you are using)

As to what it means, here's what the linker man page has to say about
that:

Quote     -install_name name
                 Sets an internal "install path" (LC_ID_DYLIB) in a
dynamic library. Any clients linked against the library will record
that path as the way dyld should locate
                 this library.  If this option is not specified, then
the -o path will be used.  This option is also called
-dylib_install_name for compatibility.

I.e., on Darwin the full path to where the library will eventually be
located can be written inside the library itself. When linking against
this library, the linker will then copy that path from the library
into the using library/executable, so that it will only allow to load
the library from that particular location. In particular, this avoids
the "DLL hell" issue from Windows where having multiple DLLs with the
same name can cause a program to load a wrong version and break. This
"full path" can also contain macros like @executable_path and the like
(see e.g. https://wincent.com/wiki/%40executable_path%2C_%40load_path_
and_%40rpath for an overview).

As mentioned in that man page fragment (from the Xcode 10.1 command
line tools), by default the linker should always add such a load
command, even if only the name of the library file itself. FPC does
not specify a custom -install_name parameter to the linker and afaik
there is even no way to tell the linker that it should not create a
LC_ID_DYLIB command, so the linker should always add the library name
by default. The only thing I can imagine is that you are perhaps using
an extremely old linker somehow. You can see the parameters FPC is
passing to linker by compiling with -Cn, and looking at the generated
ppas_link.sh file.

You can also pass custom parameters to the linker using FPC's -k
parameter, e.g. -k"-install_name @executable_path/../Frameworks/MyFram
ework.framework/Versions/A/MyFramework"

QuoteIn the Programmer's Manual, Chapter 12, it says FPC does not
support shared libraries on MacOS. Am I missing something simple?
That would be a reference to "classic" Mac OS, not to Mac OS X/OS
X/macOS. Apple seems to love creating naming confusion, although I
cannot find any reference to either "MacOS" or "Mac OS" in chapter 12
of the Programmer's Manual of FPC 3.0.4.

----------------------------------------------------------------------
Kevan S. Hashemi · 2020-05-10 12:10

Dear Jonas,

Thanks for your help. My problem turned out to be the Home Brew
installation of FPC. That version reported:

Free Pascal Compiler version 3.0.4 [2018/10/02] for x86_64

I uninstalled that version and switched to the 3.0.4 on the FPC
Download area, and now I get:

Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64

And this version produces dynamic libraries on MacOSX that work fine.
Thank you for pointing out the distinction between "MacOS" and
"MacOSX". I had forgotten about that.

Best, Kevan