Recent

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

Thaddy

  • Hero Member
  • *****
  • Posts: 16187
  • Censorship about opinions does not belong here.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #120 on: July 04, 2024, 02:43:25 pm »
Well marcov, if that your view OK,
What is so difficult to understand he is right? No but and no if's plz. >:D
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.
« Last Edit: July 04, 2024, 02:51:01 pm 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 #121 on: July 05, 2024, 02:17:46 am »
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.


 
« Last Edit: July 05, 2024, 02:32:30 am by dbannon »
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

PeterBB

  • New Member
  • *
  • Posts: 42
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #122 on: July 11, 2024, 01:32:55 pm »
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

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #123 on: July 12, 2024, 02:34:29 am »
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
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

PeterBB

  • New Member
  • *
  • Posts: 42
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #124 on: July 12, 2024, 12:11:14 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 11944
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #125 on: July 13, 2024, 01:30:51 pm »
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

  • Hero Member
  • *****
  • Posts: 16187
  • Censorship about opinions does not belong here.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #126 on: July 13, 2024, 04:39:02 pm »
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.
« Last Edit: July 13, 2024, 04:42:52 pm by Thaddy »
If I smell bad code it usually is bad code and that includes my own code.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11944
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #127 on: July 13, 2024, 06:00:20 pm »
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

  • Hero Member
  • *****
  • Posts: 8035
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #128 on: July 13, 2024, 11:19:13 pm »
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

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 #129 on: July 14, 2024, 10:28:54 am »
.... 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.

Quote from: thaddy
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.

Quote from: MarkMLl
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

 

 
« Last Edit: July 14, 2024, 10:31:08 am by dbannon »
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

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11944
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #130 on: July 14, 2024, 12:42:29 pm »
.... 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

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #131 on: July 14, 2024, 02:03:08 pm »
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

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: 3413
    • StrumPract is the musicians best friend
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #132 on: July 15, 2024, 12:12:13 pm »
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 ?
« Last Edit: July 15, 2024, 12:14:47 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: 11944
  • FPC developer.
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #133 on: July 15, 2024, 12:55:07 pm »

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

  • Hero Member
  • *****
  • Posts: 3413
    • StrumPract is the musicians best friend
Re: Preparing FPC 3.2.4, point out road blocks now
« Reply #134 on: July 15, 2024, 01:19:24 pm »
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.  
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

 

TinyPortal © 2005-2018