Re: [fpc-pascal] Can't configure fppkg
Ok, I changed GlobalPrefix to fpc source path (it is
/usr/lib/codetyphon/fpcsrc/) but still same result. So my files looks like:
fpconf.cfg
[Defaults]
ConfigVersion=4
GlobalPrefix=/usr/lib/codetyphon/fpcsrc/
LocalPrefix={LocalRepository}
Compiler=/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
OS=linux
CPU=x86_64
Version=2.7.1
fppkg.cfg
[Defaults]
ConfigVersion=4
LocalRepository={UserDir}.fppkg/
BuildDir={LocalRepository}build/
ArchivesDir={LocalRepository}archives/
CompilerConfigDir={LocalRepository}config/
RemoteMirrors=http://www.freepascal.org/repository/mirrors.xml
RemoteRepository=auto
CompilerConfig=fpconf.cfg
FPMakeCompilerConfig=fpconf.cfg
Downloader=lnet
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can't configure fppkg
On 14.02.2013 09:07, Krzysztof wrote: Ok, I changed GlobalPrefix to fpc source path (it is /usr/lib/codetyphon/fpcsrc/) but still same result. So my files looks like: Not the SOURCE path. The path which contains the COMPILED units. So this should be '/usr/lib/codytyphon/fpc' (the correct target directory will be - hopefully - picked by fppkg). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13/02/2013 16:50, Giuliano Colla wrote: IMHO the try..except..finally construct should provide exactly the same functionality as a nested try try [code] except [code] end; finally [code] end; i.e. it should be executed whatever happened in the sections between try and finally (except if somewhere there was an Application.terminate!). Any exception not handled shoud be re-raised after the finally block has been executed. The advantage would be to get rid of one level of nesting, making the code more readable and less error prone. This would guarantee both proper error handling and freeing of global resources, even in presence of errors. Giuliano It is subtle, I agree, but in try try [code] finally [code] end; except [code] end; (my version) I can catch the errors of either normal and finally code; I assume that try...finally...end is the more important; it is try...finally.. end that has to go without errors, or else one will be reported; if no exception happens, except is omitted; the except section in this case, can catch anything and its job is to decide whether to allow further execution, show/log a message or bail out. (also AFAICS this way it is recommended to be used in most snippets) In your case (try..finally...end being the outer), what if it may not be possible to free the global resources (e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end to properly show user a message? Or if something else that has to be done in finally section, throws?) Kind Regards, Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Lukasz Sokol ha scritto: It is subtle, I agree, but in try try [code] finally [code] end; except [code] end; (my version) I can catch the errors of either normal and finally code; I assume that try...finally...end is the more important; it is try...finally.. end that has to go without errors, or else one will be reported; if no exception happens, except is omitted; the except section in this case, can catch anything and its job is to decide whether to allow further execution, show/log a message or bail out. (also AFAICS this way it is recommended to be used in most snippets) In your case (try..finally...end being the outer), what if it may not be possible to free the global resources (e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end to properly show user a message? Or if something else that has to be done in finally section, throws?) The purpose of the try..except construct is to allow the developer to put some remedy in case of errors, instead of just aborting the program. The purpose of the try..finally construct is to guarantee some actions even if the program is going to be aborted. The new constructs would provide both options at the same time. But I'm afraid that there's not a better solution good for all situation. It depends on what one tries to do in the try.. clause, on which errors one choses to deal with on the except clause, and the likelihood of recoverable errors in the finally clause. Allowing both constructs, (try..except..finally and try..finally..except) as Sven suggested, would most likely cover a broader range of cases. Then, sometimes someone will still need nested try..whatever, to deal with situations which do really require the HOLES you mentioned. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Sven Barth ha scritto: I don't see the point of a else or nonexcept branch. If I want code to be executed in the case that no exception happened (e.g. a Commit for a database transaction) then I put in the block started by the try... One might argue that an additional branch would increase readability, but I personally don't see a real use for it... You're right. At first glance it appeared to me a good idea, but actually it wouldn't provide anything useful. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling arm-embedded fpc
I might have found a hack to solve your linking problem for arm-embedded on linux, unfortunately I am not an expert on gnu ld, but perhaps this here gives a hint to somebody that knows how to properly solve your problem: First, create a script names arm-embedded-ld with the following content: #!/bin/sh sed --in-place s^*(.comment)^*(.comment)\n*(.note, .note.*)^g link.res /usr/local/bin/arm-embedded-ld $* do a chmod 755 on the script so that you are able to execute it and now make sure that the script is found in your path before the original arm-embedded-ld binary so that fpc calls the small script instead of the real linker. The problem seems to be that there is no definition for the note section in the link.res file. the small script adds this section, then the real linker gets called and all are happy (I hope) You definitely need to test if after this hack you are still able to to debug your binary, I did not go that far. I hope that helped, Michael Am 30.01.13 19:02, schrieb Michael Ring: I did some digging and found the following post: http://www.redhat.com/archives/rhl-devel-list/2007-October/msg01192.html and http://www.redhat.com/archives/rhl-devel-list/2007-October/msg01196.html It's quite old so I am not sure if this still is of relevance but at = this time Freepascal did not support the section . The workarround seems = to be to add --build-id to linker command so that the section is = automagically created. I will try later tonight if I have the same issue as you. Michael Am 30.01.13 18:47, schrieb Koenraad Lelong: Hi, An update. I tried to make a crosscompiler with the new sources on my = old developing machine. There I still get the segmentation fault. = The difference is that that machine is 64 bit, while the appliance is = 32 bit. Actually, that was why I made the appliance. To see if there were = differences. Regards, Koenraad ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- next part -- An HTML attachment was scrubbed... URL: http://lists.freepascal.org/lists/fpc-pascal/attachments/20130130/d031= e163/attachment-0001.htm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling arm-embedded fpc
Am 14.02.2013 20:08, schrieb Michael Ring: I might have found a hack to solve your linking problem for arm-embedded on linux, unfortunately I am not an expert on gnu ld, but perhaps this here gives a hint to somebody that knows how to properly solve your problem: First, create a script names arm-embedded-ld with the following content: #!/bin/sh sed --in-place s^*(.comment)^*(.comment)\n*(.note, .note.*)^g link.res /usr/local/bin/arm-embedded-ld $* If this is already needed (for me it worked always without), please provide a patch for fpc/compiler/systems/t_embed.pas The linker script generation for arm starts at line 222. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling arm-embedded fpc
Den 14-02-2013 20:39, Florian Klämpfl skrev: Am 14.02.2013 20:08, schrieb Michael Ring: I might have found a hack to solve your linking problem for arm-embedded on linux, unfortunately I am not an expert on gnu ld, but perhaps this here gives a hint to somebody that knows how to properly solve your problem: First, create a script names arm-embedded-ld with the following content: #!/bin/sh sed --in-place s^*(.comment)^*(.comment)\n*(.note, .note.*)^g link.res /usr/local/bin/arm-embedded-ld $* If this is already needed (for me it worked always without), please provide a patch for fpc/compiler/systems/t_embed.pas The linker script generation for arm starts at line 222. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling arm-embedded fpc
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.
Am 14.02.13 20:41, schrieb Jeppe Græsdal Johansen:
Den 14-02-2013 20:39, Florian Klämpfl skrev:
Am 14.02.2013 20:08, schrieb Michael Ring:
I might have found a hack to solve your linking problem for
arm-embedded
on linux, unfortunately I am not an expert on gnu ld, but perhaps this
here gives a hint to somebody that knows how to properly solve your
problem:
First, create a script names arm-embedded-ld with the following
content:
#!/bin/sh
sed --in-place s^*(.comment)^*(.comment)\n*(.note, .note.*)^g
link.res
/usr/local/bin/arm-embedded-ld $*
If this is already needed (for me it worked always without), please
provide a patch for fpc/compiler/systems/t_embed.pas The linker script
generation for arm starts at line 222.
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
