I've been happily building 64-bit FPC natively on Windows for over five years now. It works fine. It is stable. There is no logical reason whatsoever to use a 32-bit to 64-bit FPC cross compiler in 2018 if you are running 64-bit Windows natively, and anyone who thinks there is doesn't use Windows enough.

As just one example, I've seen more than one instance of people on the Lazarus forums posting threads asking about how they can work around out-of-memory errors while building Lazarus, and who also mention that they're running 64-bit Windows. Realistically, the logical conclusion is that all of these people are of course using a 32-bit to 64-bit cross compiler, possibly only because they think they have no other choice.

The bundled FPC that comes with the 64-bit Windows Lazarus installer is now also a native 64-bit build. So why does the FPC website still insist on redirecting to the Win32 cross compiler? (On Sourceforge, of all places.)

Personally as it stands now I just recommend the use of FPCUpDeluxe and actively avoid directing anyone interested in starting out with FPC to the official downloads page, as it just doesn't make FPC look very good. (The same could be said about the various other wildly outdated bits of information on the overall site and the fact that it gives now-hugely-irrelevant topics like "porting from TP7" such precedence, but that's a different issue.)

That being said, if there's a way I can help to fix this, at least partially, I'm interested to know what that might be!

Roughly:

1) create the *.ist files for a win64 hosted environment (see fpcbuild/install for the existing ones)
2) extend the fpcbuild makefile to be able to create
3) build the needed 64 bit binutils and utilities
4) provide everything somewhere so it can be integrated the fpcbuild repository
5) build all installers for win64, provide them somewhere, ask for testing, fix issues
6) build installers as soon as rc's are built

Ben Grasset wrote

s just one example, I've seen more than one instance of people on the Lazarus forums posting threads asking about how they can work around out-of-memory errors while building Lazarus

Where does the compiler need more than 1.5GB of VM space while building Lazarus? That sounds like an awful lot, and something we may want to look into. Especially since Lazarus is not built in one go, but using several separate compiler invocations.

Jonas

Ben Grasset wrote

(The same could be said about the various other wildly outdated bits of information on the overall site and the fact that it gives now-hugely-irrelevant topics like "porting from TP7" such precedence, but that's a different issue.)

porting from TP/BP 6/7 is still fairly relevant... maybe not in your part of the universe but it is definitely relevant for others... in one development directory here there are well over 500 pas and inc files needing porting... no clue at this time the number of LoC in those files but it is a lot more than those with the porting task really want to know about else it set a daunting task ahead of them...

Not to mention the users who pick up FPC and have to port what they've previously learned. That information is useful even if the code isn't already written.

+1 (at least)

The narrowmindedness of some of the young whippersnappers never ceases to amaze me (and not in a good way :-( ).

Having info that is outdated (as subsequent developments have improved/replaced it) is one thing, but what one might consider "hugely irrelevant" is a completely different issue and "highly" depended on subjective needs and purposes...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

I'm not young. You're making all kinds of assumptions here. TP7 *is *generally speaking, irrelevant in the fast majority of cases nowadays. FPC is 1000x more advanced in every conceivable way than any version of Turbo Pascal ever was. There is nothing "interesting" about TP from a current perspective. At this point it's simply just a notably worse Pascal compiler than FPC, and nothing more.

I find it extremely difficult to believe that you're actually claiming there is a non-trivial number of people out there who have *literally* been actively developing in nothing but Turbo Pascal right up until now, and finally have decided to "modernize", and who will as such actually find that article useful.

The overall point is just that I believe it is *highly* reasonable to suggest that article is of interest to exceedingly few people at this current point in time, and that there are almost certainly things that would be found useful by a significantly higher number of people that could take its place. Not that I'm absolutely *not* suggesting it be removed entirely.

It may really truly be the case that you somehow have a codebase that you're still in the process of porting, but in all honesty *just *setting {$mode TP} and nothing else will generally speaking get you 90% of the way there most of the time, if not all the way.

FPC in TP mode has been able to compile most of the old Borland TP demos with zero changes for years now...

It's not even like TP was that different. Generally speaking it's just the same Object Pascal, except with less features. I don't mean to be rude, but I simply fail to see how porting code from it could ever be "daunting."

I honestly have no idea. It's not an issue I've ever encountered, as I've literally never built Lazarus with a toolchain that wasn't 64 bit. It would seem to be the case though that it is indeed very possible (at some level/point) for it to consume that much memory.

It's worth noting I guess that Lazbuild *does *invoke the FPC instances all at the same time, and by default uses the number of CPUs as the limit. It seems theoretically possible that if you had let's say 8 copies of specifically *32-bit* FPC running at the same time building Lazarus packages that they could hit a cap that wouldn't be hit with 64 bit binaries.

Lazarus also for some reason distributes a 32-bit copy of Make *3.80 *with the 64-bit Windows installer, apparently due to some concerns about makefile compatibility that I think I might vaguely remember from YEARS ago but that certainly haven't existed for a long time... I'm not sure the exact extent to which Make is implicitly invoked as far as Lazarus goes, but I could definitely see something going wrong there (as the Make 3.80 codebase dates back to 2002). Also just because again, 32-bit.

Either way, native 64-bit is definitely objectively better in various ways, many not necessarily related building Lazarus specifically. As I said I've been building it myself for years, and I use it daily.

I just strongly disagree that there's much merit or reality to the overall concept people keep floating here that FPC's *actual *user base consists largely of a magical non-stop stream of 50+ year olds who have randomly decided out of the blue to "pick up Pascal again" and re-live the whimsical good old days.

Note that I am certainly *not* "young" myself as another poster suggested, and I have no issue with people who do take an interest in FPC for reasons roughly similar to what I described above.

I do however have a huge issue with the perpetuation of the idea that FPC is *mostly* nothing more than a language for maintaining your mediocre Delphi 7 DBase apps in or for dragging out your dusty old DOS rig and tinkering around with for nostalgias sake.

It is of course fully usable for those things, which is great! At the same time though it's a modern language with modern features that is extremely well suited for a variety of modern applications that *do not necessarily resemble *whatever arbitrary idealized vision or memory of Pascal that a given long-time user may or may not have, which as far as I'm concerned is also great! Basically I'm saying FPCs notable strength is its ability to seamlessly handle vastly different programming styles originating at totally different points in time and switch between them quite trivially.

FPC is capable of much, much, much, more than "Database App Number Eighteen Million" and "Yet Another Reimplementation Of The Command-Line Snake Game I Originally Wrote 25 Years Ago", which I think an increasing number of people are discovering, some who may have used Pascal before, and some who might be younger and perhaps have not. As far as I'm concerned FPC is good for *everything, *and I'm just not a fan of insinuations to the contrary.

I accidentally replied to this one via the main thread. It's my most recent message before this.

Ben Grasset wrote

I'm not young. You're making all kinds of assumptions here. TP7 /is /generally speaking, irrelevant in the fast majority of cases nowadays.

Talking about making assumptions!

If it is not of interest for YOU, then simply ignore it. There ARE people for whom that info IS in fact interesting. Again, it is YOU who makes wild assumptions here.

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Have you tried passing --max-process-count=1 to lazbuild?

Mattias

Am Mo., 5. Nov. 2018, 04:43 hat Ben Grasset
geschrieben:

It doesn't for FPC itself whether it's running in parallel with 7 other FPC processes. Each process has its 4 GB of address space (and with the correct flag set in the PE that *really* are 4 GB on a 64 bit Windows) and only if the OS would run out of memory there would be problems, but then this would also be the case for a 64-bit FPC.

The only real problem would be if compiling and linking the final IDE would use up too much memory (and as Florian said that would need to be investigated anyway).

Regards,
Sven

wow... you talk about "making assumptions" and then you that someone claimed something that no one wrote... no one said anything about any non-trivial number of people using TP...

personally speaking, depending on the job, yes, i break out my TP6 (!) for many things... if i need 32/64 bit, then i use FPC/Lazarus...

i can also honestly point to several projects that are in the process of being ported from TP to FPC... one is/was an extremely popular FTN mailer used in Fidonet and other Fidonet Technology Networks... and yes, Fidonet does still exist today along with another ~50+ other FTNs ;)

Ben Grasset wrote

It may really truly be the case that you somehow have a codebase that you're still in the process of porting,

no one said "still in the process of porting"... porting of those hasn't even started...

but in all honesty /just /setting {$mode TP} and nothing else will generally speaking get you 90% of the way there most of the time, if not all the way.

true to a point...

FPC in TP mode has been able to compile most of the old Borland TP demos with zero changes for years now...

this is true but some of us used a lot of low level operations that aren't available any more... direct screen writes, low level disk access using FAT tables and BIOS function calls, reading the BIOS area to determine which COM ports are assigned and what their addresses are, etc...

It's not even like TP was that different. Generally speaking it's just the same Object Pascal, except with less features. I don't mean to be rude, but I simply fail to see how porting code from it could ever be "daunting."

again, it is the number of lines that would lead to that in certain cases... then there's also the complete requirement to unlearn old methods that are still stuck in one's memory... hell, i have a library of code here for working with time and dates... FPC has all that already covered so all that code that i wrote is basically useless now but the newer code is different enough that figuring which routine to use and which parameters need to be changed... ya know? some of us old timers don't live in front of the compilers any more, either...

anyway, i just wanted to point out that your statement was using a very broad brush with poor knowledge of the facts (aka limited horizon)... for me, i'm done with this thread now ;)

On 11/4/18 10:31 PM, Ben Grasset wrote:

.
.

for me, i'm done with this thread now ;)

I'd appreciate if this part of the discussion related to importance of TP compatibility is finished for everybody.

I understand that the original poster tried to suggest changing priorities. That may be a valid point, but I'd prefer discussing what should improve and how rather than whether the current state has good enough reasons. If prepared this way (e.g. 'I believe that the Features paragraph on the FPC homepage should be modified to: ..., because ...'), we may come to an agreement more efficiently than if discussing on purely theoretical level. Even then, it probably isn't a topic for the fpc-devel list but rather for fpc-pascal. In addition, I'd like to remind you that there's a category 'Website' in the bug tracker and that specific possible improvements may be posted there as well.

Tomas
(one of FPC mailing list moderators)

PM Tomas Hajny wrote

I'd appreciate if this part of the discussion related to importance of TP compatibility is finished for everybody.

For what it's worth my original message only mentioned the TP thing in passing, and I specifically said it was a "different issue" (as in not really related to what I was trying to talk about here.)