On 27 Aug 2009, at 20:56, Graeme Geldenhuys wrote:
2009/8/27 Jonas Maebe :
That was in the very first post of this thread:
Maybe on another mailing list? Not here anyway.
Nope, Mattias is right.
You're right. I clearly wasn't reading straight yesterday, I had read
"in my first post of
2009/8/27 Jonas Maebe :
>>
>> That was in the very first post of this thread:
>
> Maybe on another mailing list? Not here anyway.
Nope, Mattias is right. He posted the results in the Lazarus mailing
list, but when I moved the discussion from there to here, I quoted his
results in my first posting.
On 27 Aug 2009, at 19:08, Mattias Gaertner wrote:
On Thu, 27 Aug 2009 18:57:58 +0200
Jonas Maebe wrote:
Oh, now I see that the procedure was put below :) That it's quicker
with cmem is reasonably logical: FPC's heap manager is not very good
at reallocating memory.
What reallocating memory
On Thu, 27 Aug 2009 18:57:58 +0200
Jonas Maebe wrote:
>
> On 27 Aug 2009, at 18:55, Jonas Maebe wrote:
>
> > Without saying what this command line application and this LCL
> > application do exactly, it's kind of hard to understand this
> > conclusion.
>
>
> Oh, now I see that the procedu
On Thu, 27 Aug 2009 18:55:10 +0200
Jonas Maebe wrote:
>
> On 27 Aug 2009, at 18:48, Mattias Gaertner wrote:
>
> > On Thu, 27 Aug 2009 13:46:21 +0200
> > Mattias Gärtner wrote:
> >
> >> [...]
> >> I would say, that using cthreads under Linux in an LCL app is ok.
> >> I didn't test yet a LCL app
On 27 Aug 2009, at 18:55, Jonas Maebe wrote:
Without saying what this command line application and this LCL
application do exactly, it's kind of hard to understand this
conclusion.
Oh, now I see that the procedure was put below :) That it's quicker
with cmem is reasonably logical: FPC's
On 27 Aug 2009, at 18:48, Mattias Gaertner wrote:
On Thu, 27 Aug 2009 13:46:21 +0200
Mattias Gärtner wrote:
[...]
I would say, that using cthreads under Linux in an LCL app is ok.
I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't
know if cthreads has a performance penalty ther
On Thu, 27 Aug 2009 13:46:21 +0200
Mattias Gärtner wrote:
>[...]
> I would say, that using cthreads under Linux in an LCL app is ok.
> I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't
> know if cthreads has a performance penalty there.
I did some tests on OS X and got some intere
En/na Marco van de Voort ha escrit:
It makes it very hard to longterm succesfully deploy a simple linux binary
over several systems.
FWIW, yesterday I add to compile on a current system a 5 years old very
simpe program (updated 2 years ago) with current lazarus/gtk2/fpc 2.2.4
to deploy on a
A much longer than expected discussion, but informative none the less.
Thanks to all for explaining.
And here one can see the difference. Static vs Dynamic executable.
$ ldd bench1.cthreads
linux-vdso.so.1 => (0x7fff3f5ff000)
libdl.so.2 => /lib/libdl.so.2 (0x7f4b371b5000)
2009/8/27 Mattias Gärtner :
>
> Not me, but Michael said that.
Of course, sorry for mis-quoting you.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Zitat von Henry Vermaak :
2009/8/27 Graeme Geldenhuys :
Michael Van Canneyt wrote:
Why is threading enabled by default under Windows and not under other
platforms?
Because it creates a dependency on the C library, which
is not always wanted. For Lazarus programs, the dependency exists
anyway
Jonas Maebe schrieb:
>
> On 27 Aug 2009, at 12:49, Graeme Geldenhuys wrote:
>
>> Is this an issue, even if your program doesn't use any
>> procedures/functions from the dynamically linked C library. For example,
>> a console application that includes the cthreads unit (which dynamically
>> links
On 27 Aug 2009, at 13:15, Marco van de Voort wrote:
The init code touches errno
No, it doesn't.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 27 Aug 2009, at 13:04, Marco van de Voort wrote:
OS X and FreeBSD have basically the same problem, however has some
mitigating factors (they change mostly only with major versions, and
have
the ability to run older binaries using resp COMPAT and SDK system)
The SDK's on Mac OS X are onl
In our previous episode, Henry Vermaak said:
> 2009/8/27 Michael Van Canneyt :
> >
> > Because I want a FPC program to depend only on the Linux kernel, not on the
> > C library.
> >
> > There are FPC programs from 8 years back that still work with the current
> > kernel. Try that with a program tha
In our previous episode, Graeme Geldenhuys said:
> > There are FPC programs from 8 years back that still work with the current
> > kernel. Try that with a program that depends on the C library.
>
> Sorry if this sounds dumb - it's late in the week. ;-)
> Is this an issue, even if your program doe
Henry Vermaak schrieb:
> 2009/8/27 Michael Van Canneyt :
>> Because I want a FPC program to depend only on the Linux kernel, not on the
>> C library.
>>
>> There are FPC programs from 8 years back that still work with the current
>> kernel. Try that with a program that depends on the C library.
>
On 27 Aug 2009, at 12:49, Graeme Geldenhuys wrote:
Is this an issue, even if your program doesn't use any
procedures/functions from the dynamically linked C library. For
example,
a console application that includes the cthreads unit (which
dynamically
links to C Library), but doesn't actual
2009/8/27 Graeme Geldenhuys :
>
> I understand all this, but isn't libc available on all unix-type OSes.
In my limited experience, I haven't come across a linux system without
some form of a c library. Pretty much everything in gnu userland
relies on it.
> If so, then I don't understand why it (
In our previous episode, Graeme Geldenhuys said:
> >> Why is threading enabled by default under Windows and not under other
> >> platforms?
> >
> > Because it creates a dependency on the C library, which
> > is not always wanted. For Lazarus programs, the dependency exists
> > anyway, so it does
Graeme Geldenhuys schrieb:
> Michael Van Canneyt wrote:
>> Because I want a FPC program to depend only on the Linux kernel,
>> not on the C library.
>
> OK.
>
>
>> There are FPC programs from 8 years back that still work with the current
>> kernel. Try that with a program that depends on the C
In our previous episode, Graeme Geldenhuys said:
> uses
> {$IFDEF UNIX}{$IFDEF UseCThreads}
> cthreads,
> {$ENDIF}{$ENDIF}
> Classes;
> ---
>
> Question 1:
> Is there an alternative implementation of multi-threading support for
> Unix-type systems -- other than the cthreads u
2009/8/27 Michael Van Canneyt :
>
> Because I want a FPC program to depend only on the Linux kernel, not on the
> C library.
>
> There are FPC programs from 8 years back that still work with the current
> kernel. Try that with a program that depends on the C library.
The only reason for this is th
Michael Van Canneyt wrote:
>
> Because I want a FPC program to depend only on the Linux kernel,
> not on the C library.
OK.
> There are FPC programs from 8 years back that still work with the current
> kernel. Try that with a program that depends on the C library.
Sorry if this sounds dumb -
Henry Vermaak wrote:
>
> The linux threading support is part of glibc. See `man pthreads`.
> That's why Mattias says that including it by default in lazarus is
> o.k., since all the widgetsets depend on libc, anyway.
>
> Threading on Windows works with Windows API functions.
I understand all th
On Thu, 27 Aug 2009, Graeme Geldenhuys wrote:
Michael Van Canneyt wrote:
Why is threading enabled by default under Windows and not under other
platforms?
Because it creates a dependency on the C library, which
is not always wanted. For Lazarus programs, the dependency exists
anyway, so it d
2009/8/27 Graeme Geldenhuys :
> Michael Van Canneyt wrote:
>>> Why is threading enabled by default under Windows and not under other
>>> platforms?
>>
>> Because it creates a dependency on the C library, which
>> is not always wanted. For Lazarus programs, the dependency exists
>> anyway, so it doe
Michael Van Canneyt wrote:
>> Why is threading enabled by default under Windows and not under other
>> platforms?
>
> Because it creates a dependency on the C library, which
> is not always wanted. For Lazarus programs, the dependency exists
> anyway, so it does not make a lot of sense to have th
On Thu, 27 Aug 2009, Graeme Geldenhuys wrote:
Hi,
I first asked this question in the Lazarus mailing list, but was told it
may be more appropriate here. When you create a new project in Lazarus,
the default uses clause in the *.lpr file looks as follows:
---
uses
{$IFDEF UNIX}{$
Hi,
I first asked this question in the Lazarus mailing list, but was told it
may be more appropriate here. When you create a new project in Lazarus,
the default uses clause in the *.lpr file looks as follows:
---
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
31 matches
Mail list logo
