Send fpc-pascal mailing list submissions to
fpc-pascal@lists.freepascal.org
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
fpc-pascal-requ...@lists.freepascal.org
You can reach the person managing the list at
fpc-pascal-ow...@lists.freepascal.org
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? (microc...@zoho.com)
2. Re: 2.6.0 for Solaris? (microc...@zoho.com)
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? (microc...@zoho.com)
8. Re: Re: 2.6.0 for Solaris? (Tomas Hajny)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 May 2012 11:22:38 +0000
From: microc...@zoho.com
Subject: [fpc-pascal] Re: 2.6.0 for Solaris?
To: fpc-pascal@lists.freepascal.org
Message-ID:<20120510112300.82330a35...@lists.freepascal.org>
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: microc...@zoho.com
Subject: [fpc-pascal] Re: 2.6.0 for Solaris?
To: fpc-pascal@lists.freepascal.org
Message-ID:<20120510112532.be51fa35...@lists.freepascal.org>
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<fpas...@brouwerij.homelinux.net>
Subject: [fpc-pascal] fpc& arm-embedded interrupts
To: fpc-pascal@lists.freepascal.org
Message-ID:<4fabad03.9010...@brouwerij.homelinux.net>
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"<xhaj...@hajny.biz>
Subject: Re: [fpc-pascal] Re: 2.6.0 for Solaris?
To: "FPC-Pascal users discussions"<fpc-pascal@lists.freepascal.org>
Message-ID:
<32247.62.141.0.146.1336651667.squir...@mail.freepascal.org>
Content-Type: text/plain;charset=iso-8859-2
On Thu, May 10, 2012 13:22, microc...@zoho.com 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<jjoha...@student.aau.dk>
Subject: Re: [fpc-pascal] fpc& arm-embedded interrupts
To: FPC-Pascal users discussions<fpc-pascal@lists.freepascal.org>
Message-ID:<4fabb469.9040...@student.aau.dk>
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 - fpc-pascal@lists.freepascal.org
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<gmarti...@burdjia.com>
Subject: [fpc-pascal] Re: Runs correctly when debugging.
To: fpc-pascal@lists.freepascal.org
Message-ID:
<CAAmE6CM-AuMeeXCX=5dsfonnbmyawyy4-uaxfborhb1favo...@mail.gmail.com>
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: microc...@zoho.com
Subject: [fpc-pascal] Re: 2.6.0 for Solaris?
To: fpc-pascal@lists.freepascal.org
Message-ID:<20120510132033.e15b6a34...@lists.freepascal.org>
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"<xhaj...@hajny.biz>
Subject: Re: [fpc-pascal] Re: 2.6.0 for Solaris?
To: "FPC-Pascal users discussions"<fpc-pascal@lists.freepascal.org>
Message-ID:
<8310.62.141.0.146.1336662216.squir...@mail.freepascal.org>
Content-Type: text/plain;charset=iso-8859-2
On Thu, May 10, 2012 15:20, microc...@zoho.com 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
End of fpc-pascal Digest, Vol 95, Issue 21
******************************************
