Re: [fpc-devel] Re: Accepted fpc 2.6.2-1 (source amd64 all)
In our previous episode, peter green said: I've sorted the armhf specific issue. As expected it just required some tweaking of ifdefs so that the code in question wasn't used when building the rtl with 2.6.0. After sorting that issue it failed with much the same linker problem with fpmake as other architectures. After some discussion, something to try: try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT (for host) It will disable threading inside fpmake by not USESing cthreads, eliminating the need for cross-linking to work at all. That being said, I don't like FPC simply silently dropping those objectfiles. That should be improved, please file a bug (but I think that is more something long term for trunk, not 2.6.2) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TThread.WaitFor delay
Hi list When I call TThread.WaitFor, I almost always get a 100ms delay, presumably due to the CheckSynchronize(100) here: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/tthread.inc?view=markup#l296 Is it feasible to add an extra check so that this doesn't happen when FOnTerminate isn't assigned and DoSynchronizeMethod is false? Also, it looks like spinning on FFinished like this can get you into trouble with cpu re-ordering, or am I missing something? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] LoadLibrary result
I'm using a list of objects that each needs to load a shared Library (written in C). As some operations inside the library are slow, I've created a TThread to do multiple operations simultaneously. As the library is not thread safe, I thought using loadLibrary will create a different instance after each load, but, as the TLibHandle resulting of that function is the same, I think the library is only loaded once. Is there a way to have different handles for each loadlibrary?. 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] LoadLibrary result
On 30 May 2013, at 17:27, Leonardo M. Ramé wrote: I'm using a list of objects that each needs to load a shared Library (written in C). As some operations inside the library are slow, I've created a TThread to do multiple operations simultaneously. As the library is not thread safe, I thought using loadLibrary will create a different instance after each load, but, as the TLibHandle resulting of that function is the same, I think the library is only loaded once. Is there a way to have different handles for each loadlibrary?. No, you can load a library only once per process. Loading it more than once is not supported by any dynamic linker I know of, because it would result in symbol clashes. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary result
From: Jonas Maebe jonas.ma...@elis.ugent.be To: Leonardo M. Ramé martinr...@yahoo.com; FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, May 30, 2013 12:40 PM Subject: Re: [fpc-devel] LoadLibrary result On 30 May 2013, at 17:27, Leonardo M. Ramé wrote: I'm using a list of objects that each needs to load a shared Library (written in C). As some operations inside the library are slow, I've created a TThread to do multiple operations simultaneously. As the library is not thread safe, I thought using loadLibrary will create a different instance after each load, but, as the TLibHandle resulting of that function is the same, I think the library is only loaded once. Is there a way to have different handles for each loadlibrary?. No, you can load a library only once per process. Loading it more than once is not supported by any dynamic linker I know of, because it would result in symbol clashes. Thanks Jonas, good to know that. I'll have to re-architect the library to avoid using globals... -- 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] Re: Accepted fpc 2.6.2-1 (source amd64 all)
Marco van de Voort wrote: After some discussion, something to try: try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT (for host) Unfortunately it seems that at least when building natively (note: debian is and always has been natively built) neither OPT or CROSSOPT is passed to the build of fpmake. I asked about this in the past ( http://bugs.freepascal.org/view.php?id=21547 ) and was told it was by design. It will disable threading inside fpmake by not USESing cthreads, eliminating the need for cross-linking to work at all. Disabling threading is the last resort option but really I just want to pass the path to the compiler, I know where it should be looking. The bug report I mentioned above claims there is a FPMAKEOPT variable but I couldn't find any evidence of it in the 2.6.2 source tree. Maybe it appeared after the 2.6 series was branched (last time I ran into this issue I was dealing with trunk) The good news is I found out I can pass the setting in through the FPCFPMAKE variable. fpmake was then built successfully. I then ran into the same link problem building fpdoc. I was able to work arround that one through the OPT variable. While i've managed to get the debian 2.6.2 package to build I still feel that the best soloution long term is to add the multiarch library paths to the compiler itself. Debian/ubuntu are two of the biggest linux distros, their use of multiarch paths isn't going to go away and while we distro packagers can work arround the fact that the compiler looks there by default end users who use the upstream release directly are likely to be somewhat phased by it (especially because of the way the compiler fails in a non-obvious way). I got a fairly negative response to that last time I suggested it to you guys (don't remember if it was on irc or the mailing list) but since then I notice someone has gone ahead and added the multiarch paths for armel and armhf to the default search path in trunk. root@debian:/fpc-trunk# grep -r arm-linux-gnu * compiler/systems/t_linux.pas: LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabihf',true); compiler/systems/t_linux.pas: LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabi',true); Binary file tests/test/cg/obj/linux/arm-eabi/tcext6.o matches root@debian:/fpc-trunk# If they are going to be added for armel and armhf shouldn't they be added for other ports too? That being said, I don't like FPC simply silently dropping those objectfiles. That should be improved, please file a bug (but I think that is more something long term for trunk, not 2.6.2 http://bugs.freepascal.org/view.php?id=24518 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
