[fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. You have to use a cross-compiler" notice on the FPC website?

[Ben Grasset]

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!

[Florian Klämpfl]

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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org

[Jonas Maebe]

Post by Ben Grasset
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bi

[Ben Grasset]

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.

Post by Jonas Maebe

Post by Ben Grasset
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
_______________________________________________
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[Mattias Gaertner via fpc-devel]

On Sun, 4 Nov 2018 22:43:19 -0500

Post by Ben Grasset
[...]
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.

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

Mattias
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fp

[Sven Barth via fpc-devel]

Post by Ben Grasset
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.

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

[w***@windstream.net]

(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...

[Alexander Grotewohl]

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.

Post by w***@windstream.net

(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...

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/l

[Ben Grasset]

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.

[Ben Grasset]

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

Post by Alexander Grotewohl
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.

Post by w***@windstream.net

(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...

_______________________________________________
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[Ralf Quint]

Post by w***@windstream.net

(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...

+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

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.f

[Ben Grasset]

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.

Post by Ralf Quint

Post by w***@windstream.net

(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...

+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
_______________________________________________
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[Ralf Quint]

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!

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.

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

[w***@windstream.net]

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.

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]

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."

Post by w***@windstream.net

(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...
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list unless*
*a signed and pre-paid contract is in effect with us.*
_______________________________________________
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[w***@windstream.net]

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 ;)

[Tomas Hajny]

.
.

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)


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[Ben Grasset]

Post by Tomas Hajny
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.)