On Tue, 2019-02-05 at 15:49 +0100, Marc Santhoff wrote:
> On Mon, 2019-02-04 at 15:59 -0700, conlin664 via fpc-pascal wrote:
> > THANKS GUYS.
> >
> > This is now working. The 'fix' was to actually install fpc 3.0.4 on this
> > machine.
> > My trusty 2.4.4 still compiled just fine what I use it for
Hi John,
thanks a lot for the verbose information.
I was thinking about putting up a wiki page collecting the diffenrent cases of
calling conventions, platforms and static vs. dynamic linking. But now I'm
totally confused.
Maybe a compiler developer or someone having enough knowlodge can clear t
Marc,
Hmmm. Okay, I just switched it to be stdcall
and had to slightly alter the name, but it compiled and ran.
So my example is now with "cpp" names, so my HelloC is now:
procedure HelloC; stdcall; external name '__Z6HelloCv';
vs
procedure HelloC; cdecl; external name '_Z6HelloCv';
both lin
On Mon, 2019-02-04 at 15:59 -0700, conlin664 via fpc-pascal wrote:
> THANKS GUYS.
>
> This is now working. The 'fix' was to actually install fpc 3.0.4 on this
> machine.
> My trusty 2.4.4 still compiled just fine what I use it for here at my day
> job.
>
> But it seems 2.4.4 was not really pulling
THANKS GUYS.
This is now working. The 'fix' was to actually install fpc 3.0.4 on this
machine.
My trusty 2.4.4 still compiled just fine what I use it for here at my day
job.
But it seems 2.4.4 was not really pulling in the static reference.
{ $L ccode.o }
So for anyone else searching on this:
c
On Thu, 2019-01-31 at 22:42 +0100, Tomas Hajny wrote:
> On Thu, January 31, 2019 21:57, Marc Santhoff wrote:
> > On Thu, 2019-01-31 at 11:00 -0700, conlin664 via fpc-pascal wrote:
> > > sven,
> > >
> > > so I just tried, what I think you said:
> > >
> > > procedure HelloC; cdecl; external name 'Hel
Am Do., 31. Jan. 2019, 22:03 hat Marc Santhoff
geschrieben:
> On Thu, 2019-01-31 at 11:00 -0700, conlin664 via fpc-pascal wrote:
> > sven,
> >
> > so I just tried, what I think you said:
> >
> > procedure HelloC; cdecl; external name 'HelloC';
> >
> > pcode.pas(19,1) Error: Undefined symbol: _Hel
On Thu, January 31, 2019 21:57, Marc Santhoff wrote:
> On Thu, 2019-01-31 at 11:00 -0700, conlin664 via fpc-pascal wrote:
>> sven,
>>
>> so I just tried, what I think you said:
>>
>> procedure HelloC; cdecl; external name 'HelloC';
>>
>> pcode.pas(19,1) Error: Undefined symbol: _HelloC
.
.
> You
On Thu, 2019-01-31 at 11:00 -0700, conlin664 via fpc-pascal wrote:
> sven,
>
> so I just tried, what I think you said:
>
> procedure HelloC; cdecl; external name 'HelloC';
>
> pcode.pas(19,1) Error: Undefined symbol: _HelloC
>
>
> sorry for complaining about windows, but i feel like this is more di
sven,
so I just tried, what I think you said:
procedure HelloC; cdecl; external name 'HelloC';
pcode.pas(19,1) Error: Undefined symbol: _HelloC
sorry for complaining about windows, but i feel like this is more difficult
on windows.
All of the FPC examples, seem to run without this extra '_' b
Am Do., 31. Jan. 2019, 15:26 hat Bart geschrieben:
> On Thu, Jan 31, 2019 at 7:35 AM Sven Barth via fpc-pascal
> wrote:
>
> > > This is on an evil windows machine
> > Windows is one of FPC's main targets, we can do without such
> "expletives".
>
> Maybe he has WinME ???
>
Well, I was rather hap
On Thu, Jan 31, 2019 at 7:35 AM Sven Barth via fpc-pascal
wrote:
> > This is on an evil windows machine
> Windows is one of FPC's main targets, we can do without such "expletives".
Maybe he has WinME ???
--
Bart
___
fpc-pascal maillist - fpc-pascal
Am 30.01.2019 um 23:14 schrieb conlin664 via fpc-pascal:
ok. I backed up to a simple version.
how I declare the C routine must be the problem,
with nothing,
procedure HelloC; cdecl; external;
I think it's trying to static link it, and gets an
pcode.pas(19,1) Error: Undefined symbol: _He
ok. I backed up to a simple version.
how I declare the C routine must be the problem,
with nothing,
procedure HelloC; cdecl; external;
I think it's trying to static link it, and gets an
pcode.pas(19,1) Error: Undefined symbol: _HelloC
with anything else
procedure HelloC; cdecl; ex
On Mon, 2019-01-28 at 08:19 -0700, conlin664 via fpc-pascal wrote:
> Thanks for the suggestions..
>
> I'm pretty sure now, that the problem is that I'm thinking that the C code
> is being statically linked,
> but right now the compiler is going for dynamic.
> [ I've been comparing the size of the
On 28/01/19 16:19, conlin664 via fpc-pascal wrote:
when I don't try and call the C routine the number of unresolved objects is
only 213
compiler switches:
-TWin32 -va -Mfpc -vw -Sg -Ci -O1 -Cp386 -OpPENTIUM3 -Ratt -gl -p- -b-
I had -XS in there, but it doesn't seem to change anything.
So I'm
Thanks for the suggestions..
I'm pretty sure now, that the problem is that I'm thinking that the C code
is being statically linked,
but right now the compiler is going for dynamic.
[ I've been comparing the size of the .exe ]
I also compiled with -va and note:
[0.388] Number of unresolved extern
Am Fr., 25. Jan. 2019, 01:01 hat Marc Santhoff
geschrieben:
> On Wed, 2019-01-23 at 14:30 -0700, conlin664 via fpc-pascal wrote:
> > I've done research, but am just missing something.
> > my .pas code links just fine, but doesn't RUN.
> > ( first writeln never appears )
> > If I remove the exter
On Wed, 2019-01-23 at 14:30 -0700, conlin664 via fpc-pascal wrote:
> I've done research, but am just missing something.
> my .pas code links just fine, but doesn't RUN.
> ( first writeln never appears )
> If I remove the external call to C code, then the writeln works as normal.
>
> Problem:
>
> I
I've done research, but am just missing something.
my .pas code links just fine, but doesn't RUN.
( first writeln never appears )
If I remove the external call to C code, then the writeln works as normal.
Problem:
I have c code, which I'm compiling on a WIN32 machine ( yes the horror )
using GC
20 matches
Mail list logo
