Hi, I was looking to try FPC but I saw the latest release isn't available for Solaris, only 2.4something. Do you guys plan on releasing the new version on Solaris? Do you intend to keep supporting Solaris?

Sorry if this is a duplicate. I sent it from my phone yesterday but it has not shown up yet, possibly due to the html issue.

I was looking to try FPC and I downloaded the Linux version. I saw the latest release isn't available for Solaris.

Do you guys plan on releasing the 2.6.0 version on Solaris and is there a timeframe? Do you plan on continuing to support Solaris? I would be interested in running both the Intel and SPARC versions if they come available.

Another question is on 2.6.0 on Linux. I cannot run the fp ide because I have glibc 2.9. The error message I get says

fp: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by fp)

That is really a recent version! Even the latest Slackware from 1 year ago only has glibc 2.13. Is this really needed or can it be built against my version of glibc?

I have various other stuff going wrong when trying to build some of the samples like the fpc compiler not being able to find certain libraries. Should I post the error messages here or should I look for a bug tracker? I am not sure anything is a bug since I am new to all this. I installed into my home directory and am using all the defaults.

Thank you.

2.6.0 is available for intel from
ftp://ftp.freepascal.org/pub/fpc/dist/2.6.0/i386-solaris/fpc-2.6.0.i386-sola ris.tar.gz and
ftp://ftp.freepascal.org/pub/fpc/dist/2.6.0/x86_64-solaris/fpc-2.6.0.x86_64- solaris.tar.gz

Ludo

Thanks a lot, I will try them out.

Do you happen to know why they aren't shown from the downloads page on freepascal.org?

There is a directory for Solaris SPARC but it is empty. Is it possible to get 2.6.0 for Solaris SPARC? Thanks again.

I'm not the right one to answer this question but I believe that this depends mainly on availability of a maintainer for this operating system. You may try building the compiler (and RTL) for that platform and it may work well for you, but you may encounter some issues.

It should be possible to build against your version of glibc, but you'll probably have to do it yourself (or use FPC binaries provided by your distribution). Search for 'buildfaq.pdf' in order to learn more on how to build FPC yourself. Make sure to also have libgdb available in the right place in order to have debugging support available in the fp ide (e.g. by using one of precompiled versions available in the "contrib" section of our FTP server).

I have various other stuff going wrong when trying to build some of the samples like the fpc compiler not being able to find certain libraries. Should I post the error messages here or should I look for a bug tracker?

This depends on what the 'certain libraries' are. If you try to compile samples linking to external (3rd party) libraries, this is no fpc bug - you need to make sure to have development packages of the respective 3rd party libraries installed using tools appropriate for your distribution first.

Tomas

I've got a copy that I've built and run here, but I started off with an earlier version and had to jump through a few hoops to get it installed.

I strongly recommend using 2.6 as an interim release on SPARC, since there were code-generation bugs that weren't fixed until a few months ago- the fixes are in 2.7.1 but haven't been backported.

Having said that, 2.7.1 plus the trunk version of Lazarus work fine together for basic projects (there's things I don't routinely test, like database access).

From: "Tomas Hajny"

I didn't find a list of maintainers on the home page and I don't know how Free Pascal development is organized. Hopefully the maintainer will speak up and in the meantime I will look at the build guide you mentioned further on.

There are no binaries provided by my distribution. It's Slackware! But the question was, was it really necessary to use such a recent glibc?

Thanks.

I believe they are fpc libraries but I will have to check again. Do you expect that all of the examples will normally build on Linux without errors or is it normal to have some problems?

Thank you.

I didn't find a list of maintainers on the home page and I don't know how Free Pascal development is organized. Hopefully the maintainer will speak up and in the meantime I will look at the build guide you mentioned further on.

There is no real Solaris maintainer. Pierre sometimes works on it and I run nightly Solaris/SPARC regression tests (for as long as I still have access to a Solaris/SPARC machine), but I definitely do not support the platform. Solaris/SPARC is on life support, as far as I am concerned: I try to make sure that port doesn't get new bugs, but I don't work on fixing any existing bugs in it. I don't know to what extent Pierre wants to support Solaris/i386 and Solaris/x86-64.

There are no binaries provided by my distribution. It's Slackware! But the question was, was it really necessary to use such a recent glibc?

It's a matter of what the libc version happens to be on the system that was used to build libgdb, which is simply someone's personal machine.

I believe they are fpc libraries but I will have to check again. Do you expect that all of the examples will normally build on Linux without errors or is it normal to have some problems?

The examples are probably one of the worst maintained parts of the distribution, because almost nobody uses them. That said, some of them certainly will require the development versions of certain libraries to be installed (e.g., some of them use ncurses, so you'll need to have the development package of ncurses to be installed to compile them).

Jonas

My point was that there has been no official / dedicated maintainer for that platform within the core team recently which is the reason why there are no official builds for Solaris for version 2.6.0. Mark Morgan Lloyd who already responded to your e-mail probably has the most experience with these targets at the moment.

I'm not sure what's the supposed meaning of "It's Slackware!" in your e-mail. We do not actively track which Linux distributions support FPC directly.

Anyway, the particular glibc version was probably selected by the ld linker when compiling the binaries on the builder's machine. We cannot guarantee compatibility of the provided binaries with specific Linux distributions. Our _compiler_ does not use glibc at all on Linux - the main reason being exactly the fact that it's very difficult to ensure compatibility with different versions used by different distributions. The good point for you out of that is that you should be able to use the distributed compiler for rebuilding the IDE on your own machine and linking to the glibc version available there.

.
.

Basic examples should certainly work. In general, if you get problems when linking to particular libraries (.so), this should not be because of fpc libraries but because of something missing on your machine. If you get a compiler error complaining about units not found, it may be due to wrong (FPC) configuration performed during your installation (which may or may not be due to some bug in our installer, but that is hard to assess without more specific information). Please check what's going on there and possibly see our FAQ for common issues.

Tomas

There are no binaries provided by my distribution. It's Slackware! But the question was, was it really necessary to use such a recent glibc?

And what, pray, is wrong with Slackware? :-)

Most of the SPARC systems around here are Debian (plus one each of Solaris 8 and 10), but I've got Slackware 12 IIRC on an E4500 since the Debian installer wouldn't work. Good machine for testing multithreaded stuff on account of the number of CPUs.

I am not sure I understood your message. 2.6.0 SPARC isn't available for download, but you suggest it as an interim release because of fixes in an upcoming release that probably won't be backported. So I guess you mean even if I could get 2.6.0 built I should realize when 2.7.something comes out that's the version I should use? If so, no problem. I will go over the buildfaq suggested earlier and see what I can do, possibly with the 2.7.1 you mentioned.

I have no particular need for 2.6.0, I just normally try to get the stable release of whatever new thing I decide to try out and I understood from the website 2.6.0 is the one I should use.

Thanks.

My main role is being a thorn in the side of the core developers when something stops working :-) However I've previously offered to host a (not very fast) system here for compilation etc., and the offer stands.

His point was that Slackware has a far more limited range of binaries and libraries than do more popular distreaux such as Debian/Ubuntu, but it has its uses.

Anyway, the particular glibc version was probably selected by the ld linker when compiling the binaries on the builder's machine.

I'll check 2.7.1 on SPARC Solaris 8, 10 and Slackware 12 over the next few days. I don't anticipate any problems, and in the interest of getting the OP (who hasn't provided us with a more genteel handle) going I could mail or FTP him tarballs as appropriate.

Thanks, that is important to know. My main use would be on Solaris, possibly the SPARC version so if the project doesn't view that platform as having a future I would rather know now.

Ok, but if that is what happened I would expect a lot of people not to be able to run fp except maybe Fedora 16 or Gentoo users who always have the latest stuff. I guess I am wrong though or you would already know about it. Maybe it would be better to build on a non-bleeding edge system so people with older distros and pieces could still run everything? I very seldom upgrade but maybe everybody else does. I try to find a good working setup and then don't change it much. That's kind of why I was asking about 2.6.0 since it is the current release. I was planning on staying on that until I had a really good reason not to.

Thanks for the info here also. I have ncurses and almost every possible development tool and toolkit installed. I am careful not to randomly install non-development libraries though. If the examples are not maintained or used then I'll just do the best I can. I don't have any experience with Pascal so I was glad to see some sample code.

Yeah I checked and other platforms had people listed as maintainers. Uh oh!

Oh sorry, I thought everybody knew about Slackware since it is the oldest Linux distro still being maintained. It is mostly about building everything you want yourself but has no package management and no repo. It comes with a ton of development tools but most apps are not there. They *should* put Free Pascal on there though!

Anyway, the particular glibc version was probably selected by the ld linker when compiling the binaries on the builder's machine. We cannot guarantee compatibility of the provided binaries with specific Linux distributions.

Understood but it seems like it would be good to intentionally not use bleeding-edge setups to build in prereqs that people might not have, unless you actually need them. So my question was really about whether FPC could run with my older glibc or whether you really needed the latest.

Our _compiler_ does not use glibc at all on Linux - the main reason being exactly the fact that it's very difficult to ensure compatibility with different versions used by different distributions.

Yeah I noticed that, the compiler works great. Well done.

The good point for you out of that is that you should be able to use the distributed compiler for rebuilding the IDE on your own machine and linking to the glibc version available there.

Yes, I'll try it. I got the buildfaq and will go over it next week.

(which may or may not be due to some bug in our installer, but that is hard to assess without more specific information). Please check what's going on there and possibly see our FAQ for common issues.

I realize that. That's why I asked whether I should post here. I just didn't want to start blasting the list with a bunch of error messages for stuff you already know doesn't work or nobody cares about. I will go over the FAQ and get more info obviously. Thanks for the help guys.

Your question, as given unambiguously in the subject line, relates to 2.6.0. I'm telling you, equally unambiguously, that you don't want to do that. You might need to start off with an older binary to get yourself going, or you might be able to get hold of a binary for 2.6.0, but having done that, in the case of SPARC, you want to get onto 2.7.1 rather than relying on 2.6.0's correctness.

I have no particular need for 2.6.0, I just normally try to get the stable release of whatever new thing I decide to try out and I understood from the website 2.6.0 is the one I should use.

You are, of course, free to ignore my advice.

In any case, 2.6.0 is needed now to build 2.7.1. Just rebuild 2.7.1 from today on Solaris 10 Intel and it failed miserably with 2.4.4. That worked a few months ago and the 2.7.1 then build doesn't build todays 2.7.1 neither. Only 2.6.0 builds 2.7.1 correctly.
But I fully agree: don't do more on Solaris with 2.6.0 than building 2.7.1.

Ludo

One thing I would stress for the OP's benefit: SPARC 2.6.0 was entirely able to build itself and Lazarus. It's only when I tried mixing database access and some heavy floating-point astronomical calculations that the problems became apparent.

I don't think the OP meant he was running Slackware on Sun hardware, although maybe he (or she, I suppose) was. It seemed to me there were two mostly unrelated questions: 1) How to get FPC on Solaris? and 2) Why doesn't FPC work on his version of Slackware Linux.

Jeff.

Thanks, that's what I understood. As I said, I simply intend to get the current stable release rather than a development version. If 2.7.1 is more "stable" than 2.6.0 I will attempt to build it. I thought I explained that in the first paragraph you quoted above. And as I said in the next paragraph you quoted:

Whoa where is this coming from? I said thanks several times in my posts. I haven't ignored anything, I simply didn't understand things. The website has a note that says:

"FPC 2.6.0 has been released! 2.6.0 is a major new version, which adds many post-Delphi 7 language features and adds or improves the support for various platforms."

So naturally it sounded like that's what I should get. You have explained that is not necessarily so for SPARC, so I plan to follow your suggestions.

Thanks again.

In any case, 2.6.0 is needed now to build 2.7.1. Just rebuild 2.7.1 from today on Solaris 10 Intel and it failed miserably with 2.4.4. That worked a few months ago and the 2.7.1 then build doesn't build todays 2.7.1 neither. Only 2.6.0 builds 2.7.1 correctly.

Thanks, this is good info. I will have to build it in steps then.

But I fully agree: don't do more on Solaris with 2.6.0 than building 2.7.1.

Understood and thanks to you and Mark

One thing I would stress for the OP's benefit: SPARC 2.6.0 was entirely able to build itself and Lazarus. It's only when I tried mixing database access and some heavy floating-point astronomical calculations that the problems became apparent.

Noted. Thanks again, Mark.

My main role is being a thorn in the side of the core developers when something stops working :-) However I've previously offered to host a (not very fast) system here for compilation etc., and the offer stands.

What SPARC box(es) do you have? I may be able to host Solaris development systems if needed although the SPARC stuff would have to be scheduled since I cannot leave them on all the time because of the huge noise and heat factor. The Intel box is on most of the time.

His point was that Slackware has a far more limited range of binaries and libraries than do more popular distreaux such as Debian/Ubuntu, but it has its uses.

Right you are.

If 2.6.0 is ok for Linux that is good enough for me as far as Slackware goes. I may try to rebuild against my glibc or just forget about it on Linux and concentrate on Solaris since I prefer to work on Solaris anyway.

I appreciate your offer for packages but since you or somebody else has already pointed me to the buildfaq, I'll try this on my own and when I get stuck I'll email the list again. Thanks again for all the help.

I screwed up the quoting here, sorry. Jeff didn't write all below, I think some of it was Mark.

And what, pray, is wrong with Slackware? :-)

Nothing :-) Once you Slack you never go back!

Most of the SPARC systems around here are Debian (plus one each of Solaris 8 and 10), but I've got Slackware 12 IIRC on an E4500 since the Debian installer wouldn't work. Good machine for testing multithreaded stuff on account of the number of CPUs.

Hah! I didn't even think of that. I've been thinking it would be nice to have a SPARC port of Slackware but it hasn't been maintained.

How many sockets do you have on your E4500?

I don't think the OP meant he was running Slackware on Sun hardware, although maybe he (or she, I suppose) was. It seemed to me there were two mostly unrelated questions: 1) How to get FPC on Solaris? and 2) Why doesn't FPC work on his version of Slackware Linux.

Right. At the beginning I just wanted FPC for my Solaris boxes. Since the current stable version wasn't available for Solaris or at least so I thought until Ludo pointed me to the Intel versions, I decided to try it on Linux. Then I found fp doesn't work on my Linux setup because of not having a very recent glibc.

But yes, I'm hoping to get FPC working on Solaris SPARC now that I have the copy for Solaris Intel. Thanks to all.

Am 09.05.2012 20:19, schrieb

The text mode IDE "fp" is not used that much on Unix based systems thus such problems regarding to recent/old libraries are not detected that easily. On other systems like OS/2 (where "fp" is used more often) and Windows there aren't such dependency problems.

Most users use a graphical IDE like Lazarus:
http://www.lazarus.freepascal.org/

Regards,
Sven

I've got a range here: mostly U60 running "in anger", a U80, E4500, U10s, a U1, plus some museum pieces I can't find an OS for. I'm also one of very few people who've got an SS1000E running Linux SMP, but that's not a recent distro and because of library versions (**) I'm not sure what if any version of FPC I could get running on it.

** When a program is built, the (Linux) linker puts the actual filenames of the .so files it expects to find in the binary- not the names of any symlinks. That means that once you've built a binary using standard parameters, that binary /requires/ the same collection of .so versions that was on the development system... I managed to get around that to backport FPC from Solaris 10 to 8 but in general I think it's better to start off with a version that runs and work forwards.

I wholeheartedly agree that power, and in the Summer heat, is a massive problem. There's only so much we can afford, and even with substantial air conditioning things can get pretty unpleasant in my workroom and the adjacent machineroom. That's why I'm only able to offer U10s as always-up systems, Vincent used one of those for Lazarus two or three years ago and I've tried to test both FPC and Lazarus on Linux and Solaris fairly regularly since.

You might find it useful to go to the Mantis bug tracker and look at the SPARC-related bugs I've reported- use "View Issues", expand "Search", select "Mark Morgan Lloyd" from "Reporter" then "Use Filter". You might in particular need http://mantis.freepascal.org/view.php?id=18271 when getting your initial FPC binary installed on Solaris 10.

When you get to compiling, you might find it necessary to use a command line like this:

make NOGDB=1 OPT='-O- -gl'

What that does is tell it to not try to use the optional libgdb in the fp text-mode IDE, and it disables optimisation in the compiler binary (/not/ the compiler's ability to apply optimisation) so that if something goes wrong you can get a useful backtrace.

On Debian, you'll need [checks] build-essential, gdb, libgpmg1-dev, and some combination of libncurses5-dev and libncursesw5-dev. If you get as far as building Lazarus use trunk (on SPARC) and treat libgtk2.0-dev and possibly libqt4pas-dev as prerequisites, if those aren't available (e.g. on Slackware) I suggest we continue on the Lazarus mailing list.

12, i.e. space for an I/O card and internal discs for booting. I prefer the SS1000 architecture, where each of the eight cards is identical so you can have 16x CPUs plus full I/O... in addition being a Xerox PARC design it has a certain pedigree ;-)

I agree. I harboured illusions at one point about being able to work out how fp was put together and tracking down some of the issues (mostly related to debugging, i.e. libgdb) but in practice I've gone with the flow and started using Lazarus.

Having said which, I think I've got fp running on all the systems here (with the possible exception of Solaris 8), and I've got libgdb running with all of those (with the exception of ARM Linux).

Thu, 10 May 2012 08:45:14 +0200 Sven Barth wrote

The text mode IDE "fp" is not used that much on Unix based systems thus such problems regarding to recent/old libraries are not detected that easily.

That would explain it! But I saw fp once and I loved it, very Borland Turbo!

Most users use a graphical IDE like Lazarus: http://www.lazarus.freepascal.org/

Thanks, I'll look. But I will probably be just as happy or happier with fp.

.
.

Also, e.g. people using Debian would probably use fp from the .deb packages rather than the .tar.gz distribution. The .deb packages are created elsewhere and their dependencies are compatible with the appropriate Debian version.

Tomas

The E4500s are monsters, aren't they? I'd like to have one but I'm out of space. I'd like an Ultra 80 as well. I could find a spot for one of those.

I've got a stack of Sun Fire 210s and 440s. They're very nice but they're in various states of needing odds and ends and I don't have much disk capacity but plenty for development machines. The 210s are two bangers and are fast enough for building large apps in a reasonable timeframe. The 440s are slow but they're unstoppable, they run like a freight train, nothing bothers them. I'm hoping to get a pile of RAM but so far all the promises haven't panned out. I have a bad UPS and when I get that fixed I'll have more machines available to come online whenever needed.

Right you are. Before reading your post I built glibc-2.14 and tried fp again but no joy..

. ... I managed to get around that to backport FPC from Solaris 10 to 8 but in general I think it's better to start off with a version that runs and work forwards.

Agreed.

Sun makes awfully nice boxes and Solaris is a very nice development platform. I hope the guys will keep FPC going on Solaris. There are many Solaris 10 on Sun fans.

Thanks for the info.

Thanks.

I don't think I'll spend any further time looking at Linux, as the Slackware copy of 2.6.0 seems to work for a few small samples. If I can't get fp built on Solaris SPARC or if it doesn't work on Solaris Intel (will check that next week) then I'll think about what to do next, probably just live with Emacs. If I get bored and my list of things to do ever gets small enough I'll look at rebuilding 2.6.0 Linux under 2.6.0 with my glibc.

> How many sockets do you have on your E4500? 12, i.e. space for an I/O card and internal discs for booting.

Woohoo! That's a lot of CPUs. I'll bet you can heat your home with that in the winter.

I prefer the SS1000 architecture, where each of the eight cards is identical so you can have 16x CPUs plus full I/O... in addition being a Xerox PARC design it has a certain pedigree ;-)

I'm not familiar with that one.

On Thu, May 10, 2012 13:22, wrote:
.
.

Sun makes awfully nice boxes and Solaris is a very nice development platform. I hope the guys will keep FPC going on Solaris. There are many Solaris 10 on Sun fans.

.
.

FPC support of individual platforms depends on availability of volunteers interested and capable of supporting these platforms. FPC can target really many platforms nowadays, but this increasing number cannot be supported with constant number of developers. Someone from the Sun fans has to step in, otherwise the support cannot be guaranteed in the long term.

Tomas

Yeah, that's obvious. I'm sure anybody who was capable would help. All I can offer at this point is development systems but that doesn't seem to be the problem. How much platform dependent code is there? I would think if the main product works on i386 or AMD64 for example then there isn't much to do except build on the other targets?

Is it a matter of not having developers for the specific platform or not having anybody to build it for a specific platform?

There are operating system specific parts in both the compiler (i_sunos.pas and t_sunos.pas being the most visible ones but not necessarily the only ones) and the RTL. Moreover, talking about Solaris on Sun, there are also parts of the compiler and RTL specific for the SPARC platform. There are also packages which may occasionally need some platform specific adaptations too (not even mentioning the examples, etc.).

All of this requires some testing at least before releases and obviously also resolution of bugs specific to the particular platform (which may involve also debugging problems reported for the particular platform to the point where it is clear that the problem lies in some shared code).

Preferably, the maintainer should also run the testsuite regularly and watch for possible deviations in order to keep quality under control and avoid last minute surprises either before or even after new releases.

Tomas

You might find the fpc-devel mailing list interesting, although I think that everybody would admit that there is a shortage of documentation for the entrails of the compiler.

You might also find looking at the fpcsrc/compiler and fpcsrc/rtl trees in the source interesting, noting in particular the way that the latter at least /attempts/ to separate OS- and CPU-specific code.

You might find the fpc-devel mailing list interesting, although I think that everybody would admit that there is a shortage of documentation for the entrails of the compiler.

Thanks, I'm subscribed but haven't seen any messages yet.

You might also find looking at the fpcsrc/compiler and fpcsrc/rtl trees in the source interesting, noting in particular the way that the latter at least /attempts/ to separate OS- and CPU-specific code.

Thanks, I'll have a look later on.

Am 11.05.2012 11:29, schrieb

That's because there wasn't any since the 7th ;)

Regards,
Sven

Thanks Sven :-)

Hooray! See attached. Thanks Tomas!

Interestingly enough, the build process I stumbled through created statically linked executables. In 2.6.0 fp was dynamically linked and pointed to a copy of glibc I didn't have. In the 2.7.1 I created today, fp is static and has no dependency on a particular version of anything. I wonder if it could be created that way generically in the regular build process and then everybody on Linux could run it.

Make sure to also have libgdb available in the right place in order to have debugging support available in the fp ide (e.g. by using one of precompiled versions available in the "contrib" section of our FTP server).

Oops, I knew I forgot something! :-( Got the messages and didn't take the time to figure out where to get the library and forget about your email until I read it again now.

Paying a little more attention now after the build, the problem I am having is not finding many of the units required to build the examples. I see I do have quite a few libraries in the units directory but obviously I am missing others. I'll look at this more later on.

Thanks to everyone who's helped, I seem to be getting a lot further and fp is now working (without the debugger anyway, my fault) and looks great!

Am 21.05.2012 14:59, schrieb

This might be, because you compiled it without a libgdb which in turn is the one who links dynamically to libc. Most FPC applications (if they don't use threads or a WideString manager) don't require libc and thus don't need to link to it (which AFAIK is also the case for the IDE if it doesn't link to libgdb).

Regards,
Sven

That's a good explanation, thank you. I would like to have the debugger support.

I'm planning to go through the build again a few times for various reasons including I want to get a current copy on Solaris SPARC. I didn't get (all) the units built and there are some other minor annoyances in the way it worked out (no symlink from fpc to the ppcx module) and if it doesn't go like you said I'll post back to the list.

That will require that you can find a precompiled libgdb- preferably a version that's already supported by the options in gdbint.pp. Or build one from source (which I've done on several systems).

I've just checked my SPARC Solaris 10 and I've not gone to the trouble: fp was built without gdblib.

You normally have to set up the ppc symlink manually, irrespective or platform. I usually use two stages, e.g. ppcsparc -> ppcsparc-2.4.4 and ppcsparc-2.4.4 -> /usr/local/lib/fpc/2.4.4/ppcsparc, and in cases where I'm e.g. running Lazarus I tell it to use the "one in the middle" i.e. ppcsparc-2.4.4.

Thanks Mark. I haven't gotten to my SPARC boxes yet. Since I already had a copy of 2.6.0 built on my Linux box I was playing around with building there first.