Hello,

We have placed the first release-candidate of the Free Pascal Compiler version 2.6.0 on our ftp-servers.

You can help improve the upcoming 2.6.0 release by downloading and testing this release. If you want you can report what you have done here: http://wiki.freepascal.org/Testers_2.6.0

Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.0

Downloads are available at the FTP server at:

ftp://freepascal.stack.nl/pub/fpc/beta/2.6.0-rc1/

Enjoy!

The Free Pascal Compiler Team

Free Pascal Compiler

Version 2.6.0rc1

****************************************************************************** What's New in 2.6.0rc1
******************************************************************************

Free Pascal 2.6.0 is a new major version of the Free Pascal compiler.

Please also see http://wiki.freepascal.org/User_Changes_2.6.0 for a list of changes that may affect the behaviour of previously working code, and how to cope with these changes.

Some highlights are:

Platforms:
* iPhoneSimulator target

Compiler:
* Many new language features:
* Objective-Pascal dialect, supported on all Mac OS X and iOS targets
* constref parameter modifier for "const by reference"
* Pascal boolean types with multiple sizes (boolean16/32/64)
* ISO 7185 language mode (except for I/O). Features amongst others:
* nested procedure variables
* non-local goto's
* Mac Pascal mode improvements
* nested procedure variables
* univ modifier
* Intrinsics
* sar (shift arithmetic right)
* bsf/bsr (bitscan forward/reverse)
* Delphi compatibility mode improvements
* Nested types, class variables and class local constants
* Advanced records syntax (no constructors yet)
* (for..in) Enumerators in records
* Class and record helpers
* Generic records, arrays and procedural types
* Delphi-compatibility of generics improved
* Scoped enumerations
* Custom messages for "deprecated" directive
* Ability to use "&" for escaping keywords
* New ARM code generator features
* ARM VFPv2 and VFPv3 floating point unit support
* Thumb-2 support

Packages:
* Many improvements to the rtl
* Many improvements to the database units (fcl-db)
* Objective-Pascal interfaces to Foundation, AppKit, CoreData and WebCore
* OpenGL headers updated to OpenGL 4.0

Details about these new features can be found at
http://wiki.freepascal.org/FPC_New_Features_2.6.0

See http://bugs.freepascal.org/changelog_page.php for the list of reported bugs that have been fixed in this release.

Marco van de Voort wrote

Downloads are available at the FTP server at: ftp://freepascal.stack.nl/pub/fpc/beta/2.6.0-rc1/

Cant download

550 /pub/fpc/beta/2.6.0-rc1/: Permission denied.

Luiz

2011/11/5 Luiz Americo Pereira Camara :

x(

http://imagebin.org/182703

ditto... :-(

Ralf

06.11.2011 3:47, Luiz Americo Pereira Camara пишет:

ftp://ftp.freepascal.org/pub/fpc/beta/2.6.0-rc1/

We have placed the first release-candidate of the Free Pascal Compiler version 2.6.0 on our ftp-servers.

Congratulations! That's an impressive list of new features. I've been anticipating this release for some time.

A couple of questions: where can this be found in svn? I don't see a tag for it, and fixes_2_6 hasn't been modified for 8 weeks or so.

Secondly, will there be additional merges from trunk to fixes_2_6? If I recall the last time I checked the page with the list of potential merges from trunk to fixes_2_6 I believe it was quite long. Particularly I was hoping for revision 19036 (resolving issue 19404, fixing shared library loading and unloading for Linux platforms) to make it into the 2.6 release.

Again, congratulations. I'll start using the release candidate next week at work and will report any issues I find.

-SG

Seth Grover wrote

A couple of questions: where can this be found in svn? I don't see a tag for it, and fixes_2_6 hasn't been modified for 8 weeks or so.

http://svn.freepascal.org/svn/fpc/tags/release_2_6_0_rc1/

Jonas

Jonas, thanks for the link. For some reason it wasn't showing up on the viewvcs interface until I cleared my browser cache and refreshed.

Thanks again.

-SG

In our previous episode, Luiz Americo Pereira Camara said:

Fixed.

Seems that Freepascal Wiki is not available. If someone can access it post the information on changes into here please...

-Tee-

We have placed the first release-candidate of the Free Pascal Compiler version 2.6.0 on our ftp-servers.

Here some issues I found:

The text mode IDE states under "Help": Copyright (C) 1998-2009 by... Shouldn't this be "1998-2011"?

When I now try to compile a short test program with the IDE I get: "Error: Illegal parameter: -Cp386"
This was a setting I used before. Has this been changed? When I remove this parameter and try again I get:
"Fatal: Unable to open file D:\vpascal\FreePascal\fp.cfg" "Fatal: Compilation aborted"
The file exists and was used on the first compiler run but it seems it was not closed properly on error.

http://wiki.freepascal.org/Testers_2.6.0 http://wiki.freepascal.org/User_Changes_2.6.0

These links are not reachable.

So FPC can now compile to java byte code.

I don't even have Java installed on Windows because on Windows it's a security risk.

Nice to see some more virtual instruction set support though.

I'd like to see compile to redcode or compile to cuda/ptx ;)

Also let me ask one question about "Delphi" mode:

If free pascal is put in Delphi mode does this prevent any "free pascal specific language extensions" so that the programmer can be sure that the program written in free pascal will compile in Delphi as well ?

Bye,
Skybuck.

It appears to be back up again now.

Jonas

In our previous episode, J?rgen Hestermann said:

I will correct that.

The problem here might be some old configuration file.

In our previous episode, Seth Grover said:

(Jonas already replied to this)

There will be some minor post RC1 fixes before the release, these will be merged through fixes. To make that process easier (and avoid errors), fixes is currently frozen.

After the final release, fixes will be unfrozen, and the normal merging will resume (though it will take a week or two to work away the backlog. This because more risky commits are only merged a few at a time)

Yes, that is the case. Still there are problems: If I delete the parameter in the IDE and try again to compile it it should work. But when doing so I get the "unable to open file ...fp.cfg" error. It seems that the IDE does not close the config file properly on error so that it now has problems to reopen it. And although I have checked to save all configurations the deletion of the parameter is not stored. On next startup the same parameter reappears. But when I delete the parameter directly after startup and compile then everything works ok. In this case the IDE was able to save the changes into fp.cfg. But it fails doing so if the error "illegal parameter" has appeared first.

HI,

Does this release include intrinsic ROL & ROR?
'Bug' 6300 is shown as fixed, but I can find no mention in the new features list.

http://bugs.freepascal.org/view.php?id=6300

Yes, RolByte/Word/Dword/QWord are implemented in 2.6.0rc1.

I've added it to the wiki page.

Jonas

I am happy to say that the RPM can now be installed cleanly in Mageia Linux (and therefore I suppose that in Mandriva and PCLinuxOS too), thats to the clever fix by Joost. Thanks a lot =)

Hello,

What is: fpc-2.6.0rc1.arm-linux.tar
?

Is it supposed to run on arm-linux or is it a cross-compiler x86-linux -> arm-linux?

Hi,

-------- Original-Nachricht --------

It is a native arm-linux compiler, running on arm-linux.

A cross-compiler from x86-linux would be located in the i386-linux or x86_64-linux directory on the ftp (and I believe there is/was some special naming scheme that indicates the crosscompiler nature too).

None of the regular FPC release builders made a cross-compiler of that particular type. If somebody provided a cross-compiler release, I am sure the fpc team would make it available on the FPC FTP.

Thomas

Congratulations to the FPC team!

May I request that the arm-linux port be built with recent binutils, please? The elf binaries in this release report version 4 eabi, while version 5 is the current version. I read somewhere that version 4 was only used in pre-releases of the abi.

Henry

I have downloaded the tar-based installation for i386-linux and the installation succeeded up to the point of writing the configuration file (note: I have set my prefix to /mnt/data/applications/fpc/2.6.0):

=== output begin ===

[snip]

Running on linux
No write premission in /etc.
Writing sample configuration file to /home/sven/.fpc.cfg /mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/samplecfg: Zeile 70: fpcmkcfg: Kommando nicht gefunden.
Writing sample configuration file to
/mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/ide/text/fp.cfg /mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/samplecfg: Zeile 78: fpcmkcfg: Kommando nicht gefunden.
Writing sample configuration file to
/mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/ide/text/fp.ini /mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/samplecfg: Zeile 82: fpcmkcfg: Kommando nicht gefunden.
Writing sample configuration file to /home/sven/.config/fppkg.cfg /mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/samplecfg: Zeile 91: fpcmkcfg: Kommando nicht gefunden.
Writing sample configuration file to /home/sven/.fppkg/config/default /mnt/data/applications/fpc/2.6.0/lib/fpc/2.6.0/samplecfg: Zeile 95: fpcmkcfg: Kommando nicht gefunden.

End of installation.

Refer to the documentation for more information.

=== output end ===

It says "command not found", but at that path the "samplecfg" application does indeed exist and does have it's executable bit set.

I personally don't mind that it wasn't able to execute, cause thus my 2.4.4 configuration wasn't screwed (I again forgot to save that ^^), but I thought that I should mention this.

Regards,
Sven

Hi,

on upcoming Freebsd 9 (RC2) it is necessary to do something like this on trunk:

svn diff -r 19175:19176 > bsd_sem_patch.diff

and then apply the patch to svn fixes 2.6 branch (works cleanly)

patch -p0 -i bsd_sem_patch.diff

without that using threads and or semaphores crash on FreeBSD 9.

It would be nice if this patch could make it into fpc 2.6 to allow binary release users an easier start.

helmut

I have a question about the structure of the svn.

The branch fixes_2_6 still has the version 2.5.1. shouldn't this be set to 2.6.0-RC1.1? to indicate that this is always the newest 2.6.x version (newer than any 2.6 release or candidate ever released from this branch) and as such already newer than 2.6.0-RC1?

2.5.1 for the 2.6 fixes branch seems a bit counterintuitive to me. It seems the RC1 has been tagged and *then* afterwards the tag has been modified to update the version number. Shouldn't this rather have happened the other way around, something like this:

in fixes_2_6 change version to 2.6.0-RC1
create tags/release_2_6_0_RC1
in fixes_2_6 change version to 2.6.0-RC1.1 (odd number between two RC)

fix bugs...

in fixes_2_6 change version to 2.6.0-RC2
create tags/release_2_6_0_RC2
in fixes_2_6 change version to 2.6.0-RC2.1

fix bugs...

in fixes_2_6 change version to 2.6.0 (no more RC needed) create tags/release_2_6_0
in fixes_2_6 change version to 2.6.1

fix bugs...

so that the fixes branch always at any time has the highest version number of this branch, higher than everything released from this branch so far?

Bernd

Isn't it possible to put all processors in the compiler. At least ARM and 8086 because they are the most popular. As I know now it is one compiler program each processor. Just a question.

Bernd wrote

The branch fixes_2_6 still has the version 2.5.1. shouldn't this be set to 2.6.0-RC1.1?

No. Only releases have even version numbers (RC or not). Branches are only updated to the next version number (in this case, that will be 2.6.1) once the corresponding release is final.

Jonas

Rainer Stratmann wrote

Isn't it possible to put all processors in the compiler.

In theory, that would be possible with lots of rewriting. In practice there is little or no reason to spend time on that. You can always use "fpc -Pi386" and "fpc -Parm" to call the different ppc* binaries (which is why the "fpc" binary exists).

Jonas

2011/11/24 Jonas Maebe :

> The branch fixes_2_6 still has the version 2.5.1. shouldn't this be > set to 2.6.0-RC1.1? No. Only releases have even version numbers (RC or not).

Thats why I wrote RC1.1 to solve this dilemma, to give it an odd number between RC1 and RC2.

It's not about the RCx, but about the 2.6.0. As long as fixes_2.6 still contains the not released version it is a 2.5.1. Only afterwards it will become a 2.6.1.

Regards,
Sven

2011/11/24 Sven Barth :

It's not about the RCx, but about the 2.6.0.

Yes, I understand the intention. But this leads to the dilemma that now the branch which is by definition always same or more advanced than the last release(candidate) from it still has a *lower* version number than the already released release candidate itself. Thats the main thing that is so confusing about it. It also leads to the necessity to modify the tag after tagging which is considered bad practice. The branch should already have the RC1 version number at the very moment of tagging and then move onwards from there so that the branch version is always higher than the last tagged version.

I hope you can at least see now where I see the problem.

Its not so super important, it was just confusing to me because it makes it somewhat inconsistent, thats why I suggested to make the numbering and branching more consistent. Initially I really thought I had gotten something wrong when I started using the 2_6 branch and it installed itself into the old 2.5.1 directory, i intuitively expected the 2_6 branch would also carry a 2.6 version number.

Bernd

Bernd wrote

Yes, I understand the intention. But this leads to the dilemma that now the branch which is by definition always same or more advanced than the last release(candidate) from it still has a *lower* version number than the already released release candidate itself.

The RC moniker is only part of the long version number (2.6.0-RC1), not of the short version number (2.6.0). It cannot be made part of the short version number because e.g. in Pascal code, you can do {$if FPC_FULLVERSION >= 20600} (">= 20600RC1" does not make sense). It would also require installing the files for the RCs on unix platforms in lib/fpc/2.6.0-rc1/..., and hence different interpretation of the $fpcversion compiler macro etc. And having an svn development branch of which the short version number is 2.6.0 is what would really have the potential to create lots of confusion.

Jonas

Bernd wrote

number than the already released release candidate itself. Thats the main thing that is so confusing about it. It also leads to the necessity to modify the tag after tagging which is considered bad practice.

Don't worry, you are not alone. I also find this way of applying version numbering (rc releases specifically) confusing. Other projects handle RC releases much better. If definitely becomes problematic if you are using "a to be released as stable" version of FPC and you have code that you need to {$IF FPCVER...} - the versioning is all wrong, until the stable release is actually released, which means you need to revisit your code again too. :-(

Also regarding tagging. The FPC and Lazarus projects do not distinguish between branches and tags. They treat them both as the same thing, even apply commits to tags. Very bad practice indeed, or just the remnants of a bad version control system.

In our previous episode, Bernd said:

There have been discussions in the past, and changing the version in fixes early makes merging through (fixes for rc1 and final are merged from trunk through fixes to their own branch) it harder, which is why I'm not a fan.

IMHO this is micromanaging with a vague "confusion" banner stamped on it. If people are so easily confused, they should stay away from development branches. Specially since fixes_2_6 is an exact copy of RC1 except for the version, so there is no real motivation to use it.

2011/11/25 Marco van de Voort :

If people are so easily confused, they should stay away from development branches.

This is supposed to be a stable branch and there is no need for personal attacks.

Specially since fixes_2_6 is an exact copy of RC1 except for the version, so there is no real motivation to use it.

Its just a coincidence that they are still identical. The motivation for using subversion instead of doing a full download on every release is to always have the latest 2.6.x plus all the latest fixes for it.

Until recently I have been using the latest trunk all the time, only during the last few months I had some problems with it, some revisions didn't even compile on my system due to some major work going on in the RTL and I finally decided to change down a gear and stay with the latest stable branch for a while.

Bernd

No, it will become a new stable branch once 2.6.0 is released.

There is no 2.6.x release yet. If you want something stable, stay in 2.4.x until 2.6.0 is released.

That makes sense, but you are in a wrong branch then.

Tomas

> and I finally decided to change down a gear and stay with the > latest stable branch for a while. That makes sense, but you are in a wrong branch then.

I wanted to switch down one gear, not two. What would be the correct 2.6 stabilizing/soon-to-become-stable branch if this is the wrong one?

I wanted to switch down one gear, not two. What would be the correct 2.6 stabilizing/soon-to-become-stable branch if this is the wrong one?

As far as I understand it, versions with odd digits after the decimal point are "unstable" and even numbers are "stable". So the stable versions are 2.0, 2.2, 2.4 and the next will be 2.6. The odd numbers 2.1, 2.3, 2.5 are the once under construction until they become the next even number (2.5 will become 2.6 soon).

In our previous episode, Bernd said:

Only after 2.6.0. Though the situation is not really different for a .2 or .4 release, only shorter.

and there is no need for personal attacks.

It wasn't one. It is simply that following development (non releases) requires some skill.

> Specially since fixes_2_6 is an exact copy of RC1 except for the > version, so there is no real motivation to use it. Its just a coincidence that they are still identical.

No, that is done on purpose, partially also because merging is now very complicated because of some fpmake differences between trunk and fixes/2.6.0, and I don't want to add another dimension.

The motivation for using subversion instead of doing a full download on every release is to always have the latest 2.6.x plus all the latest fixes for it.

Yes, but as said fixes_2_6 is now not in that is the stable candidate, nothing more. That's also why the number hasn't advanced and it is still 2.5.1

While much could be done about this, it means a lot more work and worse, chances to introduce mistakes, for very little benefit.

In our previous episode, Bernd said:

2.6.0rc1 is the newest there is on the 2.6 branches. Merging will only resume after 2.6.0 is in a final state. (IOW most post RC1 fixes have been merged, most emergency patches are relatively small, and fixing them up is manually easy)