Recent

Author Topic: Preparing FPC 3.2.4, point out road blocks now  (Read 90243 times)

Fred vS

  • Hero Member
  • *****
  • Posts: 3410
    • StrumPract is the musicians best friend
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #105 on: July 03, 2024, 07:58:21 pm »
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.
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

BSaidus

  • Hero Member
  • *****
  • Posts: 596
  • lazarus 1.8.4 Win8.1 / cross FreeBSD
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #106 on: July 03, 2024, 08:08:01 pm »
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
lazarus 1.8.4 Win8.1 / cross FreeBSD
dhukmucmur vernadh!

Fred vS

  • Hero Member
  • *****
  • Posts: 3410
    • StrumPract is the musicians best friend
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #107 on: July 03, 2024, 08:23:18 pm »
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.  :-[
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

BSaidus

  • Hero Member
  • *****
  • Posts: 596
  • lazarus 1.8.4 Win8.1 / cross FreeBSD
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #108 on: July 03, 2024, 08:31:02 pm »
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.
lazarus 1.8.4 Win8.1 / cross FreeBSD
dhukmucmur vernadh!

Fred vS

  • Hero Member
  • *****
  • Posts: 3410
    • StrumPract is the musicians best friend
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #109 on: July 03, 2024, 09:27:16 pm »
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.  ;D
« Last Edit: July 13, 2024, 01:01:48 am by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

BSaidus

  • Hero Member
  • *****
  • Posts: 596
  • lazarus 1.8.4 Win8.1 / cross FreeBSD
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #110 on: July 03, 2024, 10:49:23 pm »
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   ;D
lazarus 1.8.4 Win8.1 / cross FreeBSD
dhukmucmur vernadh!

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #111 on: July 04, 2024, 03:18:12 am »

> 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
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

BSaidus

  • Hero Member
  • *****
  • Posts: 596
  • lazarus 1.8.4 Win8.1 / cross FreeBSD
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #112 on: July 04, 2024, 10:15:58 am »
Ah, I remember something,
while trying to execute simple program, it require me linker from /lib, not /libexec
lazarus 1.8.4 Win8.1 / cross FreeBSD
dhukmucmur vernadh!

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11938
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #113 on: July 04, 2024, 11:06:06 am »
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.
« Last Edit: July 04, 2024, 12:23:14 pm by marcov »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11938
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #114 on: July 04, 2024, 11:12:40 am »
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

  • Hero Member
  • *****
  • Posts: 16168
  • Censorship about opinions does not belong here.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #115 on: July 04, 2024, 11:25:02 am »
It isn't that universal.
That is polite  8) See if I can learn something from that. (I have no intention to do so, don't worry... ;D )
For other readers: this an example of a politically correct answer.
« Last Edit: July 04, 2024, 11:27:45 am by Thaddy »
If I smell bad code it usually is bad code and that includes my own code.

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #116 on: July 04, 2024, 01:38:31 pm »
....
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

Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

Fred vS

  • Hero Member
  • *****
  • Posts: 3410
    • StrumPract is the musicians best friend
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #117 on: July 04, 2024, 02:01:10 pm »
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. ...
« Last Edit: July 04, 2024, 02:04:58 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11938
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #118 on: July 04, 2024, 02:17:12 pm »
....
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.

 
« Last Edit: July 04, 2024, 02:18:58 pm by marcov »

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #119 on: July 04, 2024, 02:41:31 pm »
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
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

 

TinyPortal © 2005-2018