Re: [fpc-pascal] compiler option for $J directive

[Christo Crause]

>> They were used mainly back at TP times to have procedure local static
variables (cause that is how they behave as inside procedures).
>
> Can we make the {$J-} as default in fpc and objfpc mode for the next
major release?

+1
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Mr Bee via fpc-pascal]

2017-10-10 16:21 GMT+07:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> They were used mainly back at TP times to have procedure local static
> variables (cause that is how they behave as inside procedures).
>
Can we make the {$J-} as default in fpc and objfpc mode for the next major
release?


-- 

Regards,


–Mr Bee
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Mr Bee via fpc-pascal]

2017-10-10 13:28 GMT+07:00 Marco van de Voort :

>
> Since it is already largely uploaded, no. We are only waiting on some
> targets.
>

I thought such a minor fix that don't break any codes could be included.


-- 

Regards,


–Mr Bee
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Florian Klämpfl]

Am 10.10.2017 um 21:17 schrieb Graeme Geldenhuys:
> On 2017-10-10 19:54, Florian Klämpfl wrote:
>> Well, lack of manpower is not that odd:)
> 
> Isn't building the installations automated tasks? 

No. As building is not the main work, but creating, maintaining and testing the 
installer scripts
is. For win32 hosts we have:
- win32
- wince
- win64
- android
- jvm
- msdos

> So reallocate the man power for creating the win64
> cross-compiler, and let them rather spend the time on creating a native 
> 64-bit Windows compiler and
> installer.

You are aware that fpc is an open source community project so the possibility 
to "reallocate" man
power is basically zero?

>
> 
> I wonder what is the ratio of users now for 32-bit Windows vs 64-bit Windows? 

No idea, I do not care. I still need win32, so I take care of those. As win64 
installers would
double my work without any benefit for me, I do not create them. But as said, 
fpc is a community
project, if somebody cares, he is welcome to make scripts for win64 inno 
installers and take care of
the releases.

> Hell, even mobile
> phones have moved to 64-bit only targets.
> 
> 
> On a side note:
> If you don't have something for automating tasks, take a look at the open 
> source Jenkins project -

I do, sometimes, http://build.alb42.de:8080/

> it's awesome. It was designed for Java, but can be used for other projects 
> and languages too.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Graeme Geldenhuys]

On 2017-10-10 19:54, Florian Klämpfl wrote:

Well, lack of manpower is not that odd:)


Isn't building the installations automated tasks? So reallocate the man 
power for creating the win64 cross-compiler, and let them rather spend 
the time on creating a native 64-bit Windows compiler and installer.


I wonder what is the ratio of users now for 32-bit Windows vs 64-bit 
Windows? Hell, even mobile phones have moved to 64-bit only targets.



On a side note:
If you don't have something for automating tasks, take a look at the 
open source Jenkins project - it's awesome. It was designed for Java, 
but can be used for other projects and languages too.


Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Florian Klämpfl]

Am 10.10.2017 um 09:06 schrieb Graeme Geldenhuys:
> On 2017-10-09 09:56, adrian.soentger...@web.de wrote:
>> i installed “fpc-3.0.2.i386-win32.cross.x86_64-win64” on my laptop with 
>> windows 7, but there seem
>> to be no fpc.exe file, so i can´t compile.
> 
> For some odd reason the FPC team still 
> don't produce a native 64-bit Windows compiler installation.

Well, lack of manpower is not that odd :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Sven Barth via fpc-pascal]

Am 10.10.2017 15:21 schrieb "turro75" :
>
> Well,
>
> I think my problem is easier
> when I compile fpc for arm-android target I get ppccrossarm and units
> arm-android (with binutils arm-linux-android-*)
>
> when I compile fpc for arm-embedded target I get ppccrossarm and units
> arm-embedded (with binutils arm-none-eabi-*)
>
> both are able to create binary as I need.
>
> So the last crosschain created overwrites the previous (the ppcrossarm
> executable).
> Is there a way to instruct  fpc.cfg to use an alternative name (i.e.
> ppcrossarmdroid or ppcrossarmembed) when fpc invokes the right compiler?

You can use the same binary for both as long as both compile for the same
ABI (EABI vs. HardFloat vs. OABI).

Alternatively you can supply the -V option for the fpc binary. Used as
"-Vxyz" the compiler driver will call -xyz.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Tony Whyman]

On 10/10/17 13:50, pasc...@piments.com wrote:

On 10/10/17 13:29, Karoly Balogh (Charlie/SGR) wrote:

  Linux Subsystem for Windows.


While I know what you mean ...

I used to be maintainer on Wine AppDB for several years. Nothing ever 
worked from one release to the next.  WINE spent 10y  as an alpha 
release and it started to get embarrassing so they called it beta. 
Everything still, broke , it is still an alpha produce in all but name.


Sadly the target is moving faster than their ability to emulate it.

As for attempting to run a stable and secure  OS inside an insecure 
and unstable one, that's a great way to combine all the disadvantages 
of both. Probably clinically certifiable behaviour or at least 
"autistic spectrum".



On the other hand, without wine (and mono) I couldn't run WIX on Linux.

 If I couldn't run WIX on Linux then I could not build WIndows 
Installer Packages on Linux.


 If I couldn't build WIndows Installer Packages on Linux then I would 
not be able to have one script building for both Linux and Windows targets.


And then what would be the point of having cross-compilers and cross 
platform libraries in the first place.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 10 Oct 2017, Michael Van Canneyt wrote:

> > I used to be maintainer on Wine AppDB for several years. Nothing ever
> > worked from one release to the next.  WINE spent 10y  as an alpha
> > release and it started to get embarrassing so they called it beta.
> > Everything still, broke , it is still an alpha produce in all but name.
> >
> > Sadly the target is moving faster than their ability to emulate it.
> >
> > As for attempting to run a stable and secure  OS inside an insecure and
> > unstable one, that's a great way to combine all the disadvantages of
> > both. Probably clinically certifiable behaviour or at least "autistic
> > spectrum".
>
> LOL :)
>
> My point of view since 15+ years...
> Don't mix the 2 environments. Frustration and disappointment guaranteed.
> It used to work more or less with VMWare and Virtualbox, but even this is
> now becoming more a source of frustration than of satisfaction...

Although this is getting off topic now, it's a mater of use case I guess.
For once, I was pretty happy WINE existed, because I could run a bunch of
Windows (and binary) only tools on Linux and Mac OS with it already. I'm
pretty sure an FPC binary would also work fine in both directions, which
is where the whole discussion started.

I for example was glad I could run the ancient and Windows only POSE Palm
emulator on macOS, and I even used it for some retro FPC stuff...
(https://twitter.com/chainq/status/908439601630629888) Or I used the Amiga
emulator WinUAE a lot under WINE, before FS UAE matured, etc.

Nothing is a silver bullet and there are a lot of caveats. But
nevertheless, the state of interoperability between platforms is much
better than most people think, and care to admit. (And reach almost the
state of running a MacOS VM under AmigaOS 20 years ago, but that's a whole
different story... ;) )

Charlie

Ps:
http://charlie.amigaspirit.hu/screenshots/a2000/A2000-FPCvsThinkPascal.png

;)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[turro75]

Well,

I think my problem is easier
when I compile fpc for arm-android target I get ppccrossarm and units
arm-android (with binutils arm-linux-android-*)
 
when I compile fpc for arm-embedded target I get ppccrossarm and units
arm-embedded (with binutils arm-none-eabi-*)

both are able to create binary as I need.

So the last crosschain created overwrites the previous (the ppcrossarm
executable).
Is there a way to instruct  fpc.cfg to use an alternative name (i.e.
ppcrossarmdroid or ppcrossarmembed) when fpc invokes the right compiler?



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Michael Van Canneyt]

On Tue, 10 Oct 2017, pasc...@piments.com wrote:


On 10/10/17 13:29, Karoly Balogh (Charlie/SGR) wrote:

  Linux Subsystem for Windows.


While I know what you mean ...

I used to be maintainer on Wine AppDB for several years. Nothing ever 
worked from one release to the next.  WINE spent 10y  as an alpha 
release and it started to get embarrassing so they called it beta. 
Everything still, broke , it is still an alpha produce in all but name.


Sadly the target is moving faster than their ability to emulate it.

As for attempting to run a stable and secure  OS inside an insecure and 
unstable one, that's a great way to combine all the disadvantages of 
both. Probably clinically certifiable behaviour or at least "autistic 
spectrum".



;)


LOL :)

My point of view since 15+ years... 
Don't mix the 2 environments. Frustration and disappointment guaranteed.

It used to work more or less with VMWare and Virtualbox, but even this is
now becoming more a source of frustration than of satisfaction...

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[pascalX]

On 10/10/17 13:29, Karoly Balogh (Charlie/SGR) wrote:

  Linux Subsystem for Windows.


While I know what you mean ...

I used to be maintainer on Wine AppDB for several years. Nothing ever 
worked from one release to the next.  WINE spent 10y  as an alpha 
release and it started to get embarrassing so they called it beta. 
Everything still, broke , it is still an alpha produce in all but name.


Sadly the target is moving faster than their ability to emulate it.

As for attempting to run a stable and secure  OS inside an insecure and 
unstable one, that's a great way to combine all the disadvantages of 
both. Probably clinically certifiable behaviour or at least "autistic 
spectrum".



;)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 10 Oct 2017, pasc...@piments.com wrote:

> > The compiler is *NOT* OS/platform specific, only CPU specific. Use any for
> > both, and specify the right target using -Tandroid or -Tembedded when
> > invoking.
>
> Maybe you meant the compiler is not TARGET OS specific in that it can
> compiler for any target ( that does seem to be the point the OP was
> missing).

Yes.

> It is specific to what HOST it is built to run on. I don't think you
> will get far running a linux x64 fpc on win64 and vice versa.

While I understand what you mean, I'd recommend taking a look on WINE and
the Linux Subsystem for Windows. You might be surprised... ;)

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[pascalX]

On 10/10/17 10:08, Tony Whyman wrote:

On 10/10/17 05:51, pasc...@piments.com wrote:
Were it not for the version restrictions in building fpc one could 
arguably say this was a reasonable assumption.  As it is, it leads to 
a very confused and confusing state which has taken several days to 
understand and untangle.



Maybe that could be addressed.

Thanks for the help along the way. 
I do make a lot of use of the cross-compiler and the cross-platform 
libraries capability of FPC and I am wondering if you might be looking 
at the problem in the wrong way, especially when you seem to be talking 
about using the cross-compiler for the Lazarus IDE. Here's how I use 
them and hopefully this will inform your own understanding.


1. When I develop a program using the Lazarus IDE, I am only working 
with the native (debug) libraries for the development platform. In my 
case, this is 64-bit Linux. Occasionally, I will run 64-bit Windows in a 
virtual machine and Lazarus (in native Windows mode) to test for Windows 
specific issues. During the development and test cycle I do not use 
cross-compilers or libraries and you would probably only need to do this 
when compiling for a target on which it is just not practical to run the 
Lazarus IDE.


2. The cross-compiler and libraries come into their own when I generate 
production executables and installation packages as they enable the 
whole process to be performed on the same platform (Linux 64-bit) for my 
required target platforms: Linux (32-bit and 64-bit) and Windows (32-bit 
and 64-bit), and automated using a single script - which then goes on to 
build the Debian packages and Windows installer packages.


3. I always compile FPC from source. For the development platform, a 
64-bit compiler is needed and the FPC RTL and FCL libraries include 
debug symbols. The Lazarus IDE compiles its libraries (LCL and 
components) using this compiler and the FPC libraries, and works very 
nicely without the user needing to understand too much about what is 
going on - or even having to do much in the way of IDE configuration.


4. For the production platform, a 32-bit cross complier is also needed 
as are optimised RTL and FCL libraries and optimised Lazarus libraries. 
These libraries have to be built explicitly for each of the production 
platforms. I have a separate location in the filesystem for the 
production libraries (separate from development libraries) with 
sub-directories for x86_64-linux, x86_64-win64, i386-linux, i386-win32. 
Within the Lazarus parts of the libraries, the Linux libs have the gtk2 
interface libraries, while the Windows ones have the win32 interfaces 
libraries (both win32 and win64).


5. I then use FPC Makefiles to build for each target platform in turn 
which reference the production and not the development libraries. This 
includes Lazarus programs and the Lazarus IDE does not have anything to 
do with this part of the process. Indeed, it would complicate matters no 
end to try and use the IDE to build for each production target.


If you have taken only a few days to dis-entangle all there is to know 
about cross compilation and cross platform libraries then I think you 
are doing very well. It has taken me far longer than that to work out 
the toolchain that I need and I am still learning the best way to do 
things. Indeed, there may be no "best way" to do things. The above works 
for me, but may not work for you. However, the advice that I would give 
is that as soon as you start to talk about cross-compilers, then you 
need to start thinking about the differences between development and 
production environments. Unless you are working with embedded systems, 
then my advice is don't try to work with cross-compilers for 
development. On the other hand, when you generate production executables 
then cross-compilers and cross platform libraries are very useful for 
automating the process and ensuring consistent quality across all target 
platforms. However, you do need to think through carefully how the 
toolchain works and explicitly generate optimised libraries for each 
target platform including the Lazarus interface appropriate for the 
target. Use the IDE for development but have a separate scripted 
environment for generating production executables.




Thanks for a very clear and detailed description of you workflow. That 
is definitely very helpful coming form someone with hands-on experience 
of going the whole way.


I'm not new to cross-platform work, so I'm not starting from zero, but 
this is the first time I've attempted a  cross-platform  project on 
fpc/laz.



It's not a project I intend to distribute, it's just a bit of fun for a 
friend that I am using to evaluate the cross-compilation capabilities 
that Lazarus claims.


It looks like it's 98% of the way there with a couple wrinkles that need 
smoothing out.


In view of the issues I've found, VM may be the best way to get a final 
result. But I like the idea of full 

Re: [fpc-pascal] alternative name fpc cross

[pascalX]

On 10/10/17 11:16, Karoly Balogh (Charlie/SGR) wrote:

Hi,

On Tue, 10 Oct 2017, turro75 wrote:


when I create the cross compiler to arm-android and arm-embedded I get the
same compiler name so unable to have both running in the same system.
any workaround?


The compiler is *NOT* OS/platform specific, only CPU specific. Use any for
both, and specify the right target using -Tandroid or -Tembedded when
invoking.

Charlie


Maybe you meant the compiler is not TARGET OS specific in that it can 
compiler for any target ( that does seem to be the point the OP was 
missing) .  It is specific to what HOST  it is built to run on. I don't 
think you will get far running a linux x64 fpc on win64 and vice versa.






___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[Marco van de Voort]

In our previous episode, pasc...@piments.com said:
y> > release compiler (currently 3.0.0 or 3.0.2) is supported.
> > 
> > Regards,
> > Sven
> 
> You were mis-reading what I meant. I know it is supposed to complain 
> when I  use 3.1.1 , my point was the messages said I should ONLY use 
> 3.0.0 when in fact I can and have used 3.0.2 without the version trap 
> being triggered.

The only supported version is the last release, but due to good stability in
recent times the version before is also supported. 

However the cehck and error message comes from the makefile in the checkout,
so if it is old, it can show an outdated version.

I checked, and fixes currently tells you to use 3.0.2, but trunk has a wrong
message (shows older version in msg, but accepts 3.0.0 and 3.0.2).

I'll see if I can fix that asap.
 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[pascalX]

On 10/10/17 10:35, Tony Whyman wrote:

On 10/10/17 05:51, pasc...@piments.com wrote:
$make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64 
INSTALL_PREFIX=/usr
Makefile:2914: *** The only supported starting compiler version is 
3.0.0. You are trying to build with 3.1.1..  Stop.


BTW is  that msg  is correct? I just built with 3.0.2 , it seems that 
the version block is not specific enough or the message missed a 
version bump. 
Yes, that message is always very irritating - but probably right. The 
FPC compiler I currently use is built from the fixes_3_0 branch and this 
demands the 3.0.0 compiler to initially compile the compiler. The first 
time I build from source there is no problem. I install the 3.0.0 
compiler from a binary and build the source and install it. The second 
time, the error message occurs because you now have a more recent 
version as the installed compiler.


The way I avoid the problem is to have a script I always use to build 
from source and to force the use of the 3.0.0 compiler for the initial 
build. This is still on the system and will stay there (unless 
explicitly deleted) even after the later version is installed. My script 
saves the initial compiler version in a file "build-version" which is 
added to my working copy of the source code tree. The script is given 
below as an example and is intended to be run in the root directory of 
the source tree. Note the use of the PP make variable for passing the 
path to the initial build compiler.


   PREFIX=/usr
   FPCPROG=ppcx64

     if [ ! -f build-version ]; then
       fpc -iV >build-version
     fi

   BUILDVERSION=`cat build-version`

   if [ ! -x $PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG ]; then
     echo "FPC Build Version ($BUILDVERSION) not found"
     exit 1
   fi

   echo "make default target compiler and libraries"

   export FPCDIR=$PREFIX/lib/fpc/$BUILDVERSION


   make all PP=$PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG OPTIMIZE=1
   if [ $? -ne 0 ]; then
     exit $?
   fi

   if [ ! -x compiler/$FPCPROG ]; then
     echo "Failed to build compiler"
     exit 1
   fi

_



Thanks very much .


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[pascalX]

On 10/10/17 10:08, Tony Whyman wrote:
Within the Lazarus parts of the libraries, the Linux libs have the gtk2 
interface libraries, while the Windows ones have the win32 interfaces 
libraries (both win32 and win64).


Thanks, that was the missing element.

I dropped using gtk2 and it works perfectly on win64 now.

Many thanks. That saved me a lot of time experimenting.

;)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[pascalX]

On 10/10/17 10:25, Sven Barth via fpc-pascal wrote:
Am 10.10.2017 08:08 schrieb >:


 > $make all         NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64 
INSTALL_PREFIX=/usr
 > Makefile:2914: *** The only supported starting compiler version is 
3.0.0. You are trying to build with 3.1.1..  Stop.

 >
 > BTW is  that msg  is correct? I just built with 3.0.2 , it seems that 
the version block is not specific enough or the message missed a version 
bump.


Yes, the message is correct as you're trying to build trunk with a trunk 
compiler (the Makefile even says you're trying to use 3.1.1). Only a 
release compiler (currently 3.0.0 or 3.0.2) is supported.


Regards,
Sven




You were mis-reading what I meant. I know it is supposed to complain 
when I  use 3.1.1 , my point was the messages said I should ONLY use 
3.0.0 when in fact I can and have used 3.0.2 without the version trap 
being triggered.


So what is the REAL condition which needs to be satisfied and which is 
tested for ?


Is it any 3.0.x , or any 3.0.x where x is even?

Or is the trap incorrectly letting 3.0.2 through.

I suspect the message text is wrong. I was trying to bring that to the 
attention of someone why may fix it if needed and seek clarification on 
what is supported.


;)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 10 Oct 2017, turro75 wrote:

> when I create the cross compiler to arm-android and arm-embedded I get the
> same compiler name so unable to have both running in the same system.
> any workaround?

The compiler is *NOT* OS/platform specific, only CPU specific. Use any for
both, and specify the right target using -Tandroid or -Tembedded when
invoking.

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[Tony Whyman]

On 10/10/17 05:51, pasc...@piments.com wrote:
$make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64 
INSTALL_PREFIX=/usr
Makefile:2914: *** The only supported starting compiler version is 
3.0.0. You are trying to build with 3.1.1..  Stop.


BTW is  that msg  is correct? I just built with 3.0.2 , it seems that 
the version block is not specific enough or the message missed a 
version bump. 
Yes, that message is always very irritating - but probably right. The 
FPC compiler I currently use is built from the fixes_3_0 branch and this 
demands the 3.0.0 compiler to initially compile the compiler. The first 
time I build from source there is no problem. I install the 3.0.0 
compiler from a binary and build the source and install it. The second 
time, the error message occurs because you now have a more recent 
version as the installed compiler.


The way I avoid the problem is to have a script I always use to build 
from source and to force the use of the 3.0.0 compiler for the initial 
build. This is still on the system and will stay there (unless 
explicitly deleted) even after the later version is installed. My script 
saves the initial compiler version in a file "build-version" which is 
added to my working copy of the source code tree. The script is given 
below as an example and is intended to be run in the root directory of 
the source tree. Note the use of the PP make variable for passing the 
path to the initial build compiler.


  PREFIX=/usr
  FPCPROG=ppcx64

    if [ ! -f build-version ]; then
      fpc -iV >build-version
    fi

  BUILDVERSION=`cat build-version`

  if [ ! -x $PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG ]; then
    echo "FPC Build Version ($BUILDVERSION) not found"
    exit 1
  fi

  echo "make default target compiler and libraries"

  export FPCDIR=$PREFIX/lib/fpc/$BUILDVERSION


  make all PP=$PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG OPTIMIZE=1
  if [ $? -ne 0 ]; then
    exit $?
  fi

  if [ ! -x compiler/$FPCPROG ]; then
    echo "Failed to build compiler"
    exit 1
  fi

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[Sven Barth via fpc-pascal]

Am 10.10.2017 08:08 schrieb :

> $make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64
INSTALL_PREFIX=/usr
> Makefile:2914: *** The only supported starting compiler version is 3.0.0.
You are trying to build with 3.1.1..  Stop.
>
> BTW is  that msg  is correct? I just built with 3.0.2 , it seems that the
version block is not specific enough or the message missed a version bump.

Yes, the message is correct as you're trying to build trunk with a trunk
compiler (the Makefile even says you're trying to use 3.1.1). Only a
release compiler (currently 3.0.0 or 3.0.2) is supported.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Sven Barth via fpc-pascal]

Am 10.10.2017 08:49 schrieb :
> BTW why would anyone want
> {$WRITEABLECONST ON}
>
> writable constants is an oxymoron and goes against the whole philosophy
of strict types which is central to Pascal.

They were used mainly back at TP times to have procedure local static
variables (cause that is how they behave as inside procedures).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Graeme Geldenhuys]

On 2017-10-10 10:10, Tomas Hajny wrote:

If you read the original post up to the end,


Ah, my bad.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Tomas Hajny]

On Tue, October 10, 2017 11:08, Graeme Geldenhuys wrote:
> On 2017-10-10 10:00, Tomas Hajny wrote:
>> Apparently, Graeme forgot to include you in Cc:; including you in my
>> follow-up now...
>
> Why must I CC him as well? I simply press "Reply" and all my replies go
> to the fpc-pascal mailing list. Just like I've done with this email.

If you read the original post up to the end, you'll find out that the
original poster mentioned that he was not subscribed to the list and thus
would not receive e-mails sent just to the list.

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alternative name fpc cross

[Tomas Hajny]

On Tue, October 10, 2017 10:13, turro75 wrote:


Hi,

> when I create the cross compiler to arm-android and arm-embedded I get the
> same compiler name so unable to have both running in the same system.
> any workaround?

Are the two cross-compilers compiled with different options, or for
different endianess (in other words, are the executables different)?
Otherwise the same compiler binary should be usable for both targets.

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[Tony Whyman]

On 10/10/17 05:51, pasc...@piments.com wrote:
Were it not for the version restrictions in building fpc one could 
arguably say this was a reasonable assumption.  As it is, it leads to 
a very confused and confusing state which has taken several days to 
understand and untangle.



Maybe that could be addressed.

Thanks for the help along the way. 
I do make a lot of use of the cross-compiler and the cross-platform 
libraries capability of FPC and I am wondering if you might be looking 
at the problem in the wrong way, especially when you seem to be talking 
about using the cross-compiler for the Lazarus IDE. Here's how I use 
them and hopefully this will inform your own understanding.


1. When I develop a program using the Lazarus IDE, I am only working 
with the native (debug) libraries for the development platform. In my 
case, this is 64-bit Linux. Occasionally, I will run 64-bit Windows in a 
virtual machine and Lazarus (in native Windows mode) to test for Windows 
specific issues. During the development and test cycle I do not use 
cross-compilers or libraries and you would probably only need to do this 
when compiling for a target on which it is just not practical to run the 
Lazarus IDE.


2. The cross-compiler and libraries come into their own when I generate 
production executables and installation packages as they enable the 
whole process to be performed on the same platform (Linux 64-bit) for my 
required target platforms: Linux (32-bit and 64-bit) and Windows (32-bit 
and 64-bit), and automated using a single script - which then goes on to 
build the Debian packages and Windows installer packages.


3. I always compile FPC from source. For the development platform, a 
64-bit compiler is needed and the FPC RTL and FCL libraries include 
debug symbols. The Lazarus IDE compiles its libraries (LCL and 
components) using this compiler and the FPC libraries, and works very 
nicely without the user needing to understand too much about what is 
going on - or even having to do much in the way of IDE configuration.


4. For the production platform, a 32-bit cross complier is also needed 
as are optimised RTL and FCL libraries and optimised Lazarus libraries. 
These libraries have to be built explicitly for each of the production 
platforms. I have a separate location in the filesystem for the 
production libraries (separate from development libraries) with 
sub-directories for x86_64-linux, x86_64-win64, i386-linux, i386-win32. 
Within the Lazarus parts of the libraries, the Linux libs have the gtk2 
interface libraries, while the Windows ones have the win32 interfaces 
libraries (both win32 and win64).


5. I then use FPC Makefiles to build for each target platform in turn 
which reference the production and not the development libraries. This 
includes Lazarus programs and the Lazarus IDE does not have anything to 
do with this part of the process. Indeed, it would complicate matters no 
end to try and use the IDE to build for each production target.


If you have taken only a few days to dis-entangle all there is to know 
about cross compilation and cross platform libraries then I think you 
are doing very well. It has taken me far longer than that to work out 
the toolchain that I need and I am still learning the best way to do 
things. Indeed, there may be no "best way" to do things. The above works 
for me, but may not work for you. However, the advice that I would give 
is that as soon as you start to talk about cross-compilers, then you 
need to start thinking about the differences between development and 
production environments. Unless you are working with embedded systems, 
then my advice is don't try to work with cross-compilers for 
development. On the other hand, when you generate production executables 
then cross-compilers and cross platform libraries are very useful for 
automating the process and ensuring consistent quality across all target 
platforms. However, you do need to think through carefully how the 
toolchain works and explicitly generate optimised libraries for each 
target platform including the Lazarus interface appropriate for the 
target. Use the IDE for development but have a separate scripted 
environment for generating production executables.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Graeme Geldenhuys]

On 2017-10-10 10:00, Tomas Hajny wrote:

Apparently, Graeme forgot to include you in Cc:; including you in my
follow-up now...


Why must I CC him as well? I simply press "Reply" and all my replies go 
to the fpc-pascal mailing list. Just like I've done with this email.



Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Tomas Hajny]

On Tue, October 10, 2017 09:06, Graeme Geldenhuys wrote:
> On 2017-10-09 09:56, adrian.soentger...@web.de wrote:


Hello,

Apparently, Graeme forgot to include you in Cc:; including you in my
follow-up now...

>> i installed “fpc-3.0.2.i386-win32.cross.x86_64-win64” on my laptop with
>> windows 7, but there seem to be no fpc.exe file, so i can´t compile.
>
> For some odd reason the FPC team still don't produce a native 64-bit
> Windows compiler installation. They only make a cross-compiler install
> for 64-bit Windows. So you have to compile a native 64-bit compiler
> yourself, or install the 32-bit compiler installation, and then the
> 64-bit cross-compiler install (the part you did).
>
> I normally just build myself a native 64-bit Windows compiler. It's
> quick and easy to do.

Those "odd reasons" have fairly simple rationale in fact, but I'll skip
that part and focus the primary goal - the easy solution is installing
fpc-3.0.2.i386-win32.exe from the same location which you used for getting
the cross-comiler mentioned above. Or wait a few days and install the new
3.0.4 version right away. ;-)

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] alternative name fpc cross

[turro75]

Hi All,

when I create the cross compiler to arm-android and arm-embedded I get the
same compiler name so unable to have both running in the same system.
any workaround?

Regards 



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] no fpc.exe file after installation

[Graeme Geldenhuys]

On 2017-10-09 09:56, adrian.soentger...@web.de wrote:

i installed “fpc-3.0.2.i386-win32.cross.x86_64-win64” on my laptop with windows 
7, but there seem to be no fpc.exe file, so i can´t compile.


For some odd reason the FPC team still don't produce a native 64-bit 
Windows compiler installation. They only make a cross-compiler install 
for 64-bit Windows. So you have to compile a native 64-bit compiler 
yourself, or install the 32-bit compiler installation, and then the 
64-bit cross-compiler install (the part you did).


I normally just build myself a native 64-bit Windows compiler. It's 
quick and easy to do.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Juha Manninen]

On Tue, Oct 10, 2017 at 9:33 AM,   wrote:
> Now a patch has been integrated for this , perhaps it could be added to
> Lazarus  Project Options | Compiler Options | Parsing

Patches are welcome also for that.
The option must be either hidden for compiler versions that do not
support it, or there must be a clear note / hint about it.

Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TBufDataset vs TClientDataset

[LacaK]

Also, what's the difference between TBufDataset and TMemDataset? 
Aren't they both in-memory datasets? If so, why do we have two 
different components for the same thing?



As Michael wrote TMemDataSet is older.

And I add that it is also much "lighter". So for somebody who does not 
need "complexity" of TBufDataset there is IMO still space for TMemDataSet.
(IMO there is no need to emulate TMemDataSet by TBufDataSet ... there is 
TBufDataset a long time and everybody who needs his functionality can 
switch to TBufDataset without much effort)


There may be confusing with naming and purpose, but this can be easily 
solved by adding 1-2 sentences to documentation ...

I added one sentence to: http://wiki.freepascal.org/TMemDataset

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] no fpc.exe file after installation

[adrian.soentgerath]

Hello,

i installed “fpc-3.0.2.i386-win32.cross.x86_64-win64” on my laptop with windows 
7, but there seem to be no fpc.exe file, so i can´t compile.
In which folder should this file be? Where can i get it from?

Thanks for your answer!
Adrian

P.S.: I am not subscribed to a mailing list.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[pascalX]

On 08/10/17 21:24, leledumbo via fpc-pascal wrote:

There is my old feature request about it
https://bugs.freepascal.org/view.php?id=30344 :) You can monitor it.


No one seems to care to implement it, so if you badly need it:  sj.patch

Apply in compiler directory (please checkout r37430 at least), I only svn
diff there, not in the top level directory (I have modifications to certain
packages).



Now a patch has been integrated for this , perhaps it could be added to 
Lazarus  Project Options | Compiler Options | Parsing


BTW why would anyone want
{$WRITEABLECONST ON}

writable constants is an oxymoron and goes against the whole philosophy 
of strict types which is central to Pascal.



:?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Marco van de Voort]

In our previous episode, Mr Bee via fpc-pascal said:
> Thank you, both to Leledumbo and Sven. Will this patch be available in the 
> next FPC v.3.0.4 release?

Since it is already largely uploaded, no. We are only waiting on some
targets.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Mr Bee via fpc-pascal]

2017-10-08 23:17 GMT+07:00 Marcos Douglas B. Santos :

>
> Most developers are using single .inc file that contains all
> directives for the whole project.
>

Well, I don't like such approach. I prefer using my own shell script that I
can configure for many purposes and conditions such as build release, build
debug, build test, build deploy, etc. which each has different compiler
setting with custom before/after action.

-- 

Regards,


–Mr Bee
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] getting cross with the cross compiler

[pascalX]

On 08/10/17 10:12, Tomas Hajny wrote:

On Sat, October 7, 2017 22:13, pasc...@piments.com wrote:


Hi,

  .
  .

Can you offer any insights into what is going on with Lazarus not
locating the system unit and friends.  As you acknowledge they are
treated somewhat differently due to problems with the underlying
platforms.

I am wondering whether this enforced inconsistency with the generally
well organised structure could be leading to the problem.

It seems odd that fpc is finding them OK and Lazarus not.

It seems that fedora are doing something a little different in terms of
installation dirs, presumably a result of their way of providing
multilib 32/64 functionality where they install 64b libs in /usr/lib64
rather than /usr/lib.

I am wondering whether this has highlighted some assumption implicit in
the code about different version of libs being in the same place.

Do you have any ideas why the fpc can find the system.ppu etc and not
Lazarus?


Have you looked at FPC FAQ (in particular,
https://www.freepascal.org/faq.var#systemnotfound), or FPC documentation
(https://www.freepascal.org/docs-html/user/usersu7.html#x21-280003.1.2)?

FPC Wiki is an additional resource, there is some information related to
Lazarus as well - see
http://wiki.freepascal.org/Unit_not_found_-_How_to_find_units.

All of this might help you in finding differences; note that installation
packages created for specific Linux distributions may decide to modify the
default unit locations.

Hope this helps

Tomas




OK, I have got somewhere is finding out what is going wrong.


The trunk cross-compiler is installed and correctly linked. distro fpc 
will use it when the appropriate flags are supplied, however, Lazarus is 
not looking is the right place for the system libs and is NOT building 
them when they are are required. Which it claims to be able to do.


I was able to get cross compilation from Lazarus by installing and 
symlinkg  trunk ppcx64  but of course this breaks the ability of build 
anything else from the svn pull because of versions block.


$make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64 
INSTALL_PREFIX=/usr
Makefile:2914: *** The only supported starting compiler version is 
3.0.0. You are trying to build with 3.1.1..  Stop.


BTW is  that msg  is correct? I just built with 3.0.2 , it seems that 
the version block is not specific enough or the message missed a version 
bump.



There  are two conflicting conditions: fpc requires the system fpc to be 
older in order to build trunk but Lazarus is not smart enough to find ( 
or build ) the libs if ppc and ppcross are from different versions.


I don't know the mechanics of that but it would seem that there is an 
implicit assumption somewhere that ppc and ppcross are of the same 
version and this leads to it not finding the libs ( which are present  ) 
but not even trying to build them when they are "missing".


Were it not for the version restrictions in building fpc one could 
arguably say this was a reasonable assumption.  As it is, it leads to a 
very confused and confusing state which has taken several days to 
understand and untangle.



Maybe that could be addressed.

Thanks for the help along the way.






___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] compiler option for $J directive

[Mr Bee via fpc-pascal]

Thank you, both to Leledumbo and Sven. Will this patch be available in the next 
FPC v.3.0.4 release?

–Mr Bee
 

Pada Selasa, 10 Oktober 2017 04.44.44 WIB, Sven Barth via fpc-pascal 
 menulis:  
 
 
Am 08.10.2017 22:24 schrieb "leledumbo via fpc-pascal" 
:
>
> > There is my old feature request about it
> > https://bugs.freepascal.org/view.php?id=30344 :) You can monitor it.
>
> No one seems to care to implement it, so if you badly need it:  sj.patch
> 
> Apply in compiler directory (please checkout r37430 at least), I only svn
> diff there, not in the top level directory (I have modifications to certain
> packages).
>

Applied in r37437. Thank you for the patch.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal  ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal