Msmw.amaal
On Aug 19, 2015 4:02 PM, "Chris Moody" wrote:
> Hi all,
>
> So I reset up my Pi and I was able to get the current version of FPC to
> get as far as the linking stage, at which point it shows this:
>
> /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
> /home/p
On 08/21/2015 01:08 AM, Jonas Maebe wrote:
Chris Moody wrote:
Seems it compiles but still complains about linking.
Free Pascal Compiler version 3.0.0rc1 [2015/08/20] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Assembling dentist
Linking Dentist
D
On Friday 21 August 2015 15:25:56 Martin Schreiber wrote:
> On Friday 21 August 2015 15:04:23 Jonas Maebe wrote:
> > Does it have the same version of binutils as you use to cross-compile?
>
> No.
> Linux X86 cross: 2.25.51
> Linux arm eabihf Raspberry Pi: 2.24.51
>
Looks the same with
Linux X86 c
Am 21.08.2015 um 10:08 schrieb Jonas Maebe:
> Chris Moody wrote:
>> Seems it compiles but still complains about linking.
>>
>> Free Pascal Compiler version 3.0.0rc1 [2015/08/20] for arm
>> Copyright (c) 1993-2015 by Florian Klaempfl and others
>> Target OS: Linux for ARMHF
>>
>> Assembling dentist
On Friday 21 August 2015 15:04:23 Jonas Maebe wrote:
>
> Does it have the same version of binutils as you use to cross-compile?
>
No.
Linux X86 cross: 2.25.51
Linux arm eabihf Raspberry Pi: 2.24.51
Martin
___
fpc-pascal maillist - fpc-pascal@lists.free
On 2015-08-21 10:41, leledumbo wrote:
> Under *nix platforms, FPC layout is slightly different. At least bin and
> units by default doesn't have the same direct parent
Indeed. If you use FPC's official installer (not Linux distro package
managers) it is less of a problem. You could symlink the "un
On 21/08/15 14:51, Martin Schreiber wrote:
> On Friday 21 August 2015 14:23:40 Jonas Maebe wrote:
>
>> Does it work if you compile natively
>> on the system?
>>
> Yes.
Does it have the same version of binutils as you use to cross-compile?
Jonas
___
fp
On Friday 21 August 2015 14:23:40 Jonas Maebe wrote:
>
> Are their multiple copies of those .o files on the target system,
No.
> and did you perhaps copy a wrong one?
I don't think so.
> Does it work if you compile natively
> on the system?
>
Yes.
Martin
_
Hello,
many thanks for all the insight! I will be able to complete it now. A
separate DLL should be easy enough, too.
Cheers,
Tobias
> Am 21.08.2015 08:40 schrieb "Tobias Giesen" :
> >
> > Hello,
> >
> > I have to compile a few Pascal units with FPC and add them to a Visual
> > C++ project. Afte
On 21/08/15 14:21, Martin Schreiber wrote:
> On Friday 21 August 2015 14:13:06 Jonas Maebe wrote:
>> On 21/08/15 14:03, Martin Schreiber wrote:
>>> I got linking working without xlib in uses by copying the necessary
>>> *.o's, but now the application crashes when remote gdb tries to set a
>>> break
On Friday 21 August 2015 14:13:06 Jonas Maebe wrote:
> On 21/08/15 14:03, Martin Schreiber wrote:
> > On Friday 21 August 2015 12:56:36 Jonas Maebe wrote:
> >> That's because the compiler warned that it could not find those files,
> >> so it didn't tell the linker to link against them either. You n
On 21/08/15 14:03, Martin Schreiber wrote:
> On Friday 21 August 2015 12:56:36 Jonas Maebe wrote:
>> That's because the compiler warned that it could not find those files,
>> so it didn't tell the linker to link against them either. You need the
>> armhf sysroot for that and tell the compiler where
On Friday 21 August 2015 12:56:36 Jonas Maebe wrote:
> On 21/08/15 12:47, Martin Schreiber wrote:
> > The missing "_fini" and "_init" symbols from rtl/linux/arm/cprt0.as which
> > cause the linking error are defined in one of the crt*.o files?
>
> Yes.
>
> > The linker
> > does not try to load crt*
On 21/08/15 12:47, Martin Schreiber wrote:
> The missing "_fini" and "_init" symbols from rtl/linux/arm/cprt0.as which
> cause the linking error are defined in one of the crt*.o files?
Yes.
> The linker
> does not try to load crt*.o files:
That's because the compiler warned that it could not f
On Friday 21 August 2015 11:55:49 Jonas Maebe wrote:
[...]
> As mentioned in the "Issue with linking" thread, you will have to
> separately tell FPC where to find crtbegin.o and crtend.o, as their
> location depends on the GCC version used. Since the sysroot path (-XR
> parameter) should be prepend
On 08/21/2015 11:55 AM, Jonas Maebe wrote:
To be able to cross-compile a program that depends on a library for
any Unix platform, you need to have a sysroot available with all of
those libraries and their own requirements (such as crti.o and crtn.o
for glibc, and crtbegin.o and crtend.o for g
Martin Schreiber wrote on Fri, 21 Aug 2015:
Cross compiling Linux-x86->eabihf of the program:
"
program rpiconsole;
uses
initc;
begin
end.
"
produces the messages:
"
Free Pascal Compiler version 3.0.1 [2015/08/14] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux
Am 21.08.2015 11:04 schrieb "Tomas Hajny" :
>
> On Fri, August 21, 2015 10:22, Tobias Giesen wrote:
> >> The particular symbol should be defined in libimpsystem.a
> >
> > Fantastic! After adding some more libraries, the only remaining missing
> > symbol is FPC_WIDEINITTABLES. I can probably just cr
Am 21.08.2015 08:40 schrieb "Tobias Giesen" :
>
> Hello,
>
> I have to compile a few Pascal units with FPC and add them to a Visual
> C++ project. After adding system.o to the Visual C++ project, I get
> linker errors like this:
>
> system.o : error LNK2001: unresolved external symbol _$dll$kernel3
> Feedback is highly appreciated.
>From the install page:
Click "+" icon and select "Free Pascal SDK" or "Delphi SDK".
Then select SDK home directory. It's a directory where compiler directories
such as "bin" and "units" are located.
Under *nix platforms, FPC layout is slightly different. At leas
Hi,
Cross compiling Linux-x86->eabihf of the program:
"
program rpiconsole;
uses
initc;
begin
end.
"
produces the messages:
"
Free Pascal Compiler version 3.0.1 [2015/08/14] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling rpiconsole.pas
Assemblin
On Fri, August 21, 2015 10:22, Tobias Giesen wrote:
>> The particular symbol should be defined in libimpsystem.a
>
> Fantastic! After adding some more libraries, the only remaining missing
> symbol is FPC_WIDEINITTABLES. I can probably just create a dummy for
> that in a Pascal unit, as the code do
> The particular symbol should be defined in libimpsystem.a
Fantastic! After adding some more libraries, the only remaining missing
symbol is FPC_WIDEINITTABLES. I can probably just create a dummy for
that in a Pascal unit, as the code does not need widestrings.
Cheers,
Tobias
Chris Moody wrote:
Seems it compiles but still complains about linking.
Free Pascal Compiler version 3.0.0rc1 [2015/08/20] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Assembling dentist
Linking Dentist
Dentist.pas(106) Warning: "crtbegin.o" not foun
On Fri, August 21, 2015 09:36, Tobias Giesen wrote:
Hello,
> yes, to interface between Pascal and C I use 'extern "C"'. I do not have
> any problems linking between my C code and the Pascal code.
>
> The only problem is that the Pascal RTL uses DLL imports, which the
> Microsoft linker cannot re
Hello,
yes, to interface between Pascal and C I use 'extern "C"'. I do not have
any problems linking between my C code and the Pascal code.
The only problem is that the Pascal RTL uses DLL imports, which the
Microsoft linker cannot resolve, for example:
unresolved external symbol _$dll$kernel3
On 08/20/2015 05:39 PM, Sven Barth wrote:
Might be worthwhile to test the ARM variant again, because if that
allows normal C/C++ applications as well, then we could at least add a
arm-win32 target for that (I've seen that mingw-w64 provides
arm-binutils so that problem could be solved as well
On 08/20/2015 12:27 PM, tobiasgie...@gmail.com wrote:
Hello,
I have to compile a few Pascal units with FPC and add them to a Visual
C++ project.
As the object structure (and supposedly the naming scheme for
overloaded functions) is different in fpc and C++ you can't link them
(neither statica
28 matches
Mail list logo
