Re: [fpc-pascal] please where is fpc-3.2.0rc1.arm64-linux
Am 16.05.2020 um 11:53 schrieb Mgr. Janusz Chmiel via fpc-pascal: Dear specialists, Please is there some precompiled Linux ARM64 Binary of fpc-3.2.0rc1? Because I can only find ARM not ARM64 Bit precompiled binary. May be, that compiler is stored on some FTP site, but I have analysed ftp.freepascal.org and I did not found. Thank you for yours advice. ARM64 is correctly called AArch64, thus you can find it here: ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/aarch64-linux/ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] please where is fpc-3.2.0rc1.arm64-linux
Dear specialists, Please is there some precompiled Linux ARM64 Binary of fpc-3.2.0rc1? Because I can only find ARM not ARM64 Bit precompiled binary. May be, that compiler is stored on some FTP site, but I have analysed ftp.freepascal.org and I did not found. Thank you for yours advice. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimizing code generation fpc (lazarus)?
On Sun, 17 May 2020, Bo Berglund via fpc-pascal wrote: ADDING ANOTHER QUESTION: Is there a way to find out which functions in a particular unit are called from the other units in the project? Sort of an expanded list of "dependencies"... The lazarus IDE can give you this information. It can be that you need the cody package installed, but this is how it works: Click right on the function declaration/implementation, select 'find' and then 'Find identifier references'. The IDE will then show you where a particular function is used. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimizing code generation fpc (lazarus)?
On 17/05/2020 11:18, Bo Berglund via fpc-pascal wrote: > So now I wonder if there is a way to compile the application where the > compiler will not touch functions that are not used in the current > project? No. > ADDING ANOTHER QUESTION: > > Is there a way to find out which functions in a particular unit are > called from the other units in the project? When compiles, you can tell the linker to generate a linker map with the -Xm parameter, and then you can see all the (mangled) names of the referenced symbols (variables, functions, rtti, internally generated constants, ...). I'm sure Delphi can also generate a linker map with that information. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimizing code generation fpc (lazarus)?
On Sun, 17 May 2020 11:15:17 +0200, Bo Berglund via fpc-pascal wrote: Maybe a stupid question, but... I am struggling with porting a Windows service application written with D7/D2007 back in 2004-2006 or so. I need to get it moved to Linux because of Windows 10 issues. Now I am handling a lot of errors from a "CommonFuncs" unit that is used in many different applications including this one. It contains a whole lot of functions that all work fine in Windows from Delphi. Looks like it is a unit that has collected a lot of very special functions over the years... When compiling from Lazarus I get a lot of errors thrown from functions not used by the application I am porting So now I wonder if there is a way to compile the application where the compiler will not touch functions that are not used in the current project? As it is now I am slooowly working my way through a mass of functions that are not used in order to ifdef away parts of the code and finding FPC equivalents for others. But it would be so much easier if the compiler could disregard functions that are not called in the project and therefore not try to compile them at all. Or is this impossible due to the way the compile/linking is working? ADDING ANOTHER QUESTION: Is there a way to find out which functions in a particular unit are called from the other units in the project? Sort of an expanded list of "dependencies"... -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Optimizing code generation fpc (lazarus)?
Maybe a stupid question, but... I am struggling with porting a Windows service application written with D7/D2007 back in 2004-2006 or so. I need to get it moved to Linux because of Windows 10 issues. Now I am handling a lot of errors from a "CommonFuncs" unit that is used in many different applications including this one. It contains a whole lot of functions that all work fine in Windows from Delphi. Looks like it is a unit that has collected a lot of very special functions over the years... When compiling from Lazarus I get a lot of errors thrown from functions not used by the application I am porting So now I wonder if there is a way to compile the application where the compiler will not touch functions that are not used in the current project? As it is now I am slooowly working my way through a mass of functions that are not used in order to ifdef away parts of the code and finding FPC equivalents for others. But it would be so much easier if the compiler could disregard functions that are not called in the project and therefore not try to compile them at all. Or is this impossible due to the way the compile/linking is working? -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
On Sat, 16 May 2020 23:24:34 +0100, Graeme Geldenhuys wrote: >> Well the simplest way to get Indy10 into Lazarus is via Online Package >> Manager! > >Do they (whoever it might be) keep it up to date with the lastest Indy? I believe that it is actually Remy Lebeau who is doing that (I might be wrong).. In any case I received Indy 10.6.2 when I installed through OPM from Lazarus 2.0.8 on Windows. >> it is a rather steep climb since Indy10 is entirely blocking and the >> Delphi components were event driven. > >Indy devs explain it here. Blocking is not evil. > > https://www.swissdelphicenter.ch/en/showarticle.php?id=4 Yes, I know that it is not evil, but if you are stuck with a rather big Delphi application that is proven to work with the TServerSocket and using events to handle "everything" then it is much more difficult to turn to Indy during porting to FPC and then on to Linux... As you might have seen in various posts I have made recently I am trying to port a Windows service application written in Delphi7/Delphi2007 running on Windows to FPC/Lazarus in order to then move on to Linux. I have worked my way through it in Delphi 2007 to add ifdefs in a lot of places in order to prepare for the conversion into Lazarus and now I am in Lazarus trying to weed out the remaining issues. Not close yet... But it seems like my use of LNet in any case has been accepted by FPC/Lazarus as a replacement for TServerSocket. -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Sun, 17 May 2020, Noel Duffy via fpc-pascal wrote: On 17/05/20 3:00 am, Michael Van Canneyt wrote: On Sat, 16 May 2020, Michael Van Canneyt wrote: On Sat, 16 May 2020, Jonas Maebe wrote: On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). I will check. I never use range checking, so that could have easily escaped me. Fixed 2 occurrences of a range check. Looking at the code in SVN, I spotted a couple of still extant references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's possible to trigger range check errors for them. All s6_addr16s should be u6_addr16s. If you try parsing an address like '::' it will hit this part of the code. Sorry for the screw-up. Normally I religiously use range checks in my own code, but it completely went out of my head when working on this. That's what you get when communication with someone who doesn't use them: It's contagious ;-) I'll have a look. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
