Re: [fpc-pascal] FPC 3.0.4 released!

[pascalX]

On 03/12/17 17:36, Florian Klämpfl wrote:

Am 03.12.2017 um 18:20 schrieb kardan:

On Fri, 1 Dec 2017 21:02:30 +0100
Florian Klämpfl  wrote:


And? FPC is not debian/linux only.


If you are using windows I recommend to use a one of the many checksum
tools to verify downloaded files.> But for that, releases must publish
checksums for those files first.


Yes. And I were pointing out that your script does not help much as it is 
debian/linux only while we
create releases for several different OSes.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



How do I get off this list ?!

thx

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

Re: [fpc-pascal] Seek to EOF of file of byte

[pascalX]

On 18/11/17 20:27, Mark Morgan Lloyd wrote:
because the program is being viewed critically by the ALGOL programmer 
whose code


Algol, one my all time favourite languages.

while  wend
if  fi

why is this not universally adopted?

I still comment my C code with  fi's and wend's to keep track of what a 
bunch of curly braces actually refer to.


C : a high level language with power of assembler and the readability of 
   assembler.


Python : a high level language with the readability of assembler and 
performance of MSBASIC.


;)

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

Re: [fpc-pascal] FORTRAN from FreePascal

[pascalX]

On 18/11/17 20:14, Mark Morgan Lloyd wrote:
I think that conventional wisdom is that if somebody's written numerical 
analysis code you don't change it gratuitously, since any alterations 
will change rounding errors etc. For some reason, that seems to apply 
particularly to FORTRAN programs :-)



If you have no working knowledge of the language it is written in 
conventional wisdom is that you don't  change anything, gratuitously or 
otherwise.


to make any use of this code without understanding any of  it,  you will 
need some pretty thorough documentation of what it does, including 
accuracy, limitations and caveats.


My reaction to being presented with such a situation would be to dust 
off my 1980s punch card FORTRAN IV code, get up to speed and try to 
understand the code before attempting to use it.


Either that or you pay someone with the requisite knowledge to do the job.


my2c.

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

Re: [fpc-pascal] Problem with array of const

[pascalX]

On 29/10/17 00:31, Vojtěch Čihák wrote:

Looking to docs: https://www.freepascal.org/docs-html/ref/refsu69.html

I tried writeln(AnsiString(args[0].VAnsiString));

or just writeln(String(args[0].VAnsiString));

which works.

V.

__
 > Od: Darius Blaszyk 
 > Komu: FPC-Pascal users discussions 
 > Datum: 29.10.2017 00:59
 > Předmět: [fpc-pascal] Problem with array of const
 >

Consider the application below. When I run it I do get the following output:

name
rgname�F&{---C000-0046}

In other words I lose the first character (a) from the arguments 
supplied and the string returns with a lot of garbage. What am I doing 
wrong here?


Rgds, Darius

program test_args;

procedure test(name: string; args: array of const);
begin
   writeln(name);
   writeln(args[0].VString^);
end;

begin
   test('name', ['arg']);
end.


--



PS

In fact this page of doc linked by Vojtěch may need reviewing:

docs-html:


"Remark that this is not true for Delphi, so code relying on this 
feature will not be portable."


What is not "true"?  It is unclear exactly what "this" refers to. Should 
this be stating that cdecl modifier is not supported in Delphi?




"Remark: Note that there is no support for QWord arguments in array of 
const. This is for Delphi compatibility, "


Huh?

   vtWideString : (VWideString: Pointer);
   vtInt64  : (VInt64: PInt64);
   vtQWord  : (VQWord: PQWord);
   end;


Also all the code examples are displayed using the wrong quote character 
and copying the code results in tons of syntax errors.  If this was done 
to make mark-up easier it should at least be noted in the About this 
Guide, Notations section.  Preferably the code should paste and work.



the testit example requires a mode but this is not included as is 
promised in  About this Guide.

{$mode objfpc}


Further typos suggest is was never tested:

Writeln (’AnsiString, value :’,AnsiString(Args[I].VAnsiString);

missing parenthesis at end of line.

   Writeln (’No aguments’);

aguments ??

  Therefor, inside the procedure body,

Should be "Therefore". Therefor is a different word.





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

Re: [fpc-pascal] Problem with array of const

[pascalX]

On 29/10/17 00:31, Vojtěch Čihák wrote:

Looking to docs: https://www.freepascal.org/docs-html/ref/refsu69.html

I tried writeln(AnsiString(args[0].VAnsiString));

or just writeln(String(args[0].VAnsiString));

which works.

V.

__
 > Od: Darius Blaszyk 
 > Komu: FPC-Pascal users discussions 
 > Datum: 29.10.2017 00:59
 > Předmět: [fpc-pascal] Problem with array of const
 >

Consider the application below. When I run it I do get the following output:

name
rgname�F&{---C000-0046}

In other words I lose the first character (a) from the arguments 
supplied and the string returns with a lot of garbage. What am I doing 
wrong here?


Rgds, Darius

program test_args;

procedure test(name: string; args: array of const);
begin
   writeln(name);
   writeln(args[0].VString^);
end;

begin
   test('name', ['arg']);
end.


--

___
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




  vtString : (VString: PShortString);


in short the compiler is  sending  AnsiString and you are then telling 
it to interpret this as a traditional pascal string of length 97.  The 
Tvarrec  in the Array of const effectively removes the usual strong type 
checking you get with Pascal.


string literals now get compiled as AnsiString unless you explicitly 
assign them to a typed constant:



program test_args;
{$mode objfpc}

procedure test(name: string; args: array of const);
begin
  writeln(name);
  writeln(args[0].VString^);
end;

const  sh:shortstring='sconst';
var s:shortstring='arg';

begin
  test('name', [s]);
  test('name', [sh]);
end.


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

Re: [fpc-pascal] Overloaded functions

[pascalX]

On 28/10/17 23:54, Darius Blaszyk wrote:
Thanks! This is in line with what I was suspecting. However, why in the 
world does the compiler not warn in this case. This should be at least 
happening I would suppose?


Darius

Vojtěch Čihák schreef op 28 okt '17:

Overloading means that you have functions with the same name but 
different parameter (or param. list). You can have different return 
type for each parameter but you can never have the same parameters.


V.

__
> Od: Darius Blaszyk 
> Komu: FPC-Pascal users discussions 
> Datum: 28.10.2017 22:58
> Předmět: [fpc-pascal] Overloaded functions
>

Hi,

I have a problem with overloaded functions. I defined these functions:
function val_(name: string): string;
function val_(name: string): boolean;
function val_(name: string): integer;
function val_(name: string): double;

var
  res: boolean;
begin
  res := val_(option_variable);
end;

I get the following error: Error: Incompatible types: got 
"ShortString" expected "Boolean". So for some reason the compiler is 
looking at the first function. The mode is objfpc and I turned 
ansistrings off. I tested by adding the overload modifier but without 
result. What else could I try or do? Or is overloading only allowed 
for different parameter lists?


Rgds, Darius




Agreed.  The following incorrect override compiles without any problems. 
Since the second definition is inaccessible, it should probably get 
rejected by the compiler, or at least create a warning.


function val_(name: string): string;
begin
end;

function val_(name: string): boolean;
begin
end;




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

Re: [fpc-pascal] CRT unit and Windows' terminal

[pascalX]

On 16/10/17 13:03, James Richters wrote:
 >Long story short: CRT unit doesn't work at all on Windows, but it 
works with unicode on Mac/Linux.


I’m curious how the CRT unit handles the Extended ASCII codes on Mac and 
Linux…  All versions should be the same for cross platform compatibility.


I also noticed that email broke my links with spaces in them, so I made 
an index link with all the links and a zip file with all test programs 
and screen shots.


Index File

http://www.productionautomation.net/FPC/ASCII/index.htm

Zip file

http://www.productionautomation.net/FPC/ASCII/BoxCharacters.zip

James.




A URL can have a space in it but must be encoded  "percent two zero" , 
if you copy what is displayed in the address bar you probably get a 
space char not the encode version.


Short answer is don't use spaces is file names ;)

That will avoid having to put quotes around everything or relying on GUI 
software which silently  does this for you or encodes them or whatever.


Since spaces are the primary delimiter on computer input, it makes sense 
to avoid using them in something you do not want delimiting.


For CRT,  it would be nice if this could be made to work consistently 
across platforms.



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

Re: [fpc-pascal] CRT unit and Windows' terminal

[pascalX]

On 13/10/17 14:39, James Richters wrote:
I‘ve tried Writeln(Chr(9556)) but chr() has a limit of 255, and I’ve 
tried just Writeln(#9556) and while that compiles and runs, it doesn’t 
produce the correct character.. I have a feeling (but have not tested 
it) that it keeps cycling around the first 256 characters if you use 
anything above 255….. pretty sure a character is defined as a byte here.



Thanks for that lengthy description of the problem, much better than 
OP's just describing output as rubbish, or something similar.


since char is a single byte type a large value will just get truncated. 
If you turn on range checking it should return a compiler time error. 
You could check that.


Maybe doing that would cast some light on what is going wrong in CRT as 
well.


P

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

Re: [fpc-pascal] where's the glyph?

[pascalX]

On 11/10/17 13:28, Sven Barth via fpc-pascal wrote:
Am 11.10.2017 13:13 schrieb >:

 >
 > Hi,
 >
 > LCL provides the usual Delphi equivalent components like TBitBtn and 
TSpeedButton  but there do not seem to be any glyphs to go with them.

 >
 > Do I really have to make my own or are there some resources I have 
not found ?


Lazarus/LCL questions are best asked on the lazarus mailing list ( 
http://lists.lazarus-ide.org/listinfo/lazarus ). While quite some of the 
devs there read here as well, you'll get even more feedback regarding 
Lazarus/LCL topics there.


Regards,
Sven





yes, sorry. I will try to restrict questions here to fpc.

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

Re: [fpc-pascal] Const params question

[pascalX]

On 11/10/17 13:11, Michael Van Canneyt wrote:

Delphi has recently


Huh? I thought Delphi got shut down years ago.

:?

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

Re: [fpc-pascal] where's the glyph?

[pascalX]

On 11/10/17 12:23, Vojtěch Čihák wrote:

Hi,

TBitBtn has property Kind, setting it to anything else than bkCustom 
will show the glyph (native, from widgetset).


With TSpeedButton, you are always on your own.

V.



Hi,

LCL provides the usual Delphi equivalent components like TBitBtn and
TSpeedButton  but there do not seem to be any glyphs to go with them.

Do I really have to make my own or are there some resources I have not
found ?

Thanks.


Oh, of course.  It is longer than I realised since I've used Delphi !

For the other glyphs I guess I'll have to install one of my old D1 or D2 
CDs and dig them out..


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

Re: [fpc-pascal] {$DEFINE DEVEL}

[pascalX]

On 11/10/17 12:00, Mattias Gaertner wrote:

On Wed, 11 Oct 2017 11:45:33 +0100
pasc...@piments.com wrote:


[...]
It wasn't a reply because they was no Re and it had a new title.

I should have deleted the  [fpc-pascal]  as well . Sorry.


A reply is not defined by the title. It is marked by the hidden
References aka In-Reply-To fields, that a mail client inserts when
clicking reply.

Mattias
___


Ah thanks I was not aware of that.  I'll stop doing it that way.






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

[fpc-pascal] where's the glyph?

[pascalX]

Hi,

LCL provides the usual Delphi equivalent components like TBitBtn and 
TSpeedButton  but there do not seem to be any glyphs to go with them.


Do I really have to make my own or are there some resources I have not 
found ?


Thanks.


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

[fpc-pascal] {$DEFINE DEVEL}

[pascalX]

Hi ,

I had a little trick that I used on BP and Delphi code that does not 
work on Lazarus.


I define compiler variable which I could toggle on and off by adding a 
second opening curly bracket, since the define only works if the line 
starts {$



{$DEFINE DEVEL}


If I start the line {{$  Delphi ignores it but Lazarus then highlights 
the rest of the code as a comment and it fails to compile.


main.pas(172,1) Warning: Comment level 2 found


Is this a bug or a feature?

Can anyone suggest a similar one key trick ?

thx
___
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] 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

[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] 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] 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] getting cross with the cross compiler

[pascalX]

On 07/10/17 19:55, Florian Klämpfl wrote:

Am 07.10.2017 um 12:14 schrieb Sven Barth via fpc-pascal:

Am 07.10.2017 11:11 schrieb "Karoly Balogh (Charlie/SGR)" 
>:


Hi,

On Sat, 7 Oct 2017, Sven Barth via fpc-pascal wrote:


So where is my cross compiler ??

Thanks for any help and suggestions.


A single compiler binary can always compile for all supported targets of
that processor. So as long as all the units are available you simply
need to pass "-Twin64" as additional parameter to compile for
x86_64-win64.


Sigh. :) Any reason why Windows is different? No other OS has different
target arguments for different CPUs, because the CPU type already
specifies if its for 32 or 64bit... (fix me?)


Because MS called the apis win32/win64.



I had asked the same some time ago and the historic reason was that especially 
the system unit was
considered too different to have both of them be the same target... I don't 
agree either, but that's
how it is... :/


Well, this is another story, win32/win64 can easily share as much as possible

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



Hi Florian,

firstly may I take the opportunity to congratulate you on what have 
managed to do in creating fpc and lazarus.  Despite what seems like a 
few outstanding quirks it is an amazing achievement.


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?


Thanks for any insights.






___
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 07/10/17 11:14, Sven Barth via fpc-pascal wrote:
Am 07.10.2017 11:11 schrieb "Karoly Balogh (Charlie/SGR)" 
>:

 >
 > Hi,
 >
 > On Sat, 7 Oct 2017, Sven Barth via fpc-pascal wrote:
 >
 > > > So where is my cross compiler ??
 > > >
 > > > Thanks for any help and suggestions.
 > >
 > > A single compiler binary can always compile for all supported 
targets of

 > > that processor. So as long as all the units are available you simply
 > > need to pass "-Twin64" as additional parameter to compile for
 > > x86_64-win64.
 >
 > Sigh. :) Any reason why Windows is different? No other OS has different
 > target arguments for different CPUs, because the CPU type already
 > specifies if its for 32 or 64bit... (fix me?)

I had asked the same some time ago and the historic reason was that 
especially the system unit was considered too different to have both of 
them be the same target... I don't agree either, but that's how it is... :/


Regards,
Sven




OK  so the earlier statement was not strictly true, and I do need an fpc 
build which has been build with the cross compiler. This seems to be 
missing from the distro pkg which is why I got myself several days work 
trying to set this up from trunk.


This is all made more complicated  by having to keep the distro fpc to 
build trunk.


Now I have two different version , with trunk being able to cross 
compile a win64 exe of my hello.pas.


This seems fine from command line but when I try to use Lazarus to with 
project options specifying a Win64 target , it fails to find system.ppu 
and friends. The project builds and runs native.



HINT: using config file /etc/fpc.cfg
ERROR: compiled FPC unit not found: system.ppu
ERROR: compiled FPC unit not found: objpas.ppu
ERROR: compiled FPC unit not found: sysutils.ppu

Laz does seem to be sending the right args to fpc ( presumably to fpc )

Info: (lazarus) Execute Title="Test: Compiling an empty file"
Info: (lazarus) Working Directory="/tmp/"
Info: (lazarus) Executable="/usr/bin/fpc"
Info: (lazarus) Param[0]="-Twin64"
Info: (lazarus) Param[1]="-Px86_64"
Info: (lazarus) Param[2]="-MObjFPC"
Info: (lazarus) Param[3]="-Scghi"
Info: (lazarus) Param[4]="-O1"

I had to move the trunk libs to /usr/lib64 to be in the same place as 
the distro files and thus agree with fpc.cfg settings.


I am wondering whether this non-std position of the libs is highlighting 
a a bug in Lazarus assuming /usr/lib . It seems odd that command line 
fpc works but laz fails to find the libs.


Can you make any sense of this?

thx
___
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 07/10/17 10:01, Sven Barth via fpc-pascal wrote:
Am 07.10.2017 10:57 schrieb >:

 >
 > Hi,
 >
 > I am having trouble getting fpc to cross-compiler for win64 target.
 >
 > I'm using fedora 26 which supplies 3.0.2
 >
 > I used instructions here to create the cross compiler using trunk fpc 
since the fedora fpc-src does not seem to have the full Makefile structure:

 >
 > 
http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux#Free_Pascal

 >
 > I have a simple test file:
 >
 > {$MACRO ON}
 > program Hello;
 > begin
 >   Writeln('Hello world, from FPC ', FPC_FULLVERSION, '!');
 > end.
 >
 >
 > This builds fine using the stock fpc 3.0.2 with linux target.  
However, the supposed cross-compiler seems to be trying to build for linux.

 >
 > $/usr/lib/fpc/3.1.1/ppcrossx64  /back/coredata/hello.pas
 > Free Pascal Compiler version 3.1.1 [2017/10/06] for x86_64
 > Copyright (c) 1993-2017 by Florian Klaempfl and others
 > Target OS: Linux for x86-64
 > Compiling /back/coredata/hello.pas
 > Fatal: Can't find unit system used by Hello
 > Fatal: Compilation aborted
 >
 >
 > $/usr/lib/fpc/3.1.1/ppcrossx64  -iTO
 > linux
 >
 >
 >
 > So where is my cross compiler ??
 >
 > Thanks for any help and suggestions.

A single compiler binary can always compile for all supported targets of 
that processor. So as long as all the units are available you simply 
need to pass "-Twin64" as additional parameter to compile for x86_64-win64.


Regards,
Sven



PS.  with my current set up, if I specify -Twin64  fpc uses the cross 
compiler I built from trunk 3.1.1 , if I build native ( without -T )  it 
uses the distro 3.0.2


What is happening there if all versions handle all platforms. ;?

thx

___
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 07/10/17 10:01, Sven Barth via fpc-pascal wrote:
Am 07.10.2017 10:57 schrieb >:

 >
 > Hi,
 >
 > I am having trouble getting fpc to cross-compiler for win64 target.
 >
 > I'm using fedora 26 which supplies 3.0.2
 >
 > I used instructions here to create the cross compiler using trunk fpc 
since the fedora fpc-src does not seem to have the full Makefile structure:

 >
 > 
http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux#Free_Pascal

 >
 > I have a simple test file:
 >
 > {$MACRO ON}
 > program Hello;
 > begin
 >   Writeln('Hello world, from FPC ', FPC_FULLVERSION, '!');
 > end.
 >
 >
 > This builds fine using the stock fpc 3.0.2 with linux target.  
However, the supposed cross-compiler seems to be trying to build for linux.

 >
 > $/usr/lib/fpc/3.1.1/ppcrossx64  /back/coredata/hello.pas
 > Free Pascal Compiler version 3.1.1 [2017/10/06] for x86_64
 > Copyright (c) 1993-2017 by Florian Klaempfl and others
 > Target OS: Linux for x86-64
 > Compiling /back/coredata/hello.pas
 > Fatal: Can't find unit system used by Hello
 > Fatal: Compilation aborted
 >
 >
 > $/usr/lib/fpc/3.1.1/ppcrossx64  -iTO
 > linux
 >
 >
 >
 > So where is my cross compiler ??
 >
 > Thanks for any help and suggestions.

A single compiler binary can always compile for all supported targets of 
that processor. So as long as all the units are available you simply 
need to pass "-Twin64" as additional parameter to compile for x86_64-win64.


Regards,
Sven



Thanks Sven,

I have resolved this issue. It was due to having a distro based fpc 
which installs in /usr/lib64  and svn trunk which installs in /usr/lib .


Once I reunited both under /usr/lib64 I was able to compile native and 
cross versions. of my test prog.


I'm a little unclear when you say any compiler can always compile for 
all supported targets. All I have read indicates a specific make 
sequence to get a cross compiler.


make all OS_TARGET=win32 CPU_TARGET=i386
make crossinstall OS_TARGET=win32 CPU_TARGET=i386


Could you clarify ?

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