Re: [fpc-pascal] Compiling arm-embedded fpc
On 14-02-13 21:34, Michael Ring wrote:
I did a grep through the fpc sourcecode and found a reference in
./compiler/systems/t_linux.pas in an arm related ifdef section
add(' .note.gnu.build-id : { *(.note.gnu.build-id) }');
so perhaps this is really missing in arm-embedded target.
The patch for for fpc/compiler/systems/t_embed.pas seems to be pretty
straightforward, I will create the patch and test if debugging still
works.
Michael
by the way:
I used binutils-2.23.1 to create the cross-tools, configure script
was:
./configure --target=arm-none-eabi --program-prefix=arm-embedded-
compiled under Fedora-18.
...
Sounds to me like a broken binutils. I have never heard about the
.note section, except for some warnings now and then on obscure
platforms
Hi guys,
Thanks for taking the time to investigate this.
As far as I know binutils is the collection of programs to create
executables, so the gcc-compiler, assembler, linker, etc. Another name
is "toolchain", right ?
I recently searched for a toolchain, and I found one :
gcc-arm-none-eabi-4_7-2012q4-20121208-linux.tar.bz2. I got this in the
release.txt :
GNU Tools for ARM Embedded Processors 4.7
- Dec 2012
I think I tried it also with an older toolchain from Codewarriors (now
Mentor). I'll have to verify this, though.
There's nothing to compile, just unpack and use it.
I don't know what you are using as toolchain, did you have the same
problem ?
Like I said before, I made a virtual machine that's set up to have a
development environment for embedded-arm and fpc, including openocd. I
made some scripts to do the compilation (to get a crosscompiler and the
embedded-arm projects). The only thing I should do is make some document
explaining how to use those scripts, although they're rather
straighforward.
That could be used to investigate this case. The downside is it's size,
about 900MB. It's on susestudio.com and on dropbox
(https://www.dropbox.com/sh/dbsxi81jx2cb73n/h6ro62_XsD).
I'm going to use this when this problem is solved, but anyone can use
it. I'm going to try to maintain this, so all comments are welcome.
Users/passwords : fpc/fpc and root/linux.
Thanks again,
Koenraad Lelong.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Make TStringList.ExchangeItems virtual?
On 2/13/13, Sven Barth wrote: > We could maybe adjust the string list in so far that at the beginning of > QuickSort we determine whether ExchangeItem was overridden, if it was we > call the now virtual, protected ExchangeItem and if it was not overriden > we call a private non virtual version (which could be called by the > default implementation of ExchangeItem as well). Should I open a ticket in bugtracker for this? Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Make TStringList.ExchangeItems virtual?
On Fri, 15 Feb 2013, Bart wrote: On 2/13/13, Sven Barth wrote: We could maybe adjust the string list in so far that at the beginning of QuickSort we determine whether ExchangeItem was overridden, if it was we call the now virtual, protected ExchangeItem and if it was not overriden we call a private non virtual version (which could be called by the default implementation of ExchangeItem as well). Should I open a ticket in bugtracker for this? Yes, please. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Configuration file handling
If multiple, related, programs running on unix (Linux, Solaris etc.) refer to the same configuration file accessed via a TIniFile, is there any recommended "good practice" to ensure that they don't try to update it simultaneously? In the case that I'm thinking of, I don't anticipate e.g. multiple logins trying to write setup information at the same time. The more risky case is if there are e.g. multiple daemons or apps trying to save state when a UPS signals imminent shutdown. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Configuration file handling
I would not use INI if the systems are writing data. While I've had plenty of success reading INI files in parallel - I seem to recall that the file is just streamed out without regard to which version is on disk. I think the file is completely refreshed. I recommend using a DBMS system of some sort for read/write ops in parallel. On 02/15/2013 04:54 PM, Mark Morgan Lloyd wrote: If multiple, related, programs running on unix (Linux, Solaris etc.) refer to the same configuration file accessed via a TIniFile, is there any recommended "good practice" to ensure that they don't try to update it simultaneously? In the case that I'm thinking of, I don't anticipate e.g. multiple logins trying to write setup information at the same time. The more risky case is if there are e.g. multiple daemons or apps trying to save state when a UPS signals imminent shutdown. -- Andrew Brunner Aurawin LLC 15843 Garrison Circle Austin, TX 78717 https://aurawin.com Aurawin is a great new way to store, share, and explore all your content featuring our innovative cloud social computing platform. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Abstract methods called from descendants via Inherited.
This is a minor issue, just a question of design... I understand that by design abstract methods cannot be called and that doing so is an error. However FPC used to allow an abstract method to be called from an overriding descendant method without any error (and without doing anything useful, of course). More recently it doesn't allow this. It seems to me the earlier behaviour is more desirable because it means one can write the overriding method in decedent classes in such a way that this method can call inherited without knowing if it's abstract or not. The new behaviour means that the overriding method in all (first) decedent classes must be modified (to call the inherited method) if the parent class with the abstract method is changed (or a new class inserted in between) which makes the abstract method a concrete one. If the compiler silently ignored calls to abstract methods, when made from an overriding method, this problem would be avoided and one could change inherited behaviour in the parent class without affecting the descendant classes (which usually call the inherited method at some point). A simple work-around is to make the abstract method a "do nothing" real one in the first place, but then one looses the benefits of the abstract error raised when another (unrelated) object calls the (unimplemented) method. Am I misunderstanding something here? Why is it done the way it is done now? Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
