View Issue Details

IDProjectCategoryView StatusLast Update
0036198FPCInstallerpublic2019-10-21 08:08
ReporterPhilipAssigned ToJonas Maebe 
Status resolvedResolutionfixed 
Product Version3.0.4Product 
Target VersionFixed in Version3.3.1 
Summary0036198: Binary installer from sourceforge will not link again libX11 for 64 bit Mac OS programs.
DescriptionI have tried multiple clean installs of multiple versions of Mac OS and XCode, as well as multiple versions of XQuartz.
In each case when compiling fpGUI apps I encounter
Linking project1
ld: library not found for -lX11
I was careful to specify -Fl/usr/X11/lib or -Fl/opt/X11/lib as appropriate.
I also tried compiling in Lazarus.
I found that compiling 32 bit apps is file, but 64 bit will not work.

Finally I did a clean install and this time installed fpc using fink instead of the sourceforge installer.

Code now works perfectly.

For reference this is the complete working process That I followed using the fink method:-

 Clean install Mac OS 10.13.3 from memory stick

Update to 10.13.6

Install xquartx-2.7.11

Install xcode 10.1
    expand xcode.xip
    drag to Applications
    From terminal:-
    xcode-select --install

    Follow this instructions:-
    Download and install jdk-8u231-macosx-x64.dmg from Oracle
Note that I installed to /opt/sw instead of /sw because /sw won't work in future versions on Mac OS.


From terminal:-
fink install fpc
fink install fpc-source
mkdir ~/Programming
cd ~/Programming/
mkdir fpgui-develop
cd fpgui-develop/
git clone
cd fpGUI/src
cd ../examples/apps/docedit/
mkdir units
fpc @extrafpc.cfg docedit.lpr

The installer that causes the problem is this one

One person on the fpGUI support site suggested that it could be related to this report
but I have made no effort to look into that.

With the release of Catalina it is now vitally important 64 bit programs can be compiled.
Steps To ReproduceClean install of Mac OS (I use High Sierra but the same problem was observed on other versions)
install xquartz
install xcode
install command line tools for xcode
install from sourceforge
install fpgui:-
mkdir ~/Programming
cd ~/Programming/
mkdir fpgui-develop
cd fpgui-develop/
git clone
cd fpGUI/src
compile an fpgui X11 app:-
cd ../examples/apps/docedit/
mkdir units
fpc @extrafpc.cfg docedit.lpr
Additional Informationworks for 32 bit X11 apps, fails for 64 bit X11 apps
TagsNo tags attached.
Fixed in Revision43279
Attached Files


Jonas Maebe

2019-10-20 14:01

manager   ~0118726

Last edited: 2019-10-20 16:20

View 2 revisions

It's because if /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk exists when FPC is installed, the default configuration file contains the following fragment:

#ifndef cpui386
#ifndef cpupowerpc
#ifndef cpupowerpc64

This sets the "sysroot" for the linker to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk when compiling for x86-64. As a result, all -Fl parameters are also resolved relative to that directory. The X11 installer does not place its libraries there, which is why they are not found.

I'm actually not sure how this should be handled in a proper way. On the one hand, when specifying a sysroot libraries should be searched only in that sysroot to avoid accidentally linking wrong libraries (e.g. if you link against an OS X 10.8 SDK, you don't want to accidentally link against macOS 10.13-specific libraries because you're compiling on a macOS 10.13 system, and instead get an error that this library does not exist for OS X 10.8). On the other hand, I understand the desire to also specify library search directories that are not in the sysroot when compiling on the "native" system. I wonder how C toolchains handle this, or even Apple when compiling for a different SDK (at least back when they still supported linking against different SDKs).

It's worrying that it works when using fink, because that suggests it does not use fpmkcfg to generate the fpc.cfg configuration file (or maybe it never got updated to fpc 3.0.4a). This will cause other problems down the line.

Jonas Maebe

2019-10-20 16:33

manager   ~0118728

Ah, I've found this in the man page of GNU ld:
    If searchdir begins with =, then the = will be replaced by the sysroot prefix,
    a path specified when the linker is configured.
We can do the same (although our sysroot path is not hardcoded, but specified with the -XR parameter)

Jonas Maebe

2019-10-20 19:28

manager   ~0118733

I've adapted the compiler as described above: the sysroot will now be prepended to -Fl paths if they starts with "=" (and the "=" will then be removed, obviously).

Issue History

Date Modified Username Field Change
2019-10-20 12:47 Philip New Issue
2019-10-20 14:01 Jonas Maebe Note Added: 0118726
2019-10-20 16:20 Jonas Maebe Note Edited: 0118726 View Revisions
2019-10-20 16:33 Jonas Maebe Note Added: 0118728
2019-10-20 19:28 Jonas Maebe Assigned To => Jonas Maebe
2019-10-20 19:28 Jonas Maebe Status new => resolved
2019-10-20 19:28 Jonas Maebe Resolution open => fixed
2019-10-20 19:28 Jonas Maebe Fixed in Version => 3.3.1
2019-10-20 19:28 Jonas Maebe Fixed in Revision => 43279
2019-10-20 19:28 Jonas Maebe FPCTarget => -
2019-10-20 19:28 Jonas Maebe Note Added: 0118733