Send fpc-pascal mailing list submissions to To subscribe or unsubscribe via the World Wide Web, visit http://lists.freepascal.org/mailman/listinfo/fpc-pascal or, via email, send a message with subject or body 'help' to You can reach the person managing the list at When replying, please edit your Subject line so it is more specific than "Re: Contents of fpc-pascal digest..." Today's Topics: 1. Re: 2.6.0 for Solaris? () 2. Re: 2.6.0 for Solaris? () 3. fpc& arm-embedded interrupts (Koenraad Lelong) 4. Re: Re: 2.6.0 for Solaris? (Tomas Hajny) 5. Re: fpc& arm-embedded interrupts (Jeppe Gr?sdal Johansen) 6. Re: Runs correctly when debugging. (Guillermo Mart?nez Jim?nez) 7. Re: 2.6.0 for Solaris? () 8. Re: Re: 2.6.0 for Solaris? (Tomas Hajny) ---------------------------------------------------------------------- Message: 1 Date: Thu, 10 May 2012 11:22:38 +0000 From: Subject: [fpc-pascal] Re: 2.6.0 for Solaris? To: Message-ID: Content-Type: text/plain; charset=US-ASCII On Thu, 10 May 2012 07:27:22 +0000 Mark Morgan Lloyd wrote: > microcode wrote: >> 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. > 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. 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. > ** 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 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. > 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. 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. >> 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. > 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. Thanks for the info. > 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. Thanks. > 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. 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. ------------------------------ Message: 2 Date: Thu, 10 May 2012 11:25:12 +0000 From: Subject: [fpc-pascal] Re: 2.6.0 for Solaris? To: Message-ID: Content-Type: text/plain; charset=US-ASCII On Thu, 10 May 2012 07:32:47 +0000 Mark Morgan Lloyd wrote: >> 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. ------------------------------ Message: 3 Date: Thu, 10 May 2012 13:56:51 +0200 From: Koenraad Lelong Subject: [fpc-pascal] fpc& arm-embedded interrupts To: Message-ID: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I'm working on an embedded-arm application. I do want to use interrupts but I don't find how to easily setup the interrupt-handlers. In the startup code in C, I see default handlers defined with the keyword WEAK. Looking around, I found that this means that if one defines a function with the same name, that will be used instead of the default-handler. The start-address of that new function will be entered in the interrupt-vector table in flash. Is something similar possible with fpc ? Looking in the fpc-startup-code, the rtl, I don't see that, but that could be me. Or do I have to modify the rtl for every project I will be making ? What I did see I think, in some rtl-units for arm-embedded, is that there seems to be a contruction to put the start-address of the main error-handlers in RAM. Would that be the only way to have interrupts ? Thanks for any help, Regards, Koenraad Lelong. ------------------------------ Message: 4 Date: Thu, 10 May 2012 14:07:47 +0200 (CEST) From: "Tomas Hajny" Subject: Re: [fpc-pascal] Re: 2.6.0 for Solaris? To: "FPC-Pascal users discussions" Message-ID: Content-Type: text/plain;charset=iso-8859-2 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 ------------------------------ Message: 5 Date: Thu, 10 May 2012 14:28:25 +0200 From: Jeppe Gr?sdal Johansen Subject: Re: [fpc-pascal] fpc& arm-embedded interrupts To: FPC-Pascal users discussions Message-ID: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed The easiest way to do interrupt processing in Cortex-M3 processors(which I assume you are using), is to create an interrupt vector table in SRAM and then change the NVIC to use that. That way you can point to the interrupt handlers at runtime. It's true that the normal way of doing it is with weak linking as you write, but there's no support for that directly in FPC currently, so it'll have to be done with external assembly. It is doable, but noone has made it entirely yet. Den 10-05-2012 13:56, Koenraad Lelong skrev: > Hi, > > I'm working on an embedded-arm application. I do want to use > interrupts but I don't find how to easily setup the interrupt-handlers. > In the startup code in C, I see default handlers defined with the > keyword WEAK. Looking around, I found that this means that if one > defines a function with the same name, that will be used instead of > the default-handler. The start-address of that new function will be > entered in the interrupt-vector table in flash. > Is something similar possible with fpc ? Looking in the > fpc-startup-code, the rtl, I don't see that, but that could be me. > Or do I have to modify the rtl for every project I will be making ? > What I did see I think, in some rtl-units for arm-embedded, is that > there seems to be a contruction to put the start-address of the main > error-handlers in RAM. Would that be the only way to have interrupts ? > > Thanks for any help, > > Regards, > > Koenraad Lelong. > _______________________________________________ > fpc-pascal maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ------------------------------ Message: 6 Date: Thu, 10 May 2012 14:44:41 +0200 From: Guillermo Mart?nez Jim?nez Subject: [fpc-pascal] Re: Runs correctly when debugging. To: Message-ID: Content-Type: text/plain; charset=ISO-8859-1 > No, you have to use pchar. I would also define ALLEGRO_BITMAP as an > empty record, to be clear that it's an opaque type: > > {$packrecords c} > TAllegroBitmap = record > end; > PAllegroBitmap = ^TAllegroBitmap; > > Thus: > > function al_load_bitmap(const filename: pchar): PAllegroBitmap; cdecl; > external ALLEGRO_LIB_NAME; > > Make sure you use {$packrecords c}. Use the types in unit "ctypes", > e.g. cint, cfloat, cdouble. This will ensure the variables are the same > size and work on all architectures. > > Henry Ok, then I should revise all the "STRING" parameters, as well as all pointer types and "ctypes". Thanks for the advices. Guillermo. ------------------------------ Message: 7 Date: Thu, 10 May 2012 13:20:09 +0000 From: Subject: [fpc-pascal] Re: 2.6.0 for Solaris? To: Message-ID: Content-Type: text/plain; charset=US-ASCII On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote: > On Thu, May 10, 2012 13:22, microcode 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. 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? ------------------------------ Message: 8 Date: Thu, 10 May 2012 17:03:36 +0200 (CEST) From: "Tomas Hajny" Subject: Re: [fpc-pascal] Re: 2.6.0 for Solaris? To: "FPC-Pascal users discussions" Message-ID: Content-Type: text/plain;charset=iso-8859-2 On Thu, May 10, 2012 15:20, wrote: > On Thu, 10 May 2012 14:07:47 +0200 (CEST) "Tomas Hajny" wrote: >> On Thu, May 10, 2012 13:22, microcode 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. > 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 ------------------------------ _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal End of fpc-pascal Digest, Vol 95, Issue 21 ******************************************