Thanks much for the FYI, Jonas.
Alan
On Tue, Mar 31, 2009 at 1:02 PM, Jonas Maebe wrote:
> It's a shared library issue. It has been fixed for a number of platforms in
> 2.2.4: http://bugs.freepascal.org/view.php?id=4171 (I don't know about
> Linux though, but I think so).
>
__
On 31 Mar 2009, at 20:12, Alan Krause wrote:
I am using fpc 2.2.0, and building the shared library as follows:
fpc -Sd -Cgiro -g -gh -gl -dDEBUG library.pas -Fu../path1 -Fu../path2
-Fu../path3
Am I missing anything, or is this a shared library issue?
It's a shared library issue. It has been
I've been using the heaptrc unit in DEBUG versions of my application to
detect memory leaks. However, when a memory leak is detected, it does not
include any information on the unit, line number, etc - just the hex
addresses, like this:
Heap dump by heaptrc unit
15648 memory blocks allocated : 692
On 31 Mar 2009, at 15:53, Vincent Snijders wrote:
Seth Grover schreef:
Does that seem like the right way for me to get the functionality of
those calls available to me in InstallSignals? Or is there something
easier I'm missing?
I don't think it can be done without editing the system unit. I
Seth Grover schreef:
Does that seem like the right way for me to get the functionality of
those calls available to me in InstallSignals? Or is there something
easier I'm missing?
I don't think it can be done without editing the system unit. If you are willing to
do that, I would add a procva
In our previous episode, Seth Grover said:
> Does that seem like the right way for me to get the functionality of
> those calls available to me in InstallSignals? Or is there something
> easier I'm missing?
It is roughly ok. Optionally you can also -dFPC_USE_LIBC to force the system
unit to use li
I'm working on a project in Linux where I've got some special signal
handling requirements. I need to modify system.pp's InstallSignals to
dynamically load an .so, look up a function by name, and make some
calls into that library instead of doing what it normally does.
The dynlibs unit has the cod
2009/3/31 Tom Carly :
> Hi,
>
> I found that the problem is coming from the fact that I use
> process.Options := ProcessB.Options + [poUsePipes];
>
> If I switch that off, process B does execute the signal handling code. Is
> this a bug or am I missing something?
it would be great if you could ma
Hi,
I found that the problem is coming from the fact that I use
process.Options := ProcessB.Options + [poUsePipes];
If I switch that off, process B does execute the signal handling code. Is this
a bug or am I missing something?
Thx,
Tom
-Original Message-
From: fpc-pascal-boun...@lis
