Hi Peter,
I was about committing new changes to fix build issue and saw that you
already have fix that.
If you don't mind I'd like to change your patch slightly as follow (cf
attached patch)
Please note that fpmake is a build tool which is compiled and ran on
host while building the compiler (unl
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
>
> From: Jonas Maebe
>To: Leonardo M. Ramé ; FPC developers' list
>
>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
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
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 "instanc
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 is
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 fpmak