Preparing FPC 3.2.4, point out road blocks now

[Fred vS]

In the best possible world, each package maintainer of each library should provide the symlink without so number. Unfortunately this is not yet the case so the solution is to adapt. And versioning is one of the solutions.

[BSaidus]

Hello, for me when working on FreeBSD/OpenBSD (aarch64) I create a symbolic link to .so libraries.
  Ex:

Code: [Select]

  ld.so.1  ->  ld-elf.so.1


[Fred vS]

Hello, for me when working on FreeBSD/OpenBSD (aarch64) I create a symbolic link to .so libraries.
  Ex:

Code: [Select]

  ld.so.1  ->  ld-elf.so.1


To be able to use fpc or applications compiled by fpc?
If so, you shouldn't.
It's up to fpc to define the correct ld-elf.so.1.
Imho, of course. 

[BSaidus]

Hello, for me when working on FreeBSD/OpenBSD (aarch64) I create a symbolic link to .so libraries.
  Ex:

Code: [Select]

  ld.so.1  ->  ld-elf.so.1


To be able to use fpc or applications compiled by fpc?
If so, you shouldn't.
It's up to fpc to define the correct ld-elf.so.1.
Imho, of course. 

Yes, but I think systems like BSD, changes names of there .so libraries frequentelly.

[Fred vS]

Hello, for me when working on FreeBSD/OpenBSD (aarch64) I create a symbolic link to .so libraries.
  Ex:

Code: [Select]

  ld.so.1  ->  ld-elf.so.1


To be able to use fpc or applications compiled by fpc?
If so, you shouldn't.
It's up to fpc to define the correct ld-elf.so.1.
Imho, of course. 

Yes, but I think systems like BSD, changes names of there .so libraries frequentelly.

I suppose that you are talking about FreeBSD.
I think it is because the definition for FreeBSD is missing in /compiler/systems/t_bsd.pas line 154:

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

1.    .....
2.      if target_info.system in systems_openbsd then
3.       DynamicLinker:='/usr/libexec/ld.so'
4.      else if target_info.system in systems_netbsd then
5.       DynamicLinker:='/usr/libexec/ld.elf_so'
6.      else if target_info.system=system_x86_64_dragonfly then
7.       DynamicLinker:='/libexec/ld-elf.so.2'
8.      else if target_info.system=system_aarch64_freebsd then  // THIS IS MISSING
9.       DynamicLinker:='/libexec/ld-elf.so.1'                                  // THIS IS MISSING
10.     else
11.        DynamicLinker:='';
12.  

[EDIT] Recompiled fpc 3.3.1 for FreeBSD aarch64 with the fix:

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

1.      else if target_info.system=system_aarch64_freebsd then  // THIS IS MISSING
2.       DynamicLinker:='/libexec/ld-elf.so.1'                                  // THIS IS MISSING
3.  

And it works now. 

[BSaidus]

Hello, for me when working on FreeBSD/OpenBSD (aarch64) I create a symbolic link to .so libraries.
  Ex:

Code: [Select]

  ld.so.1  ->  ld-elf.so.1


To be able to use fpc or applications compiled by fpc?
If so, you shouldn't.
It's up to fpc to define the correct ld-elf.so.1.
Imho, of course. 

Yes, but I think systems like BSD, changes names of there .so libraries frequentelly.

I suppose that you are talking about FreeBSD.
I think it is because the definition for FreeBSD is missing in /compiler/systems/t_bsd.pas line 154:

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

1.    .....
2.      if target_info.system in systems_openbsd then
3.       DynamicLinker:='/usr/libexec/ld.so'
4.      else if target_info.system in systems_netbsd then
5.       DynamicLinker:='/usr/libexec/ld.elf_so'
6.      else if target_info.system=system_x86_64_dragonfly then
7.       DynamicLinker:='/libexec/ld-elf.so.2'
8.      else if target_info.system=system_x86_64_freebsd then  // THIS IS MISSING
9.       DynamicLinker:='/libexec/ld-elf.so.1'                                  // THIS IS MISSING
10.     else
11.        DynamicLinker:='';
12.  

YES   

[dbannon]

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

The use of "soname" and "linkname" is a linux standard, its not some trick dreamed up by me or some FPC or Kylix developers, its the standard way to use libraries under linux and some other Unixes. https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Its a means of enabling a developer, for example, to have installed multiple versions of a library to allow testing of an application. And a way to allow the application to work with existing libraries that have been established are suitable.

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

1. libthing.so     -> libthing.so.3
2. libthing.so.1  -> libthing2.so.3
3. libthing.so.2  -> libthing2.so.3
4. libthing.so.3
5. libthing2.so.3
6.  

In the above (simplified) case, when I link, I will be using the older library ensuring backwards comparability for users but when I run the same app, I will use the newer library.

This model was widely used in, eg DEC Unix and allowed a high degree of flexibility. Linux uses it now but the rise of packaging has lead people to believe there is only one combination possible. In the "olden days" a sysadmin would build a library, copy it somewhere and make an informed decision about the symlinks necessary.

>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.

Yes Fred, Anton's patch does allow for differences between Darwin, Windows, OpenBSD, haiku and "all the rest". Sounds like that is not enough. Far too long since I used any of the *BSDs to tell.

> Additionally, the libfontconfig-dev package does not exist for these operating systems.
Well, -dev or -devel packages are just a simple add add on, all they do in most cases is make that symlink to the linkname and drop a few doc files in place. Arch linux appears always make that default symlink, perhaps a good idea but it would, if reapplied, mess with the example I give above.

Aside : I package the qt5/6Pas libraries and had a (experienced and knowledgeable) user complain to me that the dev packages did not contain any binaries.  Sigh ...

Summary, in my infinite wisdom, I believe there should be some function that returns the default (run time) library name for all supported OS, this is far from just a libfontconfig issue.

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

1. function LibraryEnding() : string;
2. begin
3.     {$if defined(darwin) or defined (haiku) or defined(OpenBSD) }
4.     result := '.so';
5.     {$else}  
6.     {$if defined(MSWINDOWS)}
7.     result := '.dll');
8.     {$else}
9.     {$if defined(LINUX) }
10.     result := '.so.1';
11.     {$endif}    {$endif}  {$endif}
12. end;
13.  
14. DefaultLibName = 'fontconfig' + LibraryEnding();
15.  

(untested) Room in there for all supported OS ....
Davo

[BSaidus]

Ah, I remember something,
while trying to execute simple program, it require me linker from /lib, not /libexec

[marcov]

The trouble is that Unix wasn't designed to move binaries between systems, just to compile everything on the system itself.

The soname/linkname system that dbannon describes. was meant to make minor updates on the same system, or maybe instances of the same OS (distro+version the same) while also allowing to have two incompatible version on the same system (with one default for new development)

Despite that, people tried to improve cross-system compatibility with dynamically loading shared libraries. That added the chance to make libraries optional, try multiple names, make them configurable even.

This can be a good thing, but needs to be carefully crafted. IMHO in the FPC codebases it is done too often, and not properly maintained.

• It must be decided if it is really worth it
• It needs maintenance to have at least a number of possibilities
• Any submitted fixes should cover more than change the default to some momentarily most common configuration
• It must be possible for the end user (programmer crafting an application) to add more without changing/recompiling FPC sources

Many of the database package headers however do this to varying degrees, but IMHO they should be hard rules whenever a library changed to load dynamically.

In many other places, the reference was just changed from static to dynamic by rota without much thought

Even statically you can at least edit linker resource (link.res) files or linker commandline options, with dynamic linking this can't be done, which is why one should be careful about it.

[marcov]

Summary, in my infinite wisdom, I believe there should be some function that returns the default (run time) library name for all supported OS, this is far from just a libfontconfig issue.

Note that default extension (dylib/so/dll) is available as dynlibs.sharedsuffix.

Adding a ".1" by default is nonsense. It isn't that universal.

[Thaddy]

It isn't that universal.

That is polite  See if I can learn something from that. (I have no intention to do so, don't worry... )
For other readers: this an example of a politically correct answer.

[dbannon]

....
Adding a ".1" by default is nonsense. It isn't that universal.

Well marcov, if that your view OK, but if you state it publicly, and in such a brisk manner, you really should have some facts.

I am talking "out of the box" here to avoid repetition.

Perhaps you could point out to me one Linux distribution that has libfontconfig.so but not libfontconfig.so.1  ?

Or, if that is too challenging, one Linux distribution where my suggested model won't work ? 

I'll make it easy, don't bother checking Debian/Ubuntu or derivatives, Fedora or derivatives, (more specifically) Mageia, Argon, PCLinux, OpenSUSE-Leap, Neon, Mint, MXLinux. They all, do NOT have libfontconfig.so but do have libfontconfig.so.1.  Manjaro is a noted exception (Arch, as I noted above), it has both so will work with the existing model and my suggestion.

I am not suggesting this model should apply to anything other than Linux until someone has checked. And fully understand it definitely does not apply in most (all ?) non linux cases. But those cases need to be applied, one by one, thus my comment "room there for all supported OS"..

Using libfontconfig.so.1 for Linux may not be a perfect solution (but probably is) but it is most certainly a lot better the current offering.

Davo

[Fred vS]

Using libfontconfig.so.1 for Linux may not be a perfect solution (but probably is) but it is most certainly a lot better the current offering.

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

1. const
2. {$ifdef linux}
3. fontconfiglib: array[0..1] of string =
4.                          ('libfontconfig.so.1','libfontconfig.so');
5. {$else}
6. // do the same for other Unix oses (need to check all os)
7. {$endif}
8.  
9. var
10. int1: integer;
11. libname: string = '';
12.  
13. ...
14.  
15.  for int1:= 0 to high(fontconfiglib) do begin
16.   result:= loadlibrary(fontconfiglib[int1]);
17.    if result <> 0 then begin
18.    libname:= fontconfiglib[int1];
19.    break;
20.    end;
21.   end;
22.  
23. if libname <> '' then ...
24. ...

[marcov]

....
Adding a ".1" by default is nonsense. It isn't that universal.

Well marcov, if that your view OK, but if you state it publicly, and in such a brisk manner, you really should have some facts.

I think I was very clear in my more extensive summary of the problem. I would caution against constant ad-hoc changing to the perceived ideal solution. Specially now that the current release is already over 3 years old, solutions should aim for longevity.

So if I apply the posted criteria above to this specific problem I come to the following conclusions

• Multiple tests (that is one of the reasons of dynamic loading in the first place)
• no regressions
• tests ordered by safest first (so libfontconfig.so before libfontconfig.so.1, as the symlink means a preference)
• all of the above overridable by a programmer without recompiling FPC or distribution side updates.

See e.g. ibase60.inc:2755 where multiple names are tested, or about 10 lines later that provides a function to call by a programmer e.g. as the first line in .lpr to test own names. I would make it an open array of names to test though.

 

[dbannon]

marcov, did you understand that the existing model works with one out of eleven distributions I tested ?  And what I suggest works with all eleven ? As well as being technically correct.

So, you would rather 9% than 100% ?

(OK, I'll shutup now, I have had my say and this does not belong in this thread anyway.)

Davo