[fpc-devel] improving error message when forgot to use cthreads unit
Hi, When someone forgets to use the cthreads unit and creates a thread the exception message is: Semaphore init failed (possibly too many concurrent threads) Can this message be improved for unix? Can it check if the thread manager is valid and then emit something like Semaphore init failed (possibly too many concurrent threads or you forgot to use the cthreads unit in your program) Of course 'cthreads' is just one possible thread manager, but afaik it is commonly used, so it would give the programmer a hint into the right direction. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] improving error message when forgot to use cthreads unit
On Sat, 28 Apr 2012, Mattias Gaertner wrote: Hi, When someone forgets to use the cthreads unit and creates a thread the exception message is: Semaphore init failed (possibly too many concurrent threads) Can this message be improved for unix? Can it check if the thread manager is valid and then emit something like Define 'valid thread manager' ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] improving error message when forgot to use cthreads unit
On Sat, 28 Apr 2012 10:52:08 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: On Sat, 28 Apr 2012, Mattias Gaertner wrote: Hi, When someone forgets to use the cthreads unit and creates a thread the exception message is: Semaphore init failed (possibly too many concurrent threads) Can this message be improved for unix? Can it check if the thread manager is valid and then emit something like Define 'valid thread manager' ? I feared someone would ask that. Maybe check if it is the default one? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenBsd cross compiler
From: Pierre Free Pascal pie...@freepascal.org To: 'Leonardo M. Ramé' martinr...@yahoo.com; 'FPC developers' list' fpc-devel@lists.freepascal.org Sent: Friday, April 27, 2012 11:20 AM Subject: RE: [fpc-devel] OpenBsd cross compiler Hi Leonardo, -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Leonardo M. Ramé Envoyé : jeudi 26 avril 2012 21:10 À : FPC developers' list Objet : [fpc-devel] OpenBsd cross compiler Hi, I usually create Win32 targets using this: make crossinstall OS_TARGET=win32 CPU_TARGET=i386 PP=/home/leonardo/Desarrollo/fpc/i386-linux-ppc386 Now I want to create an OpenBSD cross compiler, so I just replaced win32 by openbsd: Yes, but you do need cross-binutils for openbsd! The problem is that current GNU Binutils source do not generate correct objects/executables for openbsd. Which means that you need to get an openbsd specific binutils source install it, and configure it for the target you are interested in: I checked the internet, and it seems to be difficult to fond. Thus I added it to ftp://ftp.freepascal.org/pub/fpc/contrib/cross/openbsd/ 1) Downloaded ftp://ftp.freepascal.org/pub/fpc/contrib/cross/openbsd/binutils-openbsd-2.15 .tar.gz file. 2) Untar it tar -xvzf binutils-openbsd-2.15.tar.gz 3) Create build directory: mkdir build-cross-i386-openbsd cd build-cross-i386-openbsd 4) Run configure for that target ../binutils-4.9/configure --target=i386-pc-openbsd --program-prefix=i386-openbsd- (That's what I used on mingw32, but to compile on mingw you also need to apply the patch that I added in the same directory on ftp server). 5) Compile and install everything: make all-gas all-binutils all-ld make install-gas install-binutils install-ld prefix=PATH/TO/WHERE/YOU/WANT/IT This should install i386-openbsd-as i386-openbsd-ld and a few more into PATH/TO/WHERE/YOU/WANT/IT/bin directory Note that I didn't use the same procedure on mingw (because I wanted to get binaries that did not depend on any mingw specific DLLs) make crossinstall OS_TARGET=openbsd CPU_TARGET=i386 PP=/home/leonardo/Desarrollo/fpc/i386-linux-ppc386 But the linker is not found. This is the error I get: make[5]: se ingresa al directorio «/home/leonardo/Desarrollo/fpc/rtl/openbsd» /bin/mkdir -p /home/leonardo/Desarrollo/fpc/rtl/units/i386-openbsd i386-openbsd-as -o /home/leonardo/Desarrollo/fpc/rtl/units/i386- openbsd/prt0.o i386/prt0.as make[5]: i386-openbsd-as: No se encontró el programa make[5]: *** [prt0.o] Error 127 make[5]: se sale del directorio «/home/leonardo/Desarrollo/fpc/rtl/openbsd» make[4]: *** [openbsd_all] Error 2 make[4]: se sale del directorio «/home/leonardo/Desarrollo/fpc/rtl» make[3]: *** [rtl] Error 2 make[3]: se sale del directorio «/home/leonardo/Desarrollo/fpc/compiler» make[2]: *** [cycle] Error 2 make[2]: se sale del directorio «/home/leonardo/Desarrollo/fpc/compiler» make[1]: *** [compiler_cycle] Error 2 make[1]: se sale del directorio «/home/leonardo/Desarrollo/fpc» make: *** [build-stamp.i386-openbsd] Error 2 Is there an i386-openbsd-as linker?. Where can I find it. i386-openbsd-as is the assembler, not the linker i386-openbsd-ld is the linker. BTW. I'm on Linux x86_64 (Ubuntu 11.10). You could repeat the steps for x86_64-openbsd target by simply using --target=x86_646pc-openbsd Hoping the above will help, Pierre Thanks Pierre, I'll try the binutils package you uploaded. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreePascal Git Repo and 2_6 branch
On 27 April 2012 18:27, David Jenkins da...@scootersoftware.com wrote: I am wondering if Graeme can update his FreePascal git mirror to include the 2_6 branches. To do it the correct way, is a lot of work, hence the reason I stopped mirroring the fixes branches. What I mean by correct way, is cherry-picking the commits from Trunk (master) and applying them in the fixes branch - thus it is one standard git repository (with alternate branches), is more efficient for git to work with, and uses less disk space. But the problem is, it can't be automated (I need to manually track what commits are merged by FPC developers, manually fix conflicts etc) and my free time is very limited. What I can do in an automated fashion, is to simply mirror the 2.6 fixes branch as a separate git repository (with limited history - going back to when 2.6 fixes branch was started). If this would be sufficient, I can set it up on Wednesday when I am back in the office. That's no trouble. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreePascal Git Repo and 2_6 branch
In our previous episode, Graeme Geldenhuys said: To do it the correct way, is a lot of work, hence the reason I stopped mirroring the fixes branches. What I mean by correct way, is cherry-picking the commits from Trunk (master) and applying them in the fixes branch - thus it is one standard git repository (with alternate branches), is more efficient for git to work with, and uses less disk space. But the problem is, it can't be automated (I need to manually track what commits are merged by FPC developers, manually fix conflicts etc) and my free time is very limited. I can try to create some form of automated feed of fixes tree commits + items that are merged. So assume fixes branch rev X merges revision T1,T2,T3 from trunk. You then roughly would do for X in all fixes revs to process since last processing do begin svn diff fixes branch X-1,X temp.patch cherry pick from git trunk to git fixes revs (e.g. T1 T2 T3) git revert all changes to files but not mergeinfo (resolves all conflicts) patch -p0 temp.patch( applies the manually merged fixes) git push/commit whatever end; An innerloop for T1,T2,T3 separately is unfortunately not possible (since manual fixes up might apply to all revs at once) I'm not saying that I will have such info next week, but if you could test if you could get such scenario done with GIT, I can see if I drag such info out of the mergelog package in time. (which I'm still expanding) I doubt it is the same as truly working through GIT (I'm not sure if tracking of line changesets works even if you could all Tx individually), it might be already better since it is automated and has GIT level info per fixes rev what revs were merged from trunk. It assumes GIT can deal with mergeinfo a bit creatively and flexible though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
