I'm getting 404 error some times (randomly). However, in a minute I can
access the forum again.
It might be an issue on the hosting server.
thanks,
Dmitry
On Mon, Mar 10, 2014 at 3:21 PM, Ralf Quint wrote:
> On 3/10/2014 7:23 AM, m...@rpzdesign.com wrote:
>
>> Ludo:
>>
>> I wish the forum.laza
On Mon, 10 Mar 2014 20:18:38 -0400
"m...@rpzdesign.com" wrote:
> Jonas:
>
> Where in Lazarus 1.0.14 do I put in the compiler command line option?
> -WM10.9
>
> Project Options->Compiler Options->Compilation->Compiler->Command
No, that's the path to the compiler, no extra options.
> -WM10.9
Jonas:
Where in Lazarus 1.0.14 do I put in the compiler command line option?
-WM10.9
Project Options->Compiler Options->Compilation->Compiler->Command->
$(CompPath) -WM10.9
And when I use this setting -WM10.9, this means that I can only execute
the resulting binary on Mavericks and above
On 10 Mar 2014, at 19:07, m...@rpzdesign.com wrote:
Unfortunately, your suggestion while appreciated does not work.
For example, the actual function "__divdi3" actually lives in
/usr/lib/system/libcompiler_rt.dylib
This library does not exist on Snow Leopard. But it does exist on
Mavericks
On 3/10/2014 7:23 AM, m...@rpzdesign.com wrote:
Ludo:
I wish the forum.lazarus.freepascal.org website were functional. It is
usually not responding most of the time.
Must be an issue on your side, I can access it, at any time I have tried
in the last few weeks, just perfectly fine...
Ralf
Peter:
I must use some form of {$LINKLIB gcc}
{$LINKLIB c} still WORKS under OSX 10.9
{$LINKLIB gcc} does not work user OSX 10.9 Mavericks.
"__divdi3" unresolved reference lives in the gcc run time library chain.
md
On 3/10/2014 11:21 AM, Peter Brooks wrote:
Why are you wanting to us
Jonas,
Unfortunately, your suggestion while appreciated does not work.
For example, the actual function "__divdi3" actually lives in
/usr/lib/system/libcompiler_rt.dylib
This library does not exist on Snow Leopard. But it does exist on
Mavericks. (I do not have Lion/Mtn Lion available)
{$
Why are you wanting to use gcc instead? If I wanted to do this, I'd
just replace c with a link to gcc.
On 10 March 2014 16:14, m...@rpzdesign.com wrote:
> Peter:
>
> I was surprised too. That is why I broadcast the alarm to the FPC
> community.
>
> I am running FPC 2.6.2 - Lazarus 1.0.14
>
> Ye
Ludo:
I wish the forum.lazarus.freepascal.org website were functional. It is
usually not responding most of the time.
Can you or anybody just copy the step by step instructions into an email
and send it to me directly?
I would love to look at the step by step instructions, but that forum
Peter:
I was surprised too. That is why I broadcast the alarm to the FPC
community.
I am running FPC 2.6.2 - Lazarus 1.0.14
Yes, I can recompile FPC from scratch on Mavericks.
I can compile perfectly well on Mavericks too.
No, I cannot issue the {$LINKLIB gcc } command on Mavericks OSX 10.9
> On Friday, 7 March 2014, 11:04, Jonas Maebe wrote:
> >
> On 05 Mar 2014, at 19:41, Jon wrote:
>
>> I have a board running Linux - it reports itself as armv4tl:
>>
>> root@phidgetsbc:~# uname -a
>> Linux phidgetsbc 3.1.6 #3 PREEMPT Fri Jan 6 13:05:50 MST 2012
>> armv4tl GNU/Linux
>>
>>
Michael Van Canneyt wrote:
On Mon, 10 Mar 2014, Mark Morgan Lloyd wrote:
When a DLL/so is loaded dynamically by multiple program instances, are
globals shared or would this require explicit use of OS-level shared
memory?
You'll need explicit use of OS-level shared memory.
Thanks, noted :-)
On Mon, 10 Mar 2014, Mark Morgan Lloyd wrote:
When a DLL/so is loaded dynamically by multiple program instances, are
globals shared or would this require explicit use of OS-level shared memory?
You'll need explicit use of OS-level shared memory.
Michael.
___
When a DLL/so is loaded dynamically by multiple program instances, are
globals shared or would this require explicit use of OS-level shared memory?
The application is emulating a region of scratchpad memory (File Protect
Memory) used by hardware in an obsolete computer (Burroughs B5700). This
On 10 Mar 2014, at 05:15, m...@rpzdesign.com wrote:
> After diving deeply into the dependency tree,
>
> there are 2 libraries that are involved in this particular problem:
>
> /usr/lib/libSystem.B.dylib
> /usr/lib/libgcc_s.1.dylib
>
> But I cannot figure out yet how to call up the libgcc_s.1.d
On 03/09/2014 08:36 PM, m...@rpzdesign.com wrote:
> Marco:
>
> Based on the tone of your response, I am thinking that I
> am doing something stupid on windows win32?
>
You are on the correct path but you need to point to the mingw
libraries. They provide the stubs for msvcrt and other windows st
16 matches
Mail list logo
