Preparing FPC 3.2.4, point out road blocks now lazarus / 60-Free Pascal ---------------------------------------------------------------------- FPK · 2021-10-25 05:57 Currently we are in the process of preparing the 3.2.4 release, mainly by merging stuff from main into fixes. 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 , i.e. if you are stuck with 3.0.4 for some reasons. ---------------------------------------------------------------------- marcov · 2021-10-25 07:29 Test with the FIXES_3_2 branch, FPC 3.2.3 that is. ---------------------------------------------------------------------- AlexTP · 2021-10-25 10:49 I wonder when the FreeBSD patch will be merged? https://github.com/Ale xey-T/CudaText/blob/master/doc/freebsd-v12-support-for-fpc32.patch ---------------------------------------------------------------------- Fred vS · 2021-10-25 12:21 Quote from: FPK on October 25, 2021, 07:57:25 amCurrently we are in the process of preparing the 3.2.4 release, mainly by merging stuff from main into fixes. 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 , i.e. if you are stuck with 3.0.4 for some reasons. Hello. Nice! Please, if possible, could you make work -Cg -k-pie -k-znow for Linux? See here: https://forum.lazarus.freepascal.org/index.php/topic,56842.0.html It works perfectly with fpc 3.0.4 and fpc 3.3.1. You may test it compiling a application using BGRABitmap or Zeos lib, no luck with fpc 3.2.0 or 3.2.2 but ok with fpc 3.0.4 / 3.3.1. Thanks. PS: It would be super great if this could be fixed: https://gitlab.com/freepascal.org/fpc/source/-/issues/32367 But yes, I know, I dream and ask too much for this. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-10-25 12:55 Quote from: Alextp on October 25, 2021, 12:49:26 pmI wonder when the FreeBSD patch will be merged? https://github.com/Alexey- T/CudaText/blob/master/doc/freebsd-v12-support-for-fpc32.patch Yes, please, mainly changing with this: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  if target_info.system in (systems_openbsd+systems_freebsd+[system_x86_64_dragonfly]) then LdProgram:='ld.bfd'; And the rest of the patch too. ( Thanks Alex ) ---------------------------------------------------------------------- FPK · 2021-10-25 19:08 Quote from: Alextp on October 25, 2021, 12:49:26 pmI wonder when the FreeBSD patch will be merged? https://github.com/Alexey- T/CudaText/blob/master/doc/freebsd-v12-support-for-fpc32.patch Is this a regression with regard to 3.2.2 or 3.0.4? If not, please do not glutter this thread with unrelated stuff. ---------------------------------------------------------------------- AlexTP · 2021-10-25 19:10 No, it's not a regression, sorry. ---------------------------------------------------------------------- Seenkao · 2021-10-25 19:34 Сделать обработку оптимизации для каждой ОС. Ссылки и код. Eng: Do optimization processing for each OS. Links and code: https://forum.lazarus.freepascal.org/index.php/topic,56719.0.html Quote from: Seenkao on October 14, 2021, 12:32:20 amFPC 3.2.1, Linux- Debian 10 -al Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   useEl^.rh2 := ry1 + 30 + 33;// assembler//      movaps  %xmm1,%xmm2//      movq    _$DRAWALL$_Ld1@GOTPCREL(%rip),%rdx//      addss   (%rdx),%xmm2//      movq    _$DRAWALL$_Ld48@GOTPCREL(%rip),%rdx//    addss   (%rdx),%xmm2//      movss   %xmm2,28(%rax).Ll56:  useEl^.tx21 := rx1 + 5;// assembler//      movaps  %xmm0,%xmm2//      movq    _$DRAWALL$_Ld16@GOTPCREL(%rip),%rdx//      addss   (%rdx),%xmm2//    movss   %xmm2,56(%rax) Quote from: ASerge on October 16, 2021, 10:55:46 amInterestingly, Delphi considers constants as a Double type, but sums constants at compile time, no matter in what order it go. From Delphi 10.4 disassembler: Code: ASM  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Project1.dpr.10: R.rh2 := 30 + 33 + D + 28;000000000040D51F F3480F5A0580280000 cvtss2sd xmm0,qword ptr [rel $00002880]000000000040D528 F20F580528000000 addsd xmm0,qword ptr [rel $00000028]000000000040D530 F2480F5AC0       cvtsd2ss xmm0,xmm0000000000040D535 F30F1105A38C0000 movss dword ptr [rel $00008ca3],xmm0 Я проверил и для FPC/Lazarus, код получается подобный Delphi. Данная оптимизация работает на Windows. Но не работает на Linux. При одном и том же коде паскаля это потеря примерно 8% скорости работы кода для Linux (где это используется). Eng: I also checked for FPC/Lazarus, the code turns out to be similar to Delphi. This optimization works on Windows. But it doesn't work on Linux. With the same pascal code, this is a loss of about 8% of the code speed for Linux (where it is used). ---------------------------------------------------------------------- FPK · 2021-10-25 19:41 Quote from: Fred vS on October 25, 2021, 02:21:39 pmQuote from: FPK on October 25, 2021, 07:57:25 amCurrently we are in the process of preparing the 3.2.4 release, mainly by merging stuff from main into fixes. 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 , i.e. if you are stuck with 3.0.4 for some reasons. Hello. Nice! Please, if possible, could you make work -Cg -k-pie -k-znow for Linux? See here: https://forum.lazarus.freepascal.org/index.php/topic,56842.0.html It works perfectly with fpc 3.0.4 and fpc 3.3.1. Can you please check after baa28faa19 with main/3.3.1? If it helps, I merge it. ---------------------------------------------------------------------- Fred vS · 2021-10-25 21:47 Quote from: FPK on October 25, 2021, 09:41:56 pmCan you please check after baa28faa19 with main/3.3.1? If it helps, I merge it. Hello Florian. Downloaded commit of today 25/10/2021 23:10 : 5c7974fceb768f96853b4abc05cb122ac8ccfd0c from https://gitlab.com/freepascal.org/fpc/source main branch. Compiled + installed = OK. Using -Cg -k-pie -k-znow for a program with BGRABitmap. It compiles and link without any warning at linking.  QuoteHint: (11030) Start of reading config file /etc/fpc.cfg Hint: (11031) End of reading config file /etc/fpc.cfg Free Pascal Compiler version 3.3.1 [2021/10/25] for x86_64 Copyright (c) 1993-2021 by Florian Klaempfl and others (1002) Target OS: Linux for x86-64 (3104) Compiling strumpract.pas ... (9015) Linking strumpract (1008) 567509 lines compiled, 14.7 sec, 4011696 bytes code, 2594736 bytes data (1021) 184 warning(s) issued (1022) 3112 hint(s) issued (1023) 407 note(s) issued Result: Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i fred@fredvs ~> file /home/fred/strumpract/src/strumpract Quote/home/fred/strumpract/src/strumpract: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped Conclusion, yes, perfect. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-10-25 21:58 Ooooops, sorry but there is problem. The program does not run any more with or without -Cg -k-pie -k-znow...  I try to debug it but not easy, no infos. Not sure it comes from your commit, I will (try to) find from witch commit. ---------------------------------------------------------------------- Fred vS · 2021-10-26 00:14 Hello. After high fight I found the commit that makes me problems: Commit ee10850a of 17 Oct, 2021: Reducing and aligning ... https://gitlab.com/freepascal.org/fpc/source/- /commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e Since that commit all my applications do not run anymore. So maybe your patch for fpc 3.2.4 for -Cg will work but I cannot test it with last trunk 3.3.1 ( because of this ee10850a commit ). [Out of the subject of the topic] For msegui and some other console apps (did not test LCL), there is a serious problem since commit ee10850a5793. ---------------------------------------------------------------------- Fred vS · 2021-10-26 00:41 The last for tonight, I promise. I did try this: Use the last trunk 3.3.1 but revert the change done in commit ee10850a ( replace all the files changed by those before commit ee10850a. ) FPC compile + install + run : OK.  My apps: compiling + linking with or without -Cg + running : OK.  And the pie binary is created and runs too! So last conclusion: OK for your commit baa28faa19 but not very OK for commit ee10850a. Fre;D ---------------------------------------------------------------------- PascalDragon · 2021-10-26 06:57 Quote from: Fred vS on October 25, 2021, 02:21:39 pmPS: It would be super great if this could be fixed: https://gitlab.com/freepascal.org/fpc/source/-/issues/32367 But yes, I know, I dream and ask too much for this. This is not a regression and thus this has no place in this thread. Quote from: Seenkao on October 25, 2021, 09:34:04 pmEng: Do optimization processing for each OS. Links and code: Is this a regression from 3.0.4 or 3.2.0? If not, then this has no place here. ---------------------------------------------------------------------- dbannon · 2021-10-26 08:04 OK, I pulled down fixes_3_2 from gitlab as a zip file (so fast !) and compiled with my existing FPC3.2.0. Compiled and installed cleanly but - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i dbannon@dell:~/bin/FPC/fixes_3_2/SRC$ ../bin/fpc -iV3.2.0 The version.pas file says - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     Copyright (c) 1998-2002 by Florian Klaempfl....    const       { version string }       version_nr = '3';       release_nr = '2';       patch_nr   = '3';       minorpatch = ''; I have definitly NOT got my existing fpc - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i dbannon@dell:~/bin/FPC$ ls -l fpc-3.2.0/bin/fpc-rwxr-xr-x 1 dbannon dbannon 513952 Jun 15  2020 fpc-3.2.0/bin/fpcdbannon@dell:~/bin/FPC$ ls -l fixes_3_2/bin/fpc-rwxr-xr-x 1 dbannon dbannon 518512 Oct 26 18:47 fixes_3_2/bin/fpc Should I be surprised ?  Am I testing what I think I am testing ? Davo ---------------------------------------------------------------------- Fred vS · 2021-10-26 12:00 Hello. I did try to compile my apps with last commit of fixes_3_2. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i fred@ /usr/lib/fpc/3.2.3/ppcx64 -iVQuote3.2.3 OK, even without your -Xg baa28faa19 patch, now it compiles and link ( with a warning ) and run all my apps with -Cg. QuoteHint: (11030) Start of reading config file /etc/fpc.cfg Hint: (11031) End of reading config file /etc/fpc.cfg Free Pascal Compiler version 3.2.3 [2021/10/26] for x86_64 Copyright (c) 1993-2021 by Florian Klaempfl and others (1002) Target OS: Linux for x86-64 (3104) Compiling strumpract.pas ... (9015) Linking strumpract /usr/bin/ld: /usr/lib/fpc/3.2.3/units/x86_64-linux/rtl/si_c.o: warning: relocation in read-only section `.text.n_si_c_$$__fpc_libc_start' /usr/bin/ld: warning: creating DT_TEXTREL in a PIE (1008) 567509 lines compiled, 15.7 sec (1021) 128 warning(s) issued (1022) 2961 hint(s) issued (1023) 545 note(s) issued So, nice, already without patch, fpc 3.2.3 can create pie (with a warning) apps that use BGRABitmap. [EDIT] Imho the warning is ok because it shows that the pie linking was done. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-10-26 12:26 Quote from: dbannon on October 26, 2021, 10:04:35 amI Am I testing what I think I am testing ? Davo Hello Davo. I do this and it install fpc 3.2.3 out-of-the-box: 1) Download source + unzip : https://gitlab.com/freepascal.org/fpc/sou rce/-/archive/fixes_3_2/source-fixes_3_2.zip 2) Create a script file named "build_fpc64_linux.sh" and save it into /source-fixes_3_2/build_fpc64_linux.sh Here the script: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #!/bin/sh  COMPILER=/usr/lib/fpc/3.2.0/ppcx64 make cleanmake all FPC=$COMPILER OPT="-Fl/usr/local/lib" make FPC=$COMPILER install INSTALL_PREFIX=/usr/  Then do : Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i > cd /thedirectoryof/source-fixes_3_2/ Then Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i sudo build_fpc64_linux.sh It will compile + install fpc 3.2.3 in /usr/lib/fpc/3.2.3/ Fre;D ---------------------------------------------------------------------- dbannon · 2021-10-26 12:41 Quote from: Fred vS on October 26, 2021, 02:26:11 pmQuote from: dbannon on October 26, 2021, 10:04:35 amI Am I testing what I think I am testing ? Davo Hello Davo. I do this and it install fpc 3.2.3 out-of-the-box: .... Thanks Fred, I am doing pretty much the same but not installing into root space. But when you do as you say, does your Fixes install claim to be version 3.2.0 ? Davo ---------------------------------------------------------------------- Fred vS · 2021-10-26 12:49 Quote from: dbannon on October 26, 2021, 02:41:52 pmBut when you do as you say, does your Fixes install claim to be version 3.2.0 ? Davo Sorry but I dont understand. What fixes, in previous post it is only to compile + install original fpc 3.2.3. Are you talking about a warning when I did the fixes for fpc 3.3.1 ( reverted a problematic commit )? If so, also no claim at installation. But maybe I miss something. Fre;D ---------------------------------------------------------------------- Seenkao · 2021-10-26 17:48 Quote from: PascalDragon on October 26, 2021, 08:57:50 amIs this a regression from 3.0.4 or 3.2.0? If not, then this has no place here. Да, я неправильно понял суть топика. Это не регресс, это обычное поведение для всех компиляторов 3.0.4, 3.2.1, 3.2.2. Видимо это ни когда не случится.... ))) Уже давно было ввести переменные, которые подменяют числа и для Linux (и вероятно для многих других систем, кроме Windows - где это сделано). Извиняюсь, что потревожил. Eng:Yes, I misunderstood the essence of the topic. This is not a regression, this is the usual behavior for all compilers 3.0.4, 3.2.1, 3.2.2. Apparently this will never happen....))) It has long been possible to introduce variables that substitute numbers for Linux (and probably for many other systems other than Windows - where this is done). I'm sorry for disturbing you. ---------------------------------------------------------------------- FPK · 2021-10-26 18:23 Quote from: Fred vS on October 26, 2021, 02:14:50 amHello. After high fight I found the commit that makes me problems: Commit ee10850a of 17 Oct, 2021: Reducing and aligning ... https://gitlab.com/freepascal.org/fpc/source/- /commit/ee10850a5793b69b19dc82b9c28342bdd0018f2e Since that commit all my applications do not run anymore. So maybe your patch for fpc 3.2.4 for -Cg will work but I cannot test it with last trunk 3.3.1 ( because of this ee10850a commit ). [Out of the subject of the topic] For msegui and some other console apps (did not test LCL), there is a serious problem since commit ee10850a5793. Well, they probably make assumptions about internla structures they shouldn't: https://wiki.freepascal.org/User_Changes_Trunk#System_- _Ref._count_of_strings But please keep such unrelated things out of this thread. It is about regressions of 3.2.3 against 3.2.2 and 3.0.4 ---------------------------------------------------------------------- Fred vS · 2021-10-26 18:41 Quote from: FPK on October 26, 2021, 08:23:26 pmBut please keep such unrelated things out of this thread. It is about regressions of 3.2.3 against 3.2.2 and 3.0.4 OK, ok ( but you asked me  ) : QuoteCan you please check after baa28faa19 with main/3.3.1? If it helps, I merge it. And to check it, better to be able to run it... Anyway, like explained in last post, with last fixes-3.2.3 the PIE binary is created at linking with a warning from linker and runs ok, like with fpc 3.0.4 (where there was no warning). With your patch pic-field, the link is OK too, without any warning. Imho a little note like "PIE link done." would be welcome, my 0.0001 cent, of course. Fre;D PS: If you want, I may apply your pic-field patch for 3.3.1 to  3.2.3 and see if all is OK ( but it should be ok ). ---------------------------------------------------------------------- dbannon · 2021-10-26 23:20 Quote from: Fred vS on October 26, 2021, 02:49:08 pm Sorry but I dont understand. What fixes, in previous post it is only to compile + install original fpc 3.2.3. When I download FPC fixes_3_2, compile and install, the resulting fpc reports itself as being 3.2.0 - I expect it to be 3.2.3 as mentioned several times in this thread. Just to be clear, I download https://gitlab.com/freepascal.org/fpc/sou rce/-/archive/fixes_3_2/source-fixes_3_2.zip. It includes a version.pas file that does have appropriate version numbers in it (but a very out of date copyright statement) but when that source is used, compiled and installed I get - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i dbannon@dell:~/bin/FPC/fixes_3_2/bin$ pwd/home/dbannon/bin/FPC/fixes_3 _2/bindbannon@dell:~/bin/FPC/fixes_3_2/bin$ ls -la fpc-rwxr-xr-x 1 dbannon dbannon 518512 Oct 26 18:47 fpcdbannon@dell:~/bin/FPC/fixes_3_2/bin$ ./fpc -iV3.2.0                                       // this line should say 3.2.3 IMHOdbannon@dell:~/bin/FPC/fixes_3_2/bin$ See, fpc -iv reports itself as being 3.2.0, -iW reports the same thing - I would expect it to be 3.2.3 or, even 3.2.2 but certainly not 3.2.0.  And the copyright .... I would like to test fixes_3_2, the one that is likely to become 3.2.4 shortly, I believe it is tagged 3.2.3. Like you Fred, I am interested in the Hardening, especially if changes are being made to how it works this late in the process. I think its important that end users like me test things like FPC but if I cannot be sure just what I am testing, there is no point. I am the first to admit I may be doing something wrong, but if I am, maybe its because the correct process is unclear ?  Other potential users may be just as silly as I apparently am. Davo ---------------------------------------------------------------------- Fred vS · 2021-10-26 23:40 Quote from: dbannon on October 27, 2021, 01:20:50 am I am the first to admit I may be doing something wrong, but if I am, maybe its because the correct process is unclear ?  Other potential users may be just as silly as I apparently am. Davo Please, could you give the script that you used to compile + install fpc? [EDITED] Here the content of /compiler/version.pas that I get from  https://gi tlab.com/freepascal.org/fpc/source/-/archive/fixes_3_2/source- fixes_3_2.zip. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unit version; {$i fpcdefs.inc} interface     const       { version string }       version_nr = '3';       release_nr = '2';       patch_nr   = '3';       minorpatch = ''; Very strange that you get something else... ---------------------------------------------------------------------- dbannon · 2021-10-27 01:45 Quote from: Fred vS on October 27, 2021, 01:40:06 am Please, could you give the script that you used to compile + install fpc? No script needed, its just - Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i make allmake install INSTALL_PREFIX=/home/dbannon/bin/FPC/fixes_3_2/Thats all I have ever used for that job. QuoteHere the content of /compiler/version.pas that I get from  https ://gitlab.com/freepascal.org/fpc/source/-/archive/fixes_3_2/source- fixes_3_2.zip. Yes, I quoted the same content from version.pas several posts ago. Thats why I considered it worth raising. I think I will try the same process on a clean vm, but it will require FPC3.2.[0,2] of course.... Davo ---------------------------------------------------------------------- Fred vS · 2021-10-27 02:28 Hello Davo. Yep, I think I get it. Indeed, doing like you did, not in /usr/  but in directory /home/fred/fpc_test/ : Testing fpc: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i /home/fred/fpc_test/bin/fpc -iVQuote3.2.2 But if you test ppcx64 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  /home/fred/fpc_test/lib/fpc/3.2.3/ppcx64 -iVQuote3.2.3 Indeed, very strange.... [EDIT] And I confirm that my /usr/bin/fpc also show 3.2.2 ( the compiler used to compile ppcx64 ), so yes, imho there is something not normal. Fre;D ---------------------------------------------------------------------- dbannon · 2021-10-27 05:32 OK, so, what I see now - we are both building FPC 3.2.3 but we are using a different compiler to build it, there is a pattern - Fred uses 3.2.2 to compile and gets a fpc that thinks its 3.2.2 Davo uses 3.2.0 to compile and gets a fpc that thinks its 3.2.0 So, Davo tries a clean vm, installs from the ubuntu repo 3.2.2 and uses that to build the 3.2.3 source, and, you guessed it, the result thinks its 3.2.2 ! So, the version that fpc reports does not depend on its own source code, it depends on the version of the compiler used to build it !  Maybe the build process is intended to use the newly build ppcx64 to build fpc but somehow ends up using the underlying 'old' one ? And yep, testing ppcx64 does report 3.2.3 - thats positive at least. Davo ---------------------------------------------------------------------- dbannon · 2021-10-27 07:43 Quote from: PascalDragon on October 27, 2021, 09:00:30 am... No, you shouldn't be surprised and no, you're not testing what you think you're testing. The fpc compiler driver binary picks up the real backend compiler binaries either if they're in the same directory (e.g. on Windows or if you install using our installation scripts provided with the binary releases) or if they're in PATH. If you simply do a make install neither will be true. So you need to temporary put lib/fpc/3.2.3/ (where ppcx64 resides) into your PATH (at the front) so that the correct binary is picked up. Indeed, I worked out at least some of that just now.  I found that by putting the (3.2.3) ppcx64 in the same directory as the fpc executable (much as I do when setting up a cross compiler), I got the result I expected.  My initial test was a little artificial, not having my PATH pointing to the new fpc. Now I can confidently test properly, for that I will have to change my PATH. Thanks PascalDragon, I feel a lot more comfortable now. Davo ---------------------------------------------------------------------- PascalDragon · 2021-10-28 07:09 Quote from: dbannon on October 27, 2021, 09:43:26 amThanks PascalDragon, I feel a lot more comfortable now. Good. By the way: can it be that someone removed the post of mine that dbannon quoted from? ---------------------------------------------------------------------- avk · 2021-10-28 07:47 Аccidentally discovered that FPC 3.2.2(and 3.3.1)-win64 lacks compiled units for the GMP package. Are there any reasons for this? ---------------------------------------------------------------------- marcov · 2021-10-28 10:34 Quote from: avk on October 28, 2021, 09:47:17 amАccidentally discovered that FPC 3.2.2(and 3.3.1)-win64 lacks compiled units for the GMP package. Are there any reasons for this? Headers are generally only enabled for targets that they were confirmed to fully work. ---------------------------------------------------------------------- avk · 2021-10-28 10:50 Thank you. ---------------------------------------------------------------------- BeniBela · 2021-11-06 17:36 This bug affects 3.2.3: https://gitlab.com/freepascal.org/fpc/source/-/issues/35651 ---------------------------------------------------------------------- trev · 2021-11-15 09:52 Mountain Lion 10.8.5 (Intel) fails to build FPC 3.2 Fixes. The cause is the codesign command:    /usr/bin/codesign --remove-signature ppc3.tmp    ppc3.tmp: unsupported type or version of signature   make[2]: *** [cycle] Error 1   make[1]: *** [compiler_cycle] Error 2   make: *** [build-stamp.x86_64-darwin] Error 2 I could not remove the signature either, but I could re-sign it with:   /usr/bin/codesign --force --sign - ppc3.tmp although the Makefile only wants to remove a signature and not re-sign the executables. It turns out that the codesign utility for Mountain Lion lacks the --remove-signature option. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i trev@dynamic37 [/Users/trev/fpc_fixes32/compiler] $ codesign Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign       codesign -v [-v*] [-R testreq] path|pid ... # verify       codesign -d [options] path ... # display contents       codesign -h pid ... # display hosting paths [Updated]  The same issue also applies to OS X Maevricks, OS X Yosemite, OS X El Capitan and macOS Sierra. [Updated2] My workaround was to create a fake codesign and ensure it was found first in the path. Jonas suggested that you can provide a custom codesign command via the CODESIGN=xxx make parameter. You could use CODESIGN=/usr/bin/true to work around it. ---------------------------------------------------------------------- BeniBela · 2021-12-21 11:26 Big road blocks for ARM: https://gitlab.com/freepascal.org/fpc/source/-/issues/39490 https://gitlab.com/freepascal.org/fpc/source/-/issues/39492 ---------------------------------------------------------------------- Zvoni · 2022-03-31 13:56 Any news on this issue?: https://gitlab.com/freepascal.org/fpc/source/-/issues/35248 ---------------------------------------------------------------------- dbannon · 2022-03-31 23:31 https://forum.lazarus.freepascal.org/index.php/topic,58888.msg439013.h tml (accommodate forthcoming changes to glibc) and, probably wishful thinking - https://gitlab.com/freepascal.org/fpc/source/-/issues/39451  (hardening on PPC64le) .... sorry ! Davo ---------------------------------------------------------------------- PascalDragon · 2022-04-01 13:22 Quote from: Zvoni on March 31, 2022, 03:56:53 pmAny news on this issue?: https://gitlab.com/freepascal.org/fpc/source/-/issues/35248 Not even fixed in main, so definitely won't be fixed in 3.2.4. ---------------------------------------------------------------------- jonnybravo · 2022-04-02 14:25 Where can I see what's in main?  I am interested in what could be coming our way! ---------------------------------------------------------------------- Bi0T1N · 2022-04-02 15:40 Quote from: jonnybravo on April 02, 2022, 04:25:53 pmWhere can I see what's in main?  I am interested in what could be coming our way! You can see new features here and bug fixes/changes here. However, this is not updated for every single change so you might also need to check the commit history. ---------------------------------------------------------------------- jonnybravo · 2022-04-02 15:47 Thank you, that's great!! ---------------------------------------------------------------------- BSaidus · 2022-12-15 15:15 Hi, people, A question that any one want to be asked When can we see the 3.2.4 fpc release ?? Thanks for patience. ---------------------------------------------------------------------- Thaddy · 2022-12-15 16:30 Note that, contrary to what was mentioned above, not all new features of main/trunk -  if any - will be in the point/bugfix release 3.2.4 although some things may have been back-ported. 3.2.4 is basically a release based on 3.2.2-fixes a.k.a. 3.2.3. Main/trunk has release target 3.4.0 ( it is suggested maybe even jumping to 4.0.0 because of the many important new compiler features ) and is expected to be released somewhere in the future, without a current release date. Think a year or more. I would be very surprised if  a major release based on main/trunk is released in 2023.... Just so that you are not confused or disappointed when some new features that are in main/trunk are missing in 3.2.4. ---------------------------------------------------------------------- DaveR_uk · 2024-03-02 21:57 Quote from: FPK on October 25, 2021, 07:57:25 amCurrently we are in the process of preparing the 3.2.4 release, mainly by merging stuff from main into fixes. 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 , i.e. if you are stuck with 3.0.4 for some reasons. That was just over 15 months ago.  Is an FPC 3.2.x bug-fix production release likely any time soon please? Or is FPC going to eventually jump direct to a  major new release?  TWhe recent Lazarus 3.2 is understandably still built against FPC 3.2.2 as the latest stable production release.   An update on possible timescales would be much appreciated. Where did I get 15 months from ??? ---------------------------------------------------------------------- ccrause · 2024-03-03 05:47 Quote from: DaveR_uk on March 02, 2024, 10:57:31 pmQuote from: FPK on October 25, 2021, 07:57:25 amCurrently we are in the process of preparing the 3.2.4 release, mainly by merging stuff from main into fixes. 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 , i.e. if you are stuck with 3.0.4 for some reasons. That was just over 15 months ago.  Is an FPC 3.2.x bug-fix production release likely any time soon please? Or is FPC going to eventually jump direct to a  major new release?  TWhe recent Lazarus 3.2 is understandably still built against FPC 3.2.2 as the latest stable production release.   An update on possible timescales would be much appreciated. Where did I get 15 months from ??? Good question, it has been more than two years since the first post appeared. ---------------------------------------------------------------------- JuhaManninen · 2024-03-03 17:19 Quote from: ccrause on March 03, 2024, 06:47:22 amGood question, it has been more than two years since the first post appeared. ... and FPC 3.2.2 was released almost 3 years ago. This is annoying. ---------------------------------------------------------------------- Wallaby · 2024-03-05 06:21 It's best to use fpcupdeluxe and regularly update to FPC fixes and Lazarus fixes. This way you could get the latest official releases plus any fixes made to them after the release. I am using 3.2.3 (aka 3.2 + fixes) and Lazarus 3.0 + fixes with great success. No need to wait for  an official release, which seems to have been abandoned. ---------------------------------------------------------------------- zeljko · 2024-03-05 08:02 I don't think it's abandoned, but yes, it need to be released soon, too much time is passed since last release. ---------------------------------------------------------------------- 440bx · 2024-03-05 08:08 There is probably a good reason why it hasn't been released after that much time and, it's likely (mostly) a technical reason. It would be nice if one of the developers would mention what is holding the release back. ---------------------------------------------------------------------- ocloma · 2024-04-02 15:31 maybe it fell into an infinite loop... ---------------------------------------------------------------------- Thaddy · 2024-04-03 08:25 Quote from: zeljko on March 05, 2024, 09:02:37 amI don't think it's abandoned, but yes, it need to be released soon, too much time is passed since last release. 1. that can be taken as an offence by the core team (it also expresses ignorance) 2. normal users want a stable environment 3. there is a fixes branch if you need a point release approximation. 4. the amount of changes and new features in trunk does not warrant a full release yet, and that will probably take even more time. 5. you obviously have no experience with professional release management. The core team has.....and delivers every release. 6. scratch out time from your vocabulary. It is done when it is done. 7. i think a  is warranted. i also want to add a to such folly. ---------------------------------------------------------------------- marcov · 2024-04-03 08:35 The last time I heard, an issue with arm-linux linking,  some ABI or other  binary format identifier was the problem. There are not that many status updates on core. ---------------------------------------------------------------------- Thaddy · 2024-04-03 08:37 I know. But sometimes users still don't get the importance of mitigating such an issue first. ---------------------------------------------------------------------- marcov · 2024-04-03 09:08 Quote from: Thaddy on April 03, 2024, 10:37:17 amI know. But sometimes users still don't get the importance of mitigating such an issue first. I'm sure that as a Lazarus core developer, Zeljan knows the issues :-) ---------------------------------------------------------------------- Thaddy · 2024-04-03 09:13 Then why he shows impatience, Marco? An issue with ARM is by now a blocking issue, since it is such an important platform by now. BTW I had to manage such things in my working carreer, so I understand the sentiments... you know that. I respect everyone in the core team. ---------------------------------------------------------------------- BSaidus · 2024-04-03 14:15 Quote from: marcov on April 03, 2024, 10:35:23 amThe last time I heard, an issue with arm-linux linking,  some ABI or other  binary format identifier was the problem. There are not that many status updates on core. Hello, I have an issue with freebsd-aarch64 OS. After compiling a simple program with fpc ( ex: simple helloworld console ) I must use command :    Code: [Select]   brandelf -t freebsd project1    to execute the program. Can FPC team do this just after compiling ? Thank you. ---------------------------------------------------------------------- marcov · 2024-04-03 15:17 Quote from: BSaidus on April 03, 2024, 04:15:43 pmQuote from: marcov on April 03, 2024, 10:35:23 amThe last time I heard, an issue with arm-linux linking,  some ABI or other  binary format identifier was the problem. There are not that many status updates on core. Hello, I have an issue with freebsd-aarch64 OS. After compiling a simple program with fpc ( ex: simple helloworld console Afaik the Aarch64 port was done by one Mikaël Urankar. I don't know anything about it, and don't have the HW. For LLVM based FreeBSDs, it might help to change the elf ident like in the i386/x64 one The commit bugreport (https://gitlab.com/freepascal.org/fpc/source/-/issues/38441 ) seems to contain some patches by Pierre with the request to validate. Please do any work on top of the fixes branch or trunk. ---------------------------------------------------------------------- lainz · 2024-05-04 18:06 I see the fixes branch and no problem at all for now. ---------------------------------------------------------------------- dbannon · 2024-05-06 11:56 Quote from: lainz on May 04, 2024, 08:06:18 pmI see the fixes branch and no problem at all for now.  People like Debian do not, as a matter of policy, ship test/fixes/beta code. They use only release products. This means, for example, all FPC based applications in the Debian repository are currently built with a compiler that won't work with openssl 3.0.  And Debian means, eg, Ubuntu, Linux Mint .... A lot of companies, quite sensibly, have similar policies. Davo ---------------------------------------------------------------------- _Bernd · 2024-05-15 10:46 Hello, it looks like FPC 3.2.4 is no longer needed ;-)) https://github.com/gcarreno/1brc-ObjectPascal#results When it comes down to it, FPC 3.3.1 seems to be the first choice. Regards, Bernd. ---------------------------------------------------------------------- JuhaManninen · 2024-05-16 09:44 Quote from: _Bernd on May 15, 2024, 12:46:46 pmWhen it comes down to it, FPC 3.3.1 seems to be the first choice. FPC 3.3.1 is the development version. All distributions including Linux distros and Lazarus release builds use the latest release version of FPC. So, we desperately need a new release of FPC! AFAIK FPC 3.2.3 branch is just fine. Certainly it is better then the 3+ years old FPC 3.2.2. Please build a release out of it ASAP! Yes, it would be time for a next major release, too, but let's not go there now. ---------------------------------------------------------------------- marcov · 2024-05-16 10:27 Quote from: JuhaManninen on May 16, 2024, 11:44:05 ambetter then the 3+ years old FPC 3.2.2. It is not 3 years old until monday. ---------------------------------------------------------------------- JuhaManninen · 2024-05-16 10:30 Quote from: marcov on May 16, 2024, 12:27:27 pmIt is not 3 years old until monday. Oops, right. Birthday coming. ---------------------------------------------------------------------- 440bx · 2024-05-16 10:40 This might be a very dumb question but... Since v3.2.4 is just a point release, is there some reason why v3.2.4 cannot simply be the current "fixes" version ? At least that would formally "bless" the fixes. ---------------------------------------------------------------------- marcov · 2024-05-16 10:48 Quote from: 440bx on May 16, 2024, 12:40:17 pmAt least that would formally "bless" the fixes. See my earlier post. The last I heard it is being held up because some ARM issues (and we would want that fix to go in the distro version for times to come too) ---------------------------------------------------------------------- dbannon · 2024-05-16 10:59 Quote from: marcov on May 16, 2024, 12:48:02 pm.... held up because some ARM issues (and we would want that fix to go in the distro version for times to come too) Sure it would be great to support all the new hardware appearing. But right now, the release version of FPC does not support the current openssl on our main stream hardware. It did once but does not now. Davo ---------------------------------------------------------------------- 440bx · 2024-05-16 12:19 Quote from: marcov on May 16, 2024, 12:48:02 pmSee my earlier post. The last I heard it is being held up because some ARM issues (and we would want that fix to go in the distro version for times to come too) The part I am having a bit of a hard time understanding is that we're only talking about a 0.0.2 release.  I'd say that implicitly states there are no major new features in the release (I'd even consider it explicit).  I consider supporting a new CPU worth at least a 0.1 version increase (actually, personally I consider it worth a full point increase, supporting an additional CPU and corresponding platform(s) is no picnic to implement.) Psychologically, even a 0.0.2 release without any new features, only fixes would likely be welcome (and likely with some relief by some.) ---------------------------------------------------------------------- marcov · 2024-05-16 16:24 Quote from: 440bx on May 16, 2024, 02:19:52 pmThe part I am having a bit of a hard time understanding is that we're only talking about a 0.0.2 release.  I'd say that implicitly states there are no major new features in the release (I'd even consider it explicit).  I consider supporting a new CPU worth at least a 0.1 version increase (actually, personally I consider it worth a full point increase, supporting an additional CPU and corresponding platform(s) is no picnic to implement.) Afaik it is a feature (a marker in the binary placed by the compiler/linker) that is starting to get mandatory in newer distros or something like that. i.e. it is to avoid a regression on newer distros. ---------------------------------------------------------------------- zeljko · 2024-05-17 06:47 I cannot find any issue about 3.2.4 except this one https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 ... is there any issue opened about arm problem which blocks 3.2.4 ? ---------------------------------------------------------------------- marcov · 2024-05-17 07:48 I looked in my mail, and Florian described it as a "armhf abi tag issue" on March the 4th. FreeBSD also has abitags and those are in the RTL. I don't know why I got the relation to the linker, maybe from an earlier mail. Anyway I posted a mail on core pointing to this thread. ---------------------------------------------------------------------- zeljko · 2024-05-17 08:00 Maybe related to https://sourceware.org/bugzilla/show_bug.cgi?id=28848 ? ---------------------------------------------------------------------- marcov · 2024-05-17 10:47 Quote from: zeljko on May 17, 2024, 10:00:24 amMaybe related to https://sourceware.org/bugzilla/show_bug.cgi?id=28848 ? I don't know. But now I read that, I do remember somebody saying on a different (GCC related) forum that ARMv7 had been changed into a FPU less base target by default, and you now had to explicitly add some marker/parameters for the FPU to the target. I.e. just saying armv7 eabi doesn't mean implicitely HF anymore. ---------------------------------------------------------------------- damieiro · 2024-05-31 09:14 My apologies if it's a silly question. But if i understood well about releases, it seems that this is the block: - Platform destination: Arm But does the platform destination blocks languaje features? reprhasing the question: should not be languaje features and platform destinations different and not mutually blocking questions? (the languaje can advance with new features without having all platforms targeting it, with the most used should be ok) But i ask it without knowledge of what it could imply... ---------------------------------------------------------------------- marcov · 2024-05-31 11:13 The next release is a fixes release i.e. no new features. ---------------------------------------------------------------------- wfbhappy · 2024-06-02 03:43 fast ---------------------------------------------------------------------- ccrause · 2024-06-03 08:07 The machinery is moving again: Freeze of fixes for 3.2.4 by 9th June ---------------------------------------------------------------------- TRon · 2024-06-03 08:20 Does that freeze imply that the 3.2.4 release will (again) not contain a fix for #40701 I ask beforehand because it seems to be a problem for a lot of people so many questions will arise (again) when this is released without a fix for it. ---------------------------------------------------------------------- ccrause · 2024-06-03 09:17 Quote from: TRon on June 03, 2024, 10:20:47 amDoes that freeze imply that the 3.2.4 release will (again) not contain a fix for #40701 That issue appears to be specific to FPC 3.3.1. If the same issue is triggered with FPC 3.2.2 or current 3.2.3 (fixes), then it is a relevant concern to this specific fixes release. ---------------------------------------------------------------------- marcov · 2024-06-03 12:24 Quote from: ccrause on June 03, 2024, 11:17:01 amThat issue appears to be specific to FPC 3.3.1. If the same issue is triggered with FPC 3.2.2 or current 3.2.3 (fixes), then it is a relevant concern to this specific fixes release. Yes, that is what I understood too. ---------------------------------------------------------------------- TRon · 2024-06-03 14:11 As far as my knowledge goes it was reported by people on the forum with the release of Lazarus 3.2 as well, and according to that same knowledge that included the Lazarus fix for that issue (the original issue was two-fold, the FPC part still open) I would have to have a closer look to see if it (still) appears with latest Lazarus release (with 3.2.2 FPC release). Mind that as long as you do not install Lazarus in a restricted directory the issue will most probably never appear (never ran into it myself unless forced). ---------------------------------------------------------------------- wp · 2024-06-03 14:18 As far as laz.VirtualTreeView is concerned, the issue could be avoided by rearranging the units in interface and implementation sections. This is in Laz/main (and fixes, it was too late vor 3.4), and Laz/main now compiles fine with fpc 3.3.1. (https://gitlab.com/freepascal.org/l azarus/lazarus/-/commit/3635aa304475f4f66374d723c7fedf8309c8fac8). ---------------------------------------------------------------------- TRon · 2024-06-03 23:18 @wp, yes indeed (though in my memory it was already fixed because it was a re-introduced bug from way earlier). fwiw you can circumvent this particular vtv issue by installing Lazarus in a directory with enough access-rights so that the fallback to the config directory does not happen. The underlying issue is rebuilding the IDE and the compiler indicating the need for recompilation (while it shouldn't). Also easy enough to circumvent by turning off the checksum check but that is not how things are suppose to work  What I do not know is if any of the changes in trunk that caused the behaviour are going to be present in 3.2.4 in which case the issue will persist, hence the question. fwiw: I haven't kept a close eye to this particular issue as it was taking too long for my liking (and therefor used fixed hashes) so perhaps it has been (properly) addressed already but I haven't noticed any mention of it so far. ---------------------------------------------------------------------- PascalDragon · 2024-06-04 20:04 Quote from: TRon on June 04, 2024, 01:18:16 amWhat I do not know is if any of the changes in trunk that caused the behaviour are going to be present in 3.2.4 in which case the issue will persist, hence the question. No, they're are not, because they were very invasive changes that have no place in a fixes release. ---------------------------------------------------------------------- TRon · 2024-06-05 03:51 Thank you for clearing that up PascalDragon. ---------------------------------------------------------------------- marcov · 2024-06-05 07:21 Also, even in trunk the rearrangement of virtualtrees is a workaround, not a fix I think? ---------------------------------------------------------------------- zeljko · 2024-06-08 08:36 Yes, it's just workaround. ---------------------------------------------------------------------- 440bx · 2024-06-08 22:43 maybe I missed the obvious but... what is the issue (or issues) that are holding up the release of FPC v3.2.4 ? No matter how many times I read the posts in this thread I cannot manage to see the issue or issues responsible for the delay. A short, concise, clear and unequivocal answer would be greatly appreciated ... thank you. ---------------------------------------------------------------------- TRon · 2024-06-08 22:56 Quote from: 440bx on June 09, 2024, 12:43:21 amA short, concise, clear and unequivocal answer would be greatly appreciated ... thank you. arm target has/had some issues that needs to be addressed before a release can happen. afaik that is the only hold-up. ---------------------------------------------------------------------- 440bx · 2024-06-08 23:05 Quote from: TRon on June 09, 2024, 12:56:22 amarm target has/had some issues that needs to be addressed before a release can happen. afaik that is the only hold-up. Thank you TRon.  At least that is clear. ---------------------------------------------------------------------- zeljko · 2024-06-14 09:36 Is it possible to merge https://gitlab.com/freepascal.org/fpc/source/- /commit/f4cc2447a2c9b751c0c31b35dcd9b92e3fd07749 into fixes ? ---------------------------------------------------------------------- marcov · 2024-06-14 13:00 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 · 2024-06-14 17:45 MVC merged it ---------------------------------------------------------------------- dbannon · 2024-06-15 03:38 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   DefaultLibName = 'libfontconfig.so';      // is currently   DefaultLibName = 'libfontconfig.so.1';   // but should be like this ! Davo edit: typo ---------------------------------------------------------------------- renabor · 2024-07-02 13:43 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i sudo apt install libfontconfig-dev hope it's helpful ---------------------------------------------------------------------- Fred vS · 2024-07-02 16:46 Quote from: dbannon on June 15, 2024, 05:38:33 amAnton 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2024-07-03 01:16 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 · 2024-07-03 04:05 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 · 2024-07-03 11:57 Re-hello. Note that the patch: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2024-07-03 15:50 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 · 2024-07-03 16:12 Quote from: Thaddy on July 03, 2024, 05:50:24 pmVersioning 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). Quote from: Thaddy on July 03, 2024, 05:50:24 pmIf 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 · 2024-07-03 16:16 Fred, it is not taste. It is how it is done. Period. ---------------------------------------------------------------------- Fred vS · 2024-07-03 16:41 Quote from: Thaddy on July 03, 2024, 06:16:43 pmFred, 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 · 2024-07-03 17:05 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 · 2024-07-03 17:26 Quote from: Thaddy on July 03, 2024, 07:05:52 pmFred, 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 · 2024-07-03 17:46 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. ---------------------------------------------------------------------- Fred vS · 2024-07-03 17:58 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 · 2024-07-03 18:08 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 · 2024-07-03 18:23 Quote from: BSaidus on July 03, 2024, 08:08:01 pmHello, 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 · 2024-07-03 18:31 Quote from: Fred vS on July 03, 2024, 08:23:18 pmQuote from: BSaidus on July 03, 2024, 08:08:01 pmHello, 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 · 2024-07-03 19:27 Quote from: BSaidus on July 03, 2024, 08:31:02 pmQuote from: Fred vS on July 03, 2024, 08:23:18 pmQuote from: BSaidus on July 03, 2024, 08:08:01 pmHello, 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i    .....   if target_info.system in systems_openbsd then      DynamicLinker:='/usr/libexec/ld.so'     else if target_info.system in systems_netbsd then      DynamicLinker:='/usr/libexec/ld.elf_so'     else if target_info.system=system_x86_64_dragonfly then      DynamicLinker:='/libexec/ld-elf.so.2'     else if target_info.system=system_aarch64_freebsd then  // THIS IS MISSING    DynamicLinker:='/libexec/ld-elf.so.1'                                // THIS IS MISSING    else       DynamicLinker:='';  [EDIT] Recompiled fpc 3.3.1 for FreeBSD aarch64 with the fix: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i      else if target_info.system=system_aarch64_freebsd then  // THIS IS MISSING      DynamicLinker:='/libexec/ld-elf.so.1'                                // THIS IS MISSING  And it works now. ---------------------------------------------------------------------- BSaidus · 2024-07-03 20:49 Quote from: Fred vS on July 03, 2024, 09:27:16 pmQuote from: BSaidus on July 03, 2024, 08:31:02 pmQuote from: Fred vS on July 03, 2024, 08:23:18 pmQuote from: BSaidus on July 03, 2024, 08:08:01 pmHello, 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i    .....   if target_info.system in systems_openbsd then      DynamicLinker:='/usr/libexec/ld.so'     else if target_info.system in systems_netbsd then      DynamicLinker:='/usr/libexec/ld.elf_so'     else if target_info.system=system_x86_64_dragonfly then      DynamicLinker:='/libexec/ld-elf.so.2'     else if target_info.system=system_x86_64_freebsd then  // THIS IS MISSING    DynamicLinker:='/libexec/ld-elf.so.1'                                  // THIS IS MISSING    else       DynamicLinker:='';  YES ---------------------------------------------------------------------- dbannon · 2024-07-04 01:18 > 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i libthing.so     -> libthing.so.3libthing.so.1  -> libthing2.so.3libthing.so.2  -> libthing2.so.3libthing.so.3libthing2.so.3  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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function LibraryEnding() : string;begin    {$if defined(darwin) or defined (haiku) or defined(OpenBSD) }    result := '.so';    {$else}      {$if defined(MSWINDOWS)}    result := '.dll');    {$else}    {$if defined(LINUX) }    result := '.so.1';    {$endif}    {$endif}  {$endif}end; DefaultLibName = 'fontconfig' + LibraryEnding(); (untested) Room in there for all supported OS .... Davo ---------------------------------------------------------------------- BSaidus · 2024-07-04 08:15 Ah, I remember something, while trying to execute simple program, it require me linker from /lib, not /libexec ---------------------------------------------------------------------- marcov · 2024-07-04 09:06 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 itIt needs maintenance to have at least a number of possibilitiesAny submitted fixes should cover more than change the default to some momentarily most common configurationIt 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 · 2024-07-04 09:12 Quote from: dbannon on July 04, 2024, 03:18:12 amSummary, 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 · 2024-07-04 09:25 Quote from: marcov on July 04, 2024, 11:12:40 amIt 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 · 2024-07-04 11:38 Quote from: marcov on July 04, 2024, 11:12:40 am.... 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 · 2024-07-04 12:01 Quote from: dbannon on July 04, 2024, 01:38:31 pmUsing 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const{$ifdef linux}fontconfiglib: array[0..1] of string =                       ('libfontconfig.so.1','libfontconfig.so');{$else}// do the same for other Unix oses (need to check all os){$endif} varint1: integer;libname: string = ''; ...  for int1:= 0 to high(fontconfiglib) do begin  result:= loadlibrary(fontconfiglib[int1]);   if result <> 0 then begin   libname:= fontconfiglib[int1];   break;   end;  end; if libname <> '' then ...... ---------------------------------------------------------------------- marcov · 2024-07-04 12:17 Quote from: dbannon on July 04, 2024, 01:38:31 pmQuote from: marcov on July 04, 2024, 11:12:40 am.... 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 · 2024-07-04 12:41 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 ---------------------------------------------------------------------- Thaddy · 2024-07-04 12:43 Quote from: dbannon on July 04, 2024, 01:38:31 pmWell 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 · 2024-07-05 00:17 Sorry Thaddy, I am not sure you are following the conversation. Quote from: Thaddy on July 04, 2024, 02:43:25 pmIf 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% Quote from: Thaddy on July 04, 2024, 02:43:25 pmIF 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 ? Quote from: Thaddy on July 04, 2024, 02:43:25 pmThe 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 · 2024-07-11 11:32 Quote from: FPK on October 25, 2021, 07:57:25 am 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i "Content- Type: text/plain; charset=UTF-8\n" are needed, and the file encodings changed to UTF-8 Regards, Peter ---------------------------------------------------------------------- dbannon · 2024-07-12 00:34 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 · 2024-07-12 10:11 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 · 2024-07-13 11:30 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. putCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  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 · 2024-07-13 14:39 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 · 2024-07-13 16:00 I don't have a real deep opinion Using the name without subnr (the symlink) requires a -dev packageusing 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 · 2024-07-13 21:19 Quote from: Thaddy on July 13, 2024, 04:39:02 pmI 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 · 2024-07-14 08:28 Quote from: marcov on July 13, 2024, 01:30:51 pm.... at least in trunk, try the following: 2. putCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  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: thaddyI 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: MarkMLlThis 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 · 2024-07-14 10:42 Quote from: dbannon on July 14, 2024, 10:28:54 amQuote from: marcov on July 13, 2024, 01:30:51 pm.... at least in trunk, try the following: 2. putCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  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 · 2024-07-14 12:03 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 · 2024-07-15 10:12 Quote from: Thaddy on July 04, 2024, 02:43:25 pmIf you need versioning you are doing something very wrong. Like here ?: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // t_linux.pas... {$ifdef m68k}  const defdynlinker='/lib/ld.so.1';{$endif m68k} {$ifdef i386}  const defdynlinker='/lib/ld-linux.so.2';{$endif} {$ifdef x86_64}  const defdynlinker='/lib64/ld-linux-x86-64.so.2';{$endif x86_64} {$ifdef sparc}  const defdynlinker='/lib/ld-linux.so.2';{$endif sparc} {$ifdef powerpc}  const defdynlinker='/lib/ld.so.1';{$endif powerpc} {$ifdef powerpc64}  const defdynlinkerv1='/lib64/ld64.so.1';  const defdynlinkerv2='/lib64/ld64.so.2';  var defdynlinker: string;{$endif powerpc64} {$ifdef arm}{$ifdef FPC_ARMHF}  const defdynlinker='/lib/ld-linux-armhf.so.3';{$else FPC_ARMHF}{$ifdef FPC_ARMEL}  const defdynlinker='/lib/ld-linux.so.3';{$else FPC_ARMEL}  const defdynlinker='/lib/ld-linux.so.2';{$endif FPC_ARMEL}{$endif FPC_ARMHF}{$endif arm} {$ifdef aarch64}const defdynlinker='/lib/ld- linux-aarch64.so.1';{$endif aarch64} {$ifdef mips}  const defdynlinker='/lib/ld.so.1';{$endif mips} {$ifdef sparc64}  const defdynlinker='/lib64/ld-linux.so.2';{$endif sparc64} {$ifdef riscv32}  const defdynlinker_generic='/lib32/ld.so.1';  const defdynlinker_soft_float='/lib/ld-linux-riscv32-ilp32.so.1';  const defdynlinker_single_float='/lib/ld-linux-riscv32-ilp32f.so.1';  const defdynlinker_double_float='/lib/ld-linux-riscv32-ilp32d.so.1';  { const defdynlinker_quad_float='/lib/ld-linux-riscv32-ilp32q.so.1'; not yet in ABI list }  var defdynlinker : string;{$endif riscv32} {$ifdef riscv64}  const defdynlinker_soft_float='/lib/ld-linux- riscv64-lp64.so.1';  const defdynlinker_single_float='/lib/ld-linux- riscv64-lp64f.so.1';  const defdynlinker_double_float='/lib/ld-linux- riscv64-lp64d.so.1';  { const defdynlinker_quad_float='/lib/ld-linux- riscv64-lp64q.so.1'; not yet in ABI list }  var defdynlinker : string;{$endif riscv64} {$ifdef xtensa}  const defdynlinker='/lib/ld.so.1';{$endif xtensa} {$ifdef loongarch64}  const defdynlinker='/lib64/ld-linux-loongarch-lp64d.so.1';{$endif loongarch64}... Apartheid ? ---------------------------------------------------------------------- marcov · 2024-07-15 10:55 Quote from: Fred vS on July 15, 2024, 12:12:13 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 · 2024-07-15 11:19 Quote from: marcov on July 15, 2024, 12:55:07 pmThat 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // prthread.inc  PThreadDLL:=DlOpen('libpthread.so.0',RTLD_LAZY);...// libpccre2_16.pp {$IFDEF LINUX}    pcrelibname = 'libpcre2-16.so.0';  {$ELSE}...// libvlc.pp{$ifdef unix}  libname = 'libvlc.so.5';{$else}...// lua.pas{$IFDEF UNIX}  LUA_NAME = 'liblua.so.5.1';  LUA_LIB_NAME = 'liblua.so.5.1';{$ELSE}...// glu.pp  GLU_LIB = 'libGLU.so.1';...// pxlib.pp  pxlibraryname='libpx.so.0'; { Default name }...// sdl.pp SDLLibName = 'libSDL-1.2.so.0';...// sdl_image.pp  SDL_ImageLibName = 'libSDL_image-1.2.so.0';...// and much others. ---------------------------------------------------------------------- TRon · 2024-07-15 11:23 Quote from: Fred vS on July 15, 2024, 01:19:24 pmThose are bad too I suppose: Dynamic vs static. Personally I think it is bad but generally it is understandable. ---------------------------------------------------------------------- zeljko · 2024-07-21 07:01 Aleluyah https://gitlab.com/freepascal.org/fpc/source/- /commits/release_3_2_4-branch?ref_type=heads ---------------------------------------------------------------------- BrunoK · 2024-07-21 09:55 Please, if not done, include: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  packages/fcl-db/src/base/sqlscript.pp | 1 + 1 file changed, 1 insertion(+) diff --git a/packages/fcl-db/src/base/sqlscript.pp b/packages/fcl-db/src/base/sqlscript.ppindex afc1944..79495e4 100644--- a/packages/fcl-db/src/base/sqlscript.pp+++ b/packages/fcl- db/src/base/sqlscript.pp@@ -509,6 +509,7 @@ begin   FSkipStackIndex:=0;   Faborted:=False;   FLine:=1;+  FCol:=1;   DefaultDirectives;   Repeat     NextStatement();I've lost quite a few hours because of that. ---------------------------------------------------------------------- zeljko · 2024-07-21 19:17 @BrunoK better would be to open issue at fpc bugtracker. ---------------------------------------------------------------------- BrunoK · 2024-07-21 20:00 Quote from: zeljko on July 21, 2024, 09:17:45 pm@BrunoK better would be to open issue at fpc bugtracker. As far as I know, the bugtracker is for trunk. This bug is corrected in trunk. Here we are considering 3.2.4 ---------------------------------------------------------------------- zeljko · 2024-07-21 20:02 Can you write revision id ? ---------------------------------------------------------------------- BrunoK · 2024-07-21 20:20 Quote from: zeljko on July 21, 2024, 10:02:47 pmCan you write revision id ? Nothing I could find in the history. It has been corrected, I dont know when or eventualy my local Git copy of 3.2.2 is damaged. ---------------------------------------------------------------------- dsiders · 2024-07-21 20:38 Quote from: zeljko on July 21, 2024, 10:02:47 pmCan you write revision id ? https://gitlab.com/freepascal.org/fpc/source/- /commit/672f90bf40cc6fe8d3dbb2be0402e41d7113fc00 Issue #39356. Cherry-picked in https://gitlab.com/freepascal.org/fpc/source/- /commit/0376cb7ae8d10bcf3ad754e0f2539c462b5cfdd4 7 months ago. ---------------------------------------------------------------------- zeljko · 2024-07-21 20:43 So it is there already, nothing to be done. ---------------------------------------------------------------------- BrunoK · 2024-07-22 09:03 Quote from: dsiders on July 21, 2024, 10:38:27 pmThanks you for the references, couldn't find them. Couldn't figure out the search words. ---------------------------------------------------------------------- dsiders · 2024-07-22 16:56 Quote from: BrunoK on July 22, 2024, 11:03:00 amQuote from: dsiders on July 21, 2024, 10:38:27 pmThanks you for the references, couldn't find them. Couldn't figure out the search words. I used git blame to find the commits for that line of code instead of searching the issue list. ---------------------------------------------------------------------- dbannon · 2024-07-23 11:08 If anyone is interested in this, perhaps it belongs in a new thread ? Quote from: marcov on July 13, 2024, 01:30:51 pmApropos 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. putCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  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. Thanks Marcov.  I have been travelling but finally got around to building a FPC without my patch to test your idea. Not sure where 'libfontconfig.so.666' comes from, but applying your logic to 'libfontconfig.so.1' almost works !  But not quite. While it is possible to preempt libfontconfig.pp's attempt to load "libfontconfig.so"  by calling LoadFontConfigLib('libfontconfig.so.1', false) earlier, its not useful because (eg) fptty.pp later calls LoadFontConfigLib('') and that triggers an EInOutException when it finds the library is already loaded. fptty.pp sees the Exception and refuses to proceed. That Exception appears to be inappropriate in my view. I have tested proceeding without an Exception if the library is already loaded and it worked, on my system, as it should. That is, however, a far more obtrusive change than the earlier suggested one. So, setting the DefaultLibName, for Linux, to 'libfontconfig.so.1' is still my recommendation.      Davo PS : I will add my notes to the bug report if no one disputes them, save someone else from starting from scratch. ---------------------------------------------------------------------- ALLIGATOR · 2024-09-03 14:30 I see in the 2020 announcement that this feature is not planned to be included in the 3.2 branch, but maybe something has changed in 4 years and there is a chance to include it in 3.2.4  ? Via modeswitch ---------------------------------------------------------------------- marcov · 2024-09-03 15:16 No major language features in 3.2.x. That is for the next major version. (3.4 or 4.0) ---------------------------------------------------------------------- BSaidus · 2024-11-27 17:23 Hello  . So, what about the release of the 3.2.4 version of FPC. We are waiting. I do not want to ask but, I'll ask at my own risks. ---------------------------------------------------------------------- marcov · 2024-11-27 18:20 I haven't heard any news about the release status for a while now. ---------------------------------------------------------------------- BSaidus · 2025-01-17 13:27 Hello. No news about the release !? ---------------------------------------------------------------------- lainz · 2025-01-17 13:29 4 years ---------------------------------------------------------------------- PascalDragon · 2025-01-18 16:26 Quote from: BSaidus on January 17, 2025, 02:27:14 pmHello. No news about the release !? We are in preparation of the RC. ---------------------------------------------------------------------- Fred vS · 2025-01-18 17:09 Quote from: PascalDragon on January 18, 2025, 05:26:29 pmQuote from: BSaidus on January 17, 2025, 02:27:14 pmHello. No news about the release !? We are in preparation of the RC. Will there be a version for OpenBSD that works with their latest releases ? ---------------------------------------------------------------------- AlexTP · 2025-01-20 08:25 Can I ask you to use _latest_ TRegExpr for the 3.2.4? branch 'release_3_2_4' has too old regexpr.pas: https://gitlab.com/freepascal.org/fpc/source/-/blob/release_3_2_4- branch/packages/regexpr/src/regexpr.pas   REVersionMajor = 0;   REVersionMinor = 987; while FPC Git main has   REVersionMajor = 1;   REVersionMinor = 182; while last Sorokin's version https://github.com/andgineer/TRegExpr/blob/master/src/regexpr.pas has   REVersionMajor = 1;   REVersionMinor = 189; ---------------------------------------------------------------------- PascalDragon · 2025-01-20 21:29 Quote from: Fred vS on January 18, 2025, 06:09:48 pmQuote from: PascalDragon on January 18, 2025, 05:26:29 pmQuote from: BSaidus on January 17, 2025, 02:27:14 pmHello. No news about the release !? We are in preparation of the RC. Will there be a version for OpenBSD that works with their latest releases ? Does main work on current OpenBSD? If so, can you point out the corresponding revisions that fixed this? They can be merged for after RC1 then if they aren't already... Quote from: AlexTP on January 20, 2025, 09:25:09 amCan I ask you to use _latest_ TRegExpr for the 3.2.4? The RC is fixed. There will be no more changes to it. For post RC1 we'll have to see. ---------------------------------------------------------------------- Fred vS · 2025-01-20 22:27 Quote from: PascalDragon on January 20, 2025, 10:29:16 pmDoes main work on current OpenBSD? If so, can you point out the corresponding revisions that fixed this? They can be merged for after RC1 then if they aren't already... No, sadly main does not work on OpenBSD 75 and 76. I posted that message to OpenBSD forum but they stop to give fpc since version 75 because of incompatibility: https://daemonforums.org/showthread.php?p=75175#post75175 There is long topic in Lazarus forum about the problem initially about Lazarus but it ended about fpc. https://forum.lazarus.freepascal.org/index.php/topic,67536.0.html There is also a fpcupdeluxe issue about this: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/issues/722 ---------------------------------------------------------------------- marcov · 2025-01-21 08:35 Quote from: Fred vS on January 20, 2025, 11:27:29 pmThere is long topic in Lazarus forum about the problem initially about Lazarus but it ended about fpc. Don Alfredo seems to say in that thread that main works on 7.6. ---------------------------------------------------------------------- korba812 · 2025-01-21 11:27 Please consider adding COM-related patches to new release and, if possible, to fixes branch: https://gitlab.com/freepascal.org/fpc/source/-/issues/41009 https://gitlab.com/freepascal.org/fpc/source/-/issues/41005 https://gitlab.com/freepascal.org/fpc/source/- /commit/ac510d391f9d784a00275836715a25a41331460f ---------------------------------------------------------------------- Fred vS · 2025-01-21 13:07 Quote from: marcov on January 21, 2025, 09:35:52 amQuote from: Fred vS on January 20, 2025, 11:27:29 pmThere is long topic in Lazarus forum about the problem initially about Lazarus but it ended about fpc. Don Alfredo seems to say in that thread that main works on 7.6. Sadly it is not working, see: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/issues/722 ---------------------------------------------------------------------- Thaddy · 2025-01-21 13:17 Quote from: korba812 on January 21, 2025, 12:27:05 pmPlease consider adding COM-related patches to new release and, if possible, to fixes branch: https://gitlab.com/freepascal.org/fpc/source/-/issues/41009 https://gitlab.com/freepascal.org/fpc/source/-/issues/41005 https://gitlab.com/freepascal.org/fpc/source/- /commit/ac510d391f9d784a00275836715a25a41331460f 3.2.4 is about fixing bugs. The first two are not bugs. Only the third one should be a candidate. The other two ? Did you test against Delphi? Seems more a feature request and that won't happen in a point release. ---------------------------------------------------------------------- Thaddy · 2025-01-21 13:32 Just release. Other than what is already known at least on my platforms ( quite a lot) I haven't found anything serious. Is the problem just release nanament? Surely one minor platform can not Withhold a point release! ---------------------------------------------------------------------- Fred vS · 2025-01-22 02:16 Some news from OpenBSD 76 front. I installed a fresh release of OpenBSD 76,  from scratch (and so not a upgrade from 75). The binary from there: https://downloads.freepascal.org/fpc/snapshot/f ixes_3_2/x86_64-openbsd/  (thanks to BSaidus) can compile and the apps are running.  Only needed to create synlink from the needed libc.so.86.0 and libpthread,so.57.0 (not sure by memory about the version)  in fpc to the installed version in OpenBSD 76. So to resume, it seems that OpenBSD 75 and his upgrade is not for fpc. (but OpenBSD 74 is ok) But for compiling fpc himself on OpenBSD 76, using last fpupdeluxe or from gmake makefile from fpc, the compilation fails. It would be interesting to know how those binaries were compiled from https://downloads.freepascal.org/fpc/snapshot. ---------------------------------------------------------------------- BSaidus · 2025-01-22 15:19 Quote from: Fred vS on January 22, 2025, 03:16:53 amSome news from OpenBSD 76 front. I installed a fresh release of OpenBSD 76,  from scratch (and so not a upgrade from 75). The binary from there: https://downloads.freepascal.org/fpc/snapshot/f ixes_3_2/x86_64-openbsd/  (thanks to BSaidus) can compile and the apps are running.  Only needed to create synlink from the needed libc.so.86.0 and libpthread,so.57.0 (not sure by memory about the version)  in fpc to the installed version in OpenBSD 76. So to resume, it seems that OpenBSD 75 and his upgrade is not for fpc. (but OpenBSD 74 is ok) But for compiling fpc himself on OpenBSD 76, using last fpupdeluxe or from gmake makefile from fpc, the compilation fails. It would be interesting to know how those binaries were compiled from https://downloads.freepascal.org/fpc/snapshot. Thank you Fred for this post. I think the maintainer of the builds is Pierre Muller (do not know his email), if you can get his email to contact it. To the release team, Please consider updating the FPC for OpenBSD plateforme (i386, amd64). Thank you. Yes, I confim that the maintainer is Pierre Muller https://downloads.freepascal.org/fpc/snapshot/fixes_3_2/i386- openbsd/README-fpc-3.2.3.i386-openbsd.built.on.x86_64-linux ---------------------------------------------------------------------- AlexTP · 2025-01-23 17:06 Can you apply this fix, made in Git 2 years ago? https://gitlab.com/freepascal.org/fpc/source/- /commit/48b97514193933e20c354a459c1cb37ca8edeb6c It fixes also this issue https://gitlab.com/freepascal.org/fpc/source/-/issues/41117 ---------------------------------------------------------------------- marcov · 2025-01-23 20:42 To my best knowledge, the last merge was September 23th: https://gitlab.com/freepascal.org/fpc/source/-/commits/release_3_2_4- branch ---------------------------------------------------------------------- PascalDragon · 2025-01-23 21:34 Quote from: korba812 on January 21, 2025, 12:27:05 pmPlease consider adding COM-related patches to new release and, if possible, to fixes branch: https://gitlab.com/freepascal.org/fpc/source/-/issues/41009 https://gitlab.com/freepascal.org/fpc/source/-/issues/41005 These are not even in main yet, so it's very unlikely that they be in 3.2.4. Quote from: korba812 on January 21, 2025, 12:27:05 pmhttps://gitlab.co m/freepascal.org/fpc/source/- /commit/ac510d391f9d784a00275836715a25a41331460f That can maybe be merged after the RC. Quote from: AlexTP on January 23, 2025, 06:06:59 pmCan you apply this fix, made in Git 2 years ago? https://gitlab.com/freepascal.org/fpc/source/- /commit/48b97514193933e20c354a459c1cb37ca8edeb6c That can maybe also be merged after the RC. Quote from: Thaddy on January 21, 2025, 02:32:36 pmJust release. Other than what is already known at least on my platforms ( quite a lot) I haven't found anything serious. Is the problem just release nanament? Surely one minor platform can not Withhold a point release! Yes, the issue is release management, because major targets are still missing. ---------------------------------------------------------------------- cpicanco · 2025-01-26 22:17 Hi everyone, great work! You’re all awesome! I was testing Lazarus RC2 (https://forum.lazarus.freepascal.org/index.php/topic,69820.60.html) and encountered an issue with a project that compiles without problems in the trunk but fails to compile in RC2 due to differences between FPC trunk and FPC 3.2.2. Would you recommend addressing these issues for FPC 3.2.4? 1) In Generics.Default, FPC trunk uses const (instead of constref) in TComparer.Compare: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   TComparer = class(TInterfacedObject, IComparer)  public    class function Default: IComparer; static;    function Compare(constref ALeft, ARight: T): Integer; virtual; abstract; overload;     class function Construct(const AComparison: TOnComparison): IComparer; overload;    class function Construct(const AComparison: TComparisonFunc): IComparer; overload;  end; 2) FPC 3.2.2 do not propagate String helpers for ShortString's. Hence: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // one may change thisTObject.ClassName.Replace('T', ''); // to thisString(TObject.ClassName).Replace('T', ''); 3) I am getting an internal error 200510032, and also "Undefined symbol: .Lj2139" when trying to use .ToInteger helper with a specialized TDictionary: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program rc2test; {$mode objfpc}{$H+} uses  {$IFDEF UNIX}  cthreads,  {$ENDIF}  Classes,  SysUtils,  Generics.Collections;   procedure DoIt;  type    TMyDictionary = specialize TDictionary;   var    MyDictionary : TMyDictionary;   begin    MyDictionary := TMyDictionary.Create;    try       MyDictionary.Add('Key', '1');       WriteLn(MyDictionary['Key'].ToInteger);    finally       MyDictionary.Free;    end;  end; begin  DoIt;  ReadLn;end. I managed to compile it doing some refactoring: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var  s1 : string; begin  s1 := MyDictionary['Numeric'];  WriteLn(s1.ToInteger);end; 4) TEvent.Create, from syncobjs unit is not overloaded in FPC 3.2.2, so one must create it explicitly. FPC 3.3.1 will call "BasicEventCreate(nil, True,False,'')" when using the overloaded constructor. ---------------------------------------------------------------------- PeterBB · 2025-03-30 12:12 I've just noticed that there is a release candidate (beta) here https://downloads.freepascal.org/fpc/beta/3.2.4-rc1/ ---------------------------------------------------------------------- BSaidus · 2025-03-30 16:26 , there is no OpenBSD port ? What happen ? ---------------------------------------------------------------------- Thaddy · 2025-03-30 17:02 Quote from: BSaidus on March 30, 2025, 06:26:47 pm , there is no OpenBSD port ? What happen ? See the quote from PascalDragon above. Major targets are missing. (in the sense that they are not pre-built, but you can build 3.2.4 from source) ---------------------------------------------------------------------- Fred vS · 2025-03-30 17:21 Quote from: BSaidus on March 30, 2025, 06:26:47 pm , there is no OpenBSD port ? What happen ? Here: https://downloads.freepascal.org/fpc/beta/3.2.3/3.2.4/ But 2 years old and not working on last OpenBSD. ---------------------------------------------------------------------- BSaidus · 2025-03-30 20:43 Quote from: Thaddy on March 30, 2025, 07:02:32 pmQuote from: BSaidus on March 30, 2025, 06:26:47 pm , there is no OpenBSD port ? What happen ? See the quote from PascalDragon above. Major targets are missing. (in the sense that they are not pre-built, but you can build 3.2.4 from source) Why not building them ? what is the reasons ? ---------------------------------------------------------------------- PascalDragon · 2025-04-01 19:23 Quote from: BSaidus on March 30, 2025, 10:43:10 pmWhy not building them ? what is the reasons ? Because it needs someone to build (and test) them. If none of the devs has a suitable machine (be it physical or VM) then one can't simply build one. ---------------------------------------------------------------------- Alexx2000 · 2025-06-07 12:19 The current situation is a very sad. The bug-fix release can't be released 4 years! To an outside observer, it looks like the project is dead. If some platform does not have a maintainer then simply don't release a binary builds for it. ---------------------------------------------------------------------- Fred vS · 2025-06-07 13:40 Quote from: Alexx2000 on June 07, 2025, 02:19:22 pmThe current situation is a very sad. The bug-fix release can't be released 4 years! To an outside observer, it looks like the project is dead. If some platform does not have a maintainer then simply don't release a binary builds for it. For clang, gcc, Delphi, their release frequency is 6 months. https://github.com/clangd/clangd/wiki/Release-cycle https://gcc.gnu.org/develop.html https://en.wikipedia.org/wiki/History_of_Delphi_(software) But I admit, as a project maintainer myself, producing releases isn't the most exciting part of the job and requires a lot of work. It's a bit like vehicle inspections (or university exams): it's boring to do but feels so good when it's done. ---------------------------------------------------------------------- Fred vS · 2025-06-07 14:05 And regarding the frequency of publishing releases and the different sensations associated with developing these releases, it's our human nature, condemned to follow Sisyphus's journey to the end. https://en.wikipedia.org/wiki/The_Myth_of_Sisyphus Amen. ---------------------------------------------------------------------- BSaidus · 2025-06-08 10:31 Quote from: Alexx2000 on June 07, 2025, 02:19:22 pmThe current situation is a very sad. The bug-fix release can't be released 4 years! To an outside observer, it looks like the project is dead. If some platform does not have a maintainer then simply don't release a binary builds for it. Hello, I do not agree with you @Alexx2000. There are many FPC users that works in different platforms and they use the FPC compiler well for there needs, but they do not have enough knowledge to help in FPC compiler development. So, I'm agree with the FPC dev team. The slogan of FPC is, write once & compile anywhere, So It must then work everywhere. ---------------------------------------------------------------------- PeterBB · 2025-06-08 10:45 Quote from: PascalDragon on January 23, 2025, 10:34:10 pm .... because major targets are still missing. Hi, Does anyone know what targets are missing? Cheers, Peter ---------------------------------------------------------------------- Alexx2000 · 2025-06-08 11:10 Quote from: BSaidus on June 08, 2025, 12:31:03 pmHello, I do not agree with you @Alexx2000. Hi, What you suggest, wait forever? If someone build a binary package later then it can be uploaded later, I don't see a problem here. ---------------------------------------------------------------------- BSaidus · 2025-06-08 11:18 Quote from: Alexx2000 on June 08, 2025, 01:10:51 pmQuote from: BSaidus on June 08, 2025, 12:31:03 pmHello, I do not agree with you @Alexx2000. Hi, What you suggest, wait forever? If someone build a binary package later then it can be uploaded later, I don't see a problem here. Hi Alexx2000, I think I maybe a dis-synchronization in this situation. Imaging someone building package later with some fixes the the Release ones do not contains. ---------------------------------------------------------------------- Wings2018 · 2025-08-27 14:25 Hello team, As I'm currently facing GDB-problems using FPC 3.2.2 (GDB v7.2) I wonder which GDB-version will get linked to the upcoming FPC 3.2.4? I noticed GDB v16.2 is the most recent one, but CoPilot also told me a GDB v11.x or v12.x might be better to link to FPC. Am I too late to request a more recent GDB-version to be linked to FPC 3.2.4? Of course, not sure if it will solve my problems, but better safe than sorry ---------------------------------------------------------------------- 440bx · 2025-08-27 15:26 Quote from: Wings2018 on August 27, 2025, 04:25:57 pmAs I'm currently facing GDB-problems using FPC 3.2.2 (GDB v7.2) I wonder which GDB- version will get linked to the upcoming FPC 3.2.4? Any reason why you don't use FpDebug instead of GDB ? ... FpDebug is quite good now and odds are reasonably good it does what you need. ---------------------------------------------------------------------- Thaddy · 2025-08-27 18:07 Quote from: Wings2018 on August 27, 2025, 04:25:57 pmAs I'm currently facing GDB-problems using FPC 3.2.2 (GDB v7.2) I wonder which GDB- version will get linked to the upcoming FPC 3.2.4? I noticed GDB v16.2 is the You can use GDB as GDB/MI, which is the recommended way. Hard linking libgdb is not recommended for quite some time and afaik it is no longer supported. 3.2.2 uses GDB/MI, so if the problems arise from older code, or older debug practises, change that. The remark made about fpdebug is correct: it's good. So: use GDB/MI, or recommended:fpdebug, do not link libgdb anymore. ---------------------------------------------------------------------- Wings2018 · 2025-08-27 18:45 Hello 440bx and Thaddy, There's no specific reason to not use fpdebug, I simply didn't start with it yet, and I'm also no experienced gdb-user. I'll find out about fpdebug and see if it supports me in solving my problem, thanks to both of you. ---------------------------------------------------------------------- Martin_fr · 2025-08-27 21:44 Debugger depends on environment. FPC (the compiler) does not have any bindings to any gdb or other debugger. FP (the FPC IDE) use gdb. It used to be libgdb, but now on most targets supposedly is just a gdb instance. If a gdb instance, then it may be possible (but I do not know) to substitute the gdb exe with a different version. That said, newer isn't always better, but a matter of trial and error. All the rest about debugger, is not FPC related. FPC (the compiler) just provides debug info. => OFF TOPIC The Lazarus IDE comes with FpDebug (for Linux and Windows, and only INTEL/AMD CPU). For the rest it is gdb. On Linux it uses what is installed by the repo. On Window it still ships an old one, but if you have a newer, well test it. On Mac, it uses a combination of LLDB+FpDebug (even with the M CPUs).