16.12.2018 22:44, Florian Klämpfl:
Well, problem is a little bit that arm is really a moving target.
Yes, I know.
Besides, the exact difference between the "arm-linux" target and
"armv7-linux-gnueabi" target is afaics just nowhere explicitely
documented.(Though, binutils is opensource, one
Am 16.12.2018 um 20:47 schrieb Nikolai Zhubr:
> Hi,
>
> Yes, "armv7-linux-gnueabi" did the trick for cross-compiling on windows as
> well. I just had to manually rename binary
> files of binutils so that thay match the naming pattern fpc build system
> expacts. I can provide my ready-to-use
>
Am 16.12.2018 um 18:20 schrieb Nikolai Zhubr:
> 16.12.2018 20:01, I wrote:
>> Hi,
>>
>> 16.12.2018 17:10, I wrote:
>>> I'm wondering what version of binutils was used to release fpc 3.0.4 for
>>> arm?
>>
>> I've suddenly noticed that there is apparently no binary 3.0.4 release
>> for arm! Well, at
Hi,
Yes, "armv7-linux-gnueabi" did the trick for cross-compiling on windows
as well. I just had to manually rename binary files of binutils so that
thay match the naming pattern fpc build system expacts. I can provide my
ready-to-use win32-to-arm binutils 2.31.1 zip if someone is interested.
Hi,
It seems I've finally cracked this puzzle, somewhat.
My self-built binutils were initially configured for "arm-linux" (That
is, configure --target="arm-linux"). As soon as I changed this to
"armv7-linux-gnueabi" (basically as a random guesswork) and rebuilt it
all including the cross-fpc
On 12/16/2018 1:01 PM, Nikolai Zhubr wrote:
And, I still see tons of "ARM BLX instruction ..." warnings from ld of this
kind:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function
On 12/16/18 7:01 AM, Marco van de Voort wrote:
Op 2018-12-15 om 22:27 schreef wkitt...@windstream.net:
i'm guessing that VFP is Virtual Floating Point which i would understand as
being emulated kinda like we used to do when a machine didn't have a math
co-processor in it... >>
No, VFP is
16.12.2018 20:01, I wrote:
Hi,
16.12.2018 17:10, I wrote:
I'm wondering what version of binutils was used to release fpc 3.0.4 for
arm?
I've suddenly noticed that there is apparently no binary 3.0.4 release
for arm! Well, at least not officially presented on fpc website. The
Not exactly
Hi,
16.12.2018 17:10, I wrote:
I'm wondering what version of binutils was used to release fpc 3.0.4 for
arm?
I've suddenly noticed that there is apparently no binary 3.0.4 release
for arm! Well, at least not officially presented on fpc website. The
download link goes to 3.0.2 version
16.12.2018 18:13, Jonas Maebe:
Which instructions does it show if you run the program in gdb and do
"x/2i $pc-4" when it crashes?
I made some additional steps in gdb in order to check if the program in
question actually starts executing anything at all. Looks like it does:
GNU gdb (GDB;
On 16/12/18 15:59, Nikolai Zhubr wrote:
16.12.2018 17:03, Florian Klämpfl:
[...]
https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32/
? They work for me with the command line you mentioned. However, we
have to support newer ones, I'll look into this.
With binutils from svn, the
16.12.2018 17:03, Florian Klämpfl:
[...]
https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32/
? They work for me with the command line you mentioned. However, we have to
support newer ones, I'll look into this.
With binutils from svn, the cross-build itself succeeded for me out of
Am 16.12.2018 um 15:18 schrieb Nikolai Zhubr:
> Hi Florian,
>
> 16.12.2018 16:41, Florian Klämpfl:
>> I followed the thread, but didn't find it: what binutils do you use?
>
> I've tried 3 version so far:
>
> * binutils-2.15.94 (prebuilt) from fpc website is unusable because assembler
> refuses
Hi Florian,
16.12.2018 16:41, Florian Klämpfl:
I followed the thread, but didn't find it: what binutils do you use?
I've tried 3 version so far:
* binutils-2.15.94 (prebuilt) from fpc website is unusable because
assembler refuses some instructions (I've mentioned it earlier)
*
Hi all,
(Sorry for flooding so much, but I've done some more testing!)
In order to isolate any possible wierd windows-specific issues, I've
redone everything on x86_64-linux as a host, with the same 3.0.4 version
starting compiler, same fpcbuild-3.0.4.zip as a source for cross-build,
same
Am 16.12.2018 um 12:01 schrieb Nikolai Zhubr:
> Hi,
>
> 16.12.2018 13:51, I wrote:
> [...]
>> So inserting
>> ASTARGET+=-mfpu=softvfp
>> allowed full cross-build to succeed. I have yet to see if the generated
>> binaries are actually usable.
>
> Ok, now the resulting elf executable has this
Op 2018-12-15 om 22:27 schreef wkitt...@windstream.net:
i'm guessing that VFP is Virtual Floating Point which i would
understand as being emulated kinda like we used to do when a machine
didn't have a math co-processor in it...
No, VFP is hard float support. The "V" stands for Vector not
Hi,
16.12.2018 13:51, I wrote:
[...]
So inserting
ASTARGET+=-mfpu=softvfp
allowed full cross-build to succeed. I have yet to see if the generated
binaries are actually usable.
Ok, now the resulting elf executable has this (supposedly correct) flag:
private flags = 600: [APCS-32] [VFP float
Hi all,
16.12.2018 3:44, I wrote:
[...]
Got it, somewhat:
-mfpu=softvfp is passed to arm-linux-as while compiling intermediate .s
files (when using -Cfsoft), not sure if it is correct and intentional,
and no special flags passed to arm-linux-as while compiling assembler
sources.
Hence the
Hi,
16.12.2018 2:13, I wrote:
Is there any easy way to see how exactly ppcrossarm.exe invokes
assembler (command-line arguments passed) during a cross-compiler build
and also to inspect intermediate .s files?
Got it, somewhat:
-mfpu=softvfp is passed to arm-linux-as while compiling
Am Sa., 15. Dez. 2018, 23:55 hat Nikolai Zhubr
geschrieben:
> Hi,
>
> Is there any easy way to see how exactly ppcrossarm.exe invokes
> assembler (command-line arguments passed) during a cross-compiler build
> and also to inspect intermediate .s files?
>
You can try -sh which should generate a
Hi,
Is there any easy way to see how exactly ppcrossarm.exe invokes
assembler (command-line arguments passed) during a cross-compiler build
and also to inspect intermediate .s files?
Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I
On 12/15/18 11:57 AM, Nikolai Zhubr wrote:
15.12.2018 19:09, wkitt...@windstream.net:
On 12/15/18 10:36 AM, Nikolai Zhubr wrote:
So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?
is this a typo? should it be -CfVPF4_S16 with F and V swapped?
No. From ppcrossarm.exe -i:
Hi again,
15.12.2018 19:52, Nikolai Zhubr:
15.12.2018 18:24, Florian Klämpfl:
Now, I'm targeting an A20-olinuxino-micro board, which is afaik
armv7a with VPFv4. The board is running either openwrt
or opensuse. (And actually, the binaries produced by the pre-built
native compiler have been
15.12.2018 19:09, wkitt...@windstream.net:
On 12/15/18 10:36 AM, Nikolai Zhubr wrote:
So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?
is this a typo? should it be -CfVPF4_S16 with F and V swapped?
No. From ppcrossarm.exe -i:
Supported FPU instruction sets:
15.12.2018 18:24, Florian Klämpfl:
Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with
VPFv4. The board is running either openwrt
or opensuse. (And actually, the binaries produced by the pre-built native
compiler have been tested in both environments
already)
So I
On 12/15/18 10:36 AM, Nikolai Zhubr wrote:
So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?
is this a typo? should it be -CfVPF4_S16 with F and V swapped?
--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list
Am 15.12.2018 um 16:36 schrieb Nikolai Zhubr:
>> There is no single ARM/Linux platform, but many different incompatible
>> ones (which is one of the reasons there are no provided FPC
>> cross-compilers for this "platform".
>
> Right, this is what I overlooked indeed (Well, because a pre-built
15.12.2018 17:38, Jonas Maebe:
T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]
I suspect this is an inintended flag set by my arm-linux-as.exe for
some reason...
On 12/15/18 9:29 AM, Nikolai Zhubr wrote:
I suspect this is an inintended flag set by my arm-linux-as.exe for some
reason... Probably have to get rid of it somehow...
so the real questions are:
1. is this flag being set erroneously?
2. are the .o files being built properly?
3. should
On 15/12/18 15:29, Nikolai Zhubr wrote:
15.12.2018 16:58, I wrote:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target
15.12.2018 16:58, I wrote:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target
specific data of file
Hm, indeed, objdump
Hi all,
Ok, apparently the binutils-2.15.94-win32-arm-linux.zip (provided on the
fpc website) is somewhat outdated to be really usable for arm target.
Retrying with (self-built) binutils-2.28 apparently solves the previous
problem but now I have another: ld yells something about VFP
33 matches
Mail list logo
