Preparing FPC 3.2.4, point out road blocks now

[marcov]

The branch is frozen since last sunday, but a schedule hasn't been posted. Florian is the release manager, so best contact him for exceptions.

[zeljko]

MVC merged it

[dbannon]

Could this be addressed please ?

https://gitlab.com/freepascal.org/fpc/source/-/issues/40698

Its not important to most people but does need fixing and has no side effects. The package, libfontconfig, on unix, tries to open the "linker name" library rather than the soname one. While the linker name, if present, is usually a symlink to the soname, not always and most end users will almost certainly not have the linker name present even though they have the package, fontconfig, installed.

Installing the relevant -dev package is one way to create that symlink but end users should not be required to install a -dev package. The trap is that a developer, who will have the linker name symlink present, will test carefully and then send application to an end user. And the end user will complain it is broken !

Anton provided a patch but its very simple, Line 26 of packages/libfontconfig/src/libfontconfig.pp -

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

1.   DefaultLibName = 'libfontconfig.so';      // is currently
2.  
3.   DefaultLibName = 'libfontconfig.so.1';   // but should be like this !

Davo

edit: typo

[renabor]

Hi dbannon,
under linux the link to a library are provided by the .dev packges, so the symbolic link: libfontconfig.so will be created if you install the package:

Code: Bash  [Select][+][-]

1. sudo apt install libfontconfig-dev

hope it's helpful

[Fred vS]

Anton provided a patch but its very simple, Line 26 of packages/libfontconfig/src/libfontconfig.pp -

Hello Davo.

I am not sure libfontconfig.pp could help you for the dependency of libfontconfig.so.1.
 libfontconfig.pp is never used nor for Lazarus, nor for fpc source (appart packages/fcl-pdf).
And the loading of libfontconfig is dynamycally done with:

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

1. Function LoadFontConfigLib(Const ALibName : String; RaiseError : Boolean = true) : Integer;

where you may assign a custom library name.
But LoadFontConfigLib() is never called, nor in Lazarus source nor in fpc source.

There is only a example in fpcsrc/packages/libfontconfig/examples/testfc.pp, just change with this and it will work:

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

1. Writeln('Load 3: ',loadfontconfiglib('libfontconfig.so.1'));

Imho the dependency of libfontconfig.so is staticaly done at linking by /fpcsrc/packages/x11/src/fontconfig.pas.
(But statically link libfontconfig.so.1 is not permised by fpc, you know already this  )

Of couuuurse, I may be wrong or you are using libfontconfig.pp via the fcp-pdf package.

( MSEgui dont have that problem because it loads dynamically libfontconfig.so.1 if loading libfontconfig.so fails.  Ok,ok, I leave... )

Fre;D

[dbannon]

Yes Fred, renabor, perhaps my wording was unclear.

Fred As you note, the only time libfontconfig is used is in fcl-pdf. That is where I use it. Obscure but it is part of FPC.

When loading the library, fcl-pdf uses the "linker name", it should use the "so name".  The linker name is to be used when linking, not at run time.  The linker name, in most Linuxes (except Arch etc), is not available unless the -dev package is installed. But the "so name" is almost certainly pre-installed.

None developers should not be expected to have have -dev packages installed.

Yes Fred, as you mention, all it needs is to change the name in FPC source. I have changed it in my FPC, it works as expected and is well tested over many months. But in the official release (and main and fixes) of FPC, its not changed. And it is wrong.

renabor yes installing the -dev package hides the problem, but, as I noted, end users should no be required to use a -dev package. Further, relying on a -dev package at run time risks complications when new versions of the library are released. We make a distinction between "linker name" and "so name" for that reason.

I recently updated the version of my app in Debian, I have had to include the -dev version of both ssl and libfontconfig as dependencies because Debian only every uses the official release of FPC. And both are broken in FPC322. That is NOT a fix, its a "work-around".

The real risk, as I noted, is a developer (who is expected to have the -dev packages) builds and tests an app on his/her own machine and it all works as expected. Then send it to an end user who, quite probably has no reason to even know  -dev packages even exist.

Davo

[Fred vS]

Hello Davo.

Ha, ok, you use fcl-pdf so yes, Anton's patch is the simplest.
I too am obsessed with out-of-the-box for my users.

Fre;D

[Fred vS]

Re-hello.

Note that the patch:

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

1. DefaultLibName = 'libfontconfig.so.1'; // but it should be like this!

Is only OK for Linux operating system.

In other Unix operating systems, such as OpenBSD or NetBSD, libfontconfig.so.1 does not exist, nor libfontconfig.so but some like libfontconfig.so.13.1 for OpenBSD.
Additionally, the libfontconfig-dev package does not exist for these operating systems.

IMHO the best solution would be to have an array of DefaultLibName and try each one until one installed in the system is found. (Like MSEgui does).

[Thaddy]

Versioning on a lib is never a good idea. Drop that illusion. It works only for a short time.
Who is responsible for that?: libfontconfig.so.1
That is versioning (.1) and should not be in a release.
If done correctly the installer ( of libfontconfig.so.1 ) creates a symlink as libfontconfig.so (to libfontconfig.so.1)
If not, create the symlink ...
Versioning is not a good idea. I have seen that a bit too much lately.
So it // should NOT be like this...
That is the same as copying dll's to the exe directory on Windows, instead of putting the dll's in the right place (system32 or sysWOW64).
Good for debugging, NOT good for distribution.

Will they ever learn?

[Fred vS]

Versioning on a lib is never a good idea. Drop that illusion. It works only for a short time.

Perhaps short time is better than none at all (in the case of libfonconfig.so.1 on Linux, I have many doubts it will be short).

If done correctly the installer ( of libfontconfig.so.1 ) creates a symlink as libfontconfig.so (to libfontconfig.so.1)
If not, create the symlink ...
Versioning is not a good idea. I have seen that a bit too much lately.
So it // should NOT be like this...

Yes, it's like tastes, colors, religions, everyone has their preferences.
And even if versioning is not very Orthodox, I prefer it to the obligation to install dev packages which often do not exist.
Or having to force the user, under root, to create symlinks on their system.
But I understand the Orthodox mentality and respect it.

[Thaddy]

Fred, it is not taste. It is how it is done. Period.

[Fred vS]

Fred, it is not taste. It is how it is done. Period.

Thaddy, yes for C, C++ developers who need the library header files.
Borland Kylix used versioning for linking and allowed the user to link libraries with so.number.
(I will not return to this debate, the last time it ended in war),

[Thaddy]

Yes, but the Kylix developers had only basic understanding, so if something did not work, they versioned it. (speed of release)
I still have my Kylixes, but mainly because the sources of the rtl and vcl are gpl'd (which was a commercial mistake)
Fred, versioning is NOT the way to solve a problem.

[Fred vS]

Fred, versioning is NOT the way to solve a problem.

Thaddy, forcing the user to install dev package or create a symlink in their system under root is a WORSE solution. 

[Thaddy]

That part I agree with, end users should not have to install a dev, but these things are related. It should be done right, without versioning, then there is also no need for a forced dev.