Re: [fpc-pascal] FPCMake and Makefile.fpc question
On Wed, May 6, 2020 at 8:03 AM Sven Barth via fpc-pascal wrote: > Not in the makefile.fpc, That is unfortunate. > but fpcmake allows you to pass a list of supported targets (usually -Tall is > used to allow all targets), but you'd need to pick each one. This does mean > however that everyone that wants to try a target that's not supported has to > generate the makefile (I don't know if Lazarus only has the one compared to > FPC). > For example officially Lazarus doesn't support powerpc-darwin anymore, but > one could probably still use it there with some fixes (I should really test > that...) I would at least want to weed out targets we definitively do not support like embedded platforms and DOS. But in the end that's up to the Lazarus devs. I just wanted to know how that could be done. Thanks @all for the info. -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
Hi, On Wed, 6 May 2020, Noel Duffy via fpc-pascal wrote: > Testing would also have to be fairly rigorous to make sure all the > different formats are handled correctly. I've already done some work to > make it easy to compare StrToHostAddr6's output to that of inet_pton in > the C library, so this would at least provide a good method to quickly > spot problems. > > So I guess the question is, is it worth the effort to make > StrToHostAddr6 RFC4291 compliant? Is that something the FPC team would > want, Definitely yes. FPC is not a commercial "product", it's an open source project, and contributions like this are the whole idea behind open source, and makes projects like FPC actually viable. Note that the code you're looking into is very old (almost 15 years old), and was a contributed code in the first place, not written by the FPC team (see SVN r939). And this also means it actually predates the RFC you refer to. :) So it definitely needs an overhaul. > or do they just not use the sockets unit? As much as we use the compiler and associated libraries ourselves, we can't cover every use case, or find every bug. A lot of packages are there for completeness, or because someone submitted it, or for compatibility with Delphi, not because we necessarily use it ourselves. So if you find weak spots like this where you feel you can do better, do it and submit it! Charlie ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
On Wed, May 6, 2020 at 12:19 PM Noel Duffy via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > So I guess the question is, is it worth the effort to make > StrToHostAddr6 RFC4291 compliant? Is that something the FPC team would > want, or do they just not use the sockets unit? > There have been 2 changes applied to sockets.inc in the last two months so it is not neglected. I am convinced a patch to ensure compliance will be considered for inclusion, especially if you provide test cases demonstrating shortcomings in the current implementation. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
On 3/05/20 10:28 pm, Michael Van Canneyt wrote: On Sun, 3 May 2020, Noel Duffy via fpc-pascal wrote: On Sun, 3 May 2020 09:57:46 +0200 (CEST) Michael Van Canneyt wrote: Yes, please open a bug report. If you attach a small console test program that demonstrates the bug (and subsequently the fix) then I will make sure it ends up in the correct place. If you make sure it exits with exit code 0 if all is well, and a nonzero exit code if there is an error, that will save me some work. If you post the URL for the bug here, I will look at it at once. To follow-up on this issue I raised in bug #37013 (https://bugs.freepascal.org/view.php?id=37013), I've been digging into RFC4291 to see what address formats for IPv6 exist, and I see that the scope of this problem is bigger than I envisioned. To summarize, the current function, StrToHostAddr6, from the sockets unit, will successfully parse many address formats expressly forbidden by RFC4291, and it fails to parse others that the RFC expressly requires. An example of the latter is this ugly form: fe80:caf1:906e:9d2f:a520:4172:172.16.31.14 This apparently exists to make IPv4 to IPv6 transitions easier. Anyway, back to the bug report. I can't make StrToHostAddr6 RFC4291 compliant without rewriting it, and I don't want to undertake that unless I know it's something the FPC community actually wants. I am happy to do the work, don't get me wrong, but I realise that a wholesale rewrite of the function is much wider in scope and has more potential for drawbacks. Testing would also have to be fairly rigorous to make sure all the different formats are handled correctly. I've already done some work to make it easy to compare StrToHostAddr6's output to that of inet_pton in the C library, so this would at least provide a good method to quickly spot problems. So I guess the question is, is it worth the effort to make StrToHostAddr6 RFC4291 compliant? Is that something the FPC team would want, or do they just not use the sockets unit? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Raspberry Pi3B - often EBusError: Bus error or misaligned data access
Hi Ched, I run nightly testsuite on a raspberry PiB, and I did not see anything like that. Would it be possible for you to send here a simple source file that shows this behavior together with an explicit command line for the compilation, to be sure of the precise options you are using: To be really useful, this command line should use the '-n' option, which prevents loading of your local .fpc.cfg or /etc/fpc.cfg. Of course, adding this option will force you to also add explicit -Fu/explicit/dir/to/rtl/units/for/arm-linux-target option so that the compiler finds the rtl units. For me, I have fixes installed in $HOME/pas/fixes directory, typically I use "-n -Fu$HOME/pas/fixes/fpcsrc/rtl/units/arm-linux" Using strace might also be useful to figure out which system call generates the BUS error. An explicit version of the linux system might also be relevant, uname -a output would also help. Best regards, Pierre Le 05/05/2020 à 22:40, Il Grande Beppe via fpc-pascal a écrit : > Hello All, > > With the 3.2.0-RC1 on a Raspberry PiB running raspbian, most of my software > which ran very well when > compiled with fpc 3.0.4 do stop with the error in title when or near a seek() > is done in a structured > binary file. I tryed first -O3 then -O2 then -O1 then no optimisation option > without success. > > Do some peoples encounter the same difficulties ? > > Kindest regards, Ched' > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Raspberry Pi3B - often EBusError: Bus error or misaligned data access
Hello All, With the 3.2.0-RC1 on a Raspberry PiB running raspbian, most of my software which ran very well when compiled with fpc 3.0.4 do stop with the error in title when or near a seek() is done in a structured binary file. I tryed first -O3 then -O2 then -O1 then no optimisation option without success. Do some peoples encounter the same difficulties ? Kindest regards, Ched' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
> 5 maj 2020 kl. 07:19 skrev Sven Barth via fpc-pascal > : > > Am 05.05.2020 um 04:16 schrieb Ryan Joseph via fpc-pascal: >> >> >>> On May 4, 2020, at 10:44 PM, Michael Van Canneyt >>> wrote: >>> >>> That is how enums work by default in Pascal. >>> >>> If you don't force scoped enums, you can still scope them. >>> >>> if you use >>> $scopedenums on then you simply force the use instead of having it optional. >> But the names collide then, that's the whole point. We want to protect >> against name collisions and we don't want to type long prefix names every >> time. Scoped enums fixes half of that by formalizing the prefix syntax but >> you still need to type it even when it could be inferred by context. >> >> Swift figured out how to do this and so should Pascal imo. > > Surprise: Pascal is /not/ about writing less. Pascal is about writing correct > code. Couldn't agree more! /Bjarne. (back to lurking) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCMake and Makefile.fpc question
Bart via fpc-pascal schrieb am Mi., 6. Mai 2020, 02:33: > Hi, > > Here's the first line of the Lazarus Makefile: > - > # > # Don't edit, this file is generated by FPCMake Version 2.0.0 > # > default: all > MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 > i386-freebsd i386-beos i386-haiku i386-netbsd i386-solaris > i386-netware i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom > i386-netwlibc i386-wince i386-embedded i386-symbian i386-nativent > i386-iphonesim i386-android i386-aros m68k-linux m68k-netbsd > m68k-amiga m68k-atari m68k-palmos m68k-macos m68k-embedded > powerpc-linux powerpc-netbsd powerpc-amiga powerpc-macos > powerpc-darwin powerpc-morphos powerpc-embedded powerpc-wii > powerpc-aix sparc-linux sparc-netbsd sparc-solaris sparc-embedded > x86_64-linux x86_64-freebsd x86_64-netbsd x86_64-solaris > x86_64-openbsd x86_64-darwin x86_64-win64 x86_64-embedded > x86_64-iphonesim x86_64-aros x86_64-dragonfly arm-linux arm-netbsd > arm-palmos arm-darwin arm-wince arm-gba arm-nds arm-embedded > arm-symbian arm-android arm-aros powerpc64-linux powerpc64-darwin > powerpc64-embedded powerpc64-aix avr-embedded armeb-linux > armeb-embedded mips-linux mipsel-linux mipsel-embedded mipsel-android > jvm-java jvm-android i8086-embedded i8086-msdos i8086-win16 > aarch64-linux aarch64-darwin wasm-wasm sparc64-linux > > > As you can imagine that's way more targest than Lazarus actually supports. > And the Makefile is cluttered with hundreds of unnecessary lines, > which makes identifying an actual bug in the Lazarus build process > (which might be in the Makefile) rather difficult. > > Is it possible to control this in the makefile.fpc file? > Not in the makefile.fpc, but fpcmake allows you to pass a list of supported targets (usually -Tall is used to allow all targets), but you'd need to pick each one. This does mean however that everyone that wants to try a target that's not supported has to generate the makefile (I don't know if Lazarus only has the one compared to FPC). For example officially Lazarus doesn't support powerpc-darwin anymore, but one could probably still use it there with some fixes (I should really test that...) Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
