Preparing FPC 3.2.4, point out road blocks now

[Thaddy]

Well marcov, if that your view OK,

What is so difficult to understand he is right? No but and no if's plz.
If you need versioning you are doing something very wrong. Except for development.
IF you need a -dev installed for distribution you are doing something very wrong.
The point Marco makes is that if you follow the rules of the OS you are fine.
It can of course be the case that someone else made the mistake elsewhere in the tool chain. Not necessarily you.

What he writes is fact, not opinion.

[dbannon]

Sorry Thaddy, I am not sure you are following the conversation.

If you need versioning you are doing something very wrong. Except for development.

Versioning is not my decision Thaddy, Its the Linux distributions that have decided to use versioning,  I have absolutely no influence on how Liniux in general structure their libraries. To be sure I tested 11 distributions, every one, 100%, used library versioning. I expect that represents  >95% of linux systems in use. I am pretty sure its used in close to 100%

IF you need a -dev installed for distribution you are doing something very wrong.

For example, when I submit my package to debian, I do so knowing that it will be compiled there, at Debian, using FPC322. As such, to ensure it works as expected, I have to declare both libssl-dev and libfontconfig-dev are dependencies.

So, I need two -dev packages installed. What exactly am I doing wrong Thaddy ?

The point Marco makes is that if you follow the rules of the OS you are fine.

And the rules on Linux is that there is a difference between the soname, the linkname and the realname of libraries.

I guess you are talking about a different rule, which one is that ? Please be specific.

Davo

EDIT: Note that I accept Marco's statement that that he is uncomfortable making changes at this late stage "caution against constant ad-hoc changing to the perceived ideal". That makes sense and I reluctantly accept it. Its wrong but at least its a wrong we know how to live with. I do not accept Thaddy's statements, they are clearly at odds with the facts.


 

[PeterBB]

If there are any problems with 3.2.2 prevent you from using 3.2.2, it is now the time to point this out

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074706

It seems that msgfmt has changed for the worse  ,
 and the po files in fpc/source/utils/fpdoc/int no longer build.
 So, as things stand, fpc will no longer build on Linux.

Seems to me that to restore the build, headers of

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

1. "Content-Type: text/plain; charset=UTF-8\n"

are needed, and the file encodings changed to UTF-8


Regards,
Peter

[dbannon]

Peter, my tests on unstable indicated that msgfmt also needs the two lines with empty data ahead of the Content-Type tag. I know it sounds very silly but msgfmt fails if it does not see -

Code: [Select]

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
...
No idea why it would want those first two lines there but only works if they are there !

Nothing needs to be done to "change encoding to UTF-8" as far as I can see, just add the lines.

Following files need attention -

Code: [Select]

./fpc/utils/fpdoc/intl/dglobals.de.po
./fpc/utils/fpdoc/intl/dwriter.de.po
./fpc/utils/fpdoc/intl/makeskel.de.po
./fpc/utils/fpdoc/intl/fpdoc.de.po
./fpc/packages/fcl-base/examples/intl/restest.fr.po
./fpc/packages/fcl-base/examples/intl/restest.de.po
./fpc/packages/fcl-base/examples/intl/restest.nl.po
./fpc/packages/fcl-base/examples/intl/restest.pb.po
./fpc/packages/fcl-base/examples/intl/resttest.po
And note, no point in repeating Peter's test unless you are using Debian Unstable (or possibly Trixie by now ?). msgfmt on, eg bookworm shows no problem.

Davo

[PeterBB]

Hi Davo,

The extra lines are indeed needed if there is no other header.

The po files must be UTF-8 encloded, or msgfmt now fails with another error.
(There is already a debian patch to change the encoding to UTF-8)

It iwould be deal to fix every po file,
but its only needed to patch the po files in .../uutils/fpdoc/intl to fix the debian build of 3.2.2.

There is also an sk.po file in .../uutils/fpdoc/intl bit it is not used in the Makefile

I've raised a bug report
https://gitlab.com/freepascal.org/fpc/source/-/issues/40853

Regards,
Peter
 

[marcov]

Apropos libfontconfig, I booted a *nix system for the first time after a busy month, and looked into this. I found that there already is an override in the code, at least in trunk, try the following:

1. put unit libfontconfig in your uses.
2. put

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

1.  LoadFontConfigLib('libfontconfig.so.666',false);

as first line in your .lpr to try to load libfontconfig.so.666 before the rest is tried. Untested,  no guarantees, but worth a try.

[Thaddy]

I still think there should be an unversioned symlink that points to highest available versioned library. And that code should use that symlink and not a path directly to a versioned lib. In my opinion that is the only way to do it properly.
(e.g. everything GNU is installed like that)
That is the responsibilty of the package manager for the libraries that are affected.

[marcov]

I don't have a real deep opinion

• Using the name without subnr (the symlink) requires a -dev package
• using the name with subnr might cause troubles with updates, specially due to FPC long release cycles

So in short, you can't know in advance what is going to happen (and in the past, specially mysql/mariadb were often a pain), but sometimes new developments are fixable by just trying a few extra options from the mainprogram, this is why these kind of procedures exist.

[MarkMLl]

I still think there should be an unversioned symlink that points to highest available versioned library. And that code should use that symlink and not a path directly to a versioned lib. In my opinion that is the only way to do it properly.
(e.g. everything GNU is installed like that)
That is the responsibilty of the package manager for the libraries that are affected.

I really don't like subscribing to an interminable thread, but I agree with Thaddy here.

This is a consequence of the way that the GNU linker etc. works, which cannot realistically be challenged.

MarkMLl

[dbannon]

.... at least in trunk, try the following:
2. put

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

1.  LoadFontConfigLib('libfontconfig.so.666',false);

Thanks Marcov, but trunk does not help me, I have to cope with a "hands off" build at Debian and they use only Release. But its not really a problem for me, as I note below.

I still think there should be an unversioned symlink that points to highest available versioned library.

Correct Thaddy, its installed by the development version of most libraries. Its for linking to. I thought you understood that.

This is a consequence of the way that the GNU linker etc. works...

Correct Mark, but in this case we are not talking about Linking, its a run time issue. Quite different rules apply and different flexibility is required.

A developer might link to the latest version of a library. But sometimes, a developer may have different versions installed and need to manually change that symlink to link to an older version, perhaps to avoid a compatibility problem for example. On the other hand, its assumed an end user's system will probably only have one version of a library and the correct symlink to look for has the soname, eg libsomething.so.1

I have quite got over this issue, I patch FPC for packages I build and distribute and I send my package to Debian with a dependency on the libfontconfig-dev package, I only wanted it fixed because someone else using the FPC's libfontconf unit will very easily send out a binary to their end users without realizing the -dev package is needed. It will crash complaining about a missing library that the user believes, correctly, is installed.

And, I guess, I wanted it fixed because its wrong and that does not impress outsiders. So be it !

Davo

edit: typo

 

 

[marcov]

.... at least in trunk, try the following:
2. put

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

1.  LoadFontConfigLib('libfontconfig.so.666',false);

Thanks Marcov, but trunk does not help me, I have to cope with a "hands off" build at Debian and they use only Release. But its not really a problem for me, as I note below.

Fixes (and thus future 3.2.4) has this code too, don't know about 3.2.2.

[dbannon]

OK, I tried in it a minimal app, it does appear to load something, so I renamed my libfontconfig.so symlink and the minimal app again started without any fuss. Will take me a bit of time to try it in my real app on a clean system but you are right, it does look like it might be working. Late tonight here, tomorrow perhaps ...

Interesting workaround.

Thanks,
Davo

[Fred vS]

If you need versioning you are doing something very wrong.

Like here ?:

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

1. // t_linux.pas
2. ...
3.  
4. {$ifdef m68k}
5.   const defdynlinker='/lib/ld.so.1';
6. {$endif m68k}
7.  
8. {$ifdef i386}
9.   const defdynlinker='/lib/ld-linux.so.2';
10. {$endif}
11.  
12. {$ifdef x86_64}
13.   const defdynlinker='/lib64/ld-linux-x86-64.so.2';
14. {$endif x86_64}
15.  
16. {$ifdef sparc}
17.   const defdynlinker='/lib/ld-linux.so.2';
18. {$endif sparc}
19.  
20. {$ifdef powerpc}
21.   const defdynlinker='/lib/ld.so.1';
22. {$endif powerpc}
23.  
24. {$ifdef powerpc64}
25.   const defdynlinkerv1='/lib64/ld64.so.1';
26.   const defdynlinkerv2='/lib64/ld64.so.2';
27.   var defdynlinker: string;
28. {$endif powerpc64}
29.  
30. {$ifdef arm}
31. {$ifdef FPC_ARMHF}
32.   const defdynlinker='/lib/ld-linux-armhf.so.3';
33. {$else FPC_ARMHF}
34. {$ifdef FPC_ARMEL}
35.   const defdynlinker='/lib/ld-linux.so.3';
36. {$else FPC_ARMEL}
37.   const defdynlinker='/lib/ld-linux.so.2';
38. {$endif FPC_ARMEL}
39. {$endif FPC_ARMHF}
40. {$endif arm}
41.  
42. {$ifdef aarch64}
43. const defdynlinker='/lib/ld-linux-aarch64.so.1';
44. {$endif aarch64}
45.  
46. {$ifdef mips}
47.   const defdynlinker='/lib/ld.so.1';
48. {$endif mips}
49.  
50. {$ifdef sparc64}
51.   const defdynlinker='/lib64/ld-linux.so.2';
52. {$endif sparc64}
53.  
54. {$ifdef riscv32}
55.   const defdynlinker_generic='/lib32/ld.so.1';
56.   const defdynlinker_soft_float='/lib/ld-linux-riscv32-ilp32.so.1';
57.   const defdynlinker_single_float='/lib/ld-linux-riscv32-ilp32f.so.1';
58.   const defdynlinker_double_float='/lib/ld-linux-riscv32-ilp32d.so.1';
59.   { const defdynlinker_quad_float='/lib/ld-linux-riscv32-ilp32q.so.1'; not yet in ABI list }
60.   var defdynlinker : string;
61. {$endif riscv32}
62.  
63. {$ifdef riscv64}
64.   const defdynlinker_soft_float='/lib/ld-linux-riscv64-lp64.so.1';
65.   const defdynlinker_single_float='/lib/ld-linux-riscv64-lp64f.so.1';
66.   const defdynlinker_double_float='/lib/ld-linux-riscv64-lp64d.so.1';
67.   { const defdynlinker_quad_float='/lib/ld-linux-riscv64-lp64q.so.1'; not yet in ABI list }
68.   var defdynlinker : string;
69. {$endif riscv64}
70.  
71. {$ifdef xtensa}
72.   const defdynlinker='/lib/ld.so.1';
73. {$endif xtensa}
74.  
75. {$ifdef loongarch64}
76.   const defdynlinker='/lib64/ld-linux-loongarch-lp64d.so.1';
77. {$endif loongarch64}
78. ...

Apartheid ?

[marcov]

Like here ?:

That FPC internal, which exists to implement a easier baseline. If you look at the glibc internals you will also find all kinds of gore.

So that is a bad example IMHO. Thaddy reasons from an user perspective, and you quote an example from below the user documented interface.
 

[Fred vS]

That FPC internal, which exists to implement a easier baseline.
So that is a bad example IMHO.

Those are bad too I suppose:

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

1. // prthread.inc
2.   PThreadDLL:=DlOpen('libpthread.so.0',RTLD_LAZY);
3. ...
4. // libpccre2_16.pp
5.  {$IFDEF LINUX}
6.     pcrelibname = 'libpcre2-16.so.0';
7.   {$ELSE}
8. ...
9. // libvlc.pp
10. {$ifdef unix}
11.   libname = 'libvlc.so.5';
12. {$else}
13. ...
14. // lua.pas
15. {$IFDEF UNIX}
16.   LUA_NAME = 'liblua.so.5.1';
17.   LUA_LIB_NAME = 'liblua.so.5.1';
18. {$ELSE}
19. ...
20. // glu.pp
21.   GLU_LIB = 'libGLU.so.1';
22. ...
23. // pxlib.pp
24.   pxlibraryname='libpx.so.0'; { Default name }
25. ...
26. // sdl.pp
27.  SDLLibName = 'libSDL-1.2.so.0';
28. ...
29. // sdl_image.pp
30.   SDL_ImageLibName = 'libSDL_image-1.2.so.0';
31. ...
32. // and much others.
33.