Same thing for:fxm wrote:=> Invalid compressed file !
fbc_win32_mingw_0618_2020-10-04.zip 2020-10-04 02:47 2.3M
and
fbc_win64_mingw_0627_2020-10-04.zip 2020-10-04 02:50 8.5M
+ manual not rebuilt.
Same thing for:fxm wrote:=> Invalid compressed file !
Unfortunately I'm not really sure what I can do regarding the unstable internet connection. Restarted PC, router and switches and updated to latest Jenkins version and plugins.Build timed out (after 120 minutes). Marking the build as aborted.
Aborting due to runtime error 9 ("interrupted" signal) in CHttpStream.bas::RECEIVE()
It already does that. It works exactly like the DirectX one. All it requires is a Win7-capable set of headers to build.St_W wrote: Will there be dedicated builds for Windows XP (and older) for the next official FreeBasic release? Can't we dynamically activate that driver if the system supports it instead of having custom gfxlibs for 7+ and XP?
Thanks for the clarification. Then I probably misunderstood what coderJeff wanted to point out. So the default fbc build requires Win 7+ if one wants to build that new gfxlib driver, if building on XP it has to be disabled. And the default fbc build generates binaries that work on XP as well as 7+, the new driver will just be inactive on XP (and if one wants to specifically target XP or older one could build a custom gfxlib without that driver for e.g. reduced size).adeyblue wrote:It already does that. It works exactly like the DirectX one. All it requires is a Win7-capable set of headers to build.
It's been in the master branch for at least 8 months now, so if you haven't encountered problems building it so far, you're not likely to start now.
Yes, this is exactly what I was thinking. I'm using WinXP to build the dos package and the win32-mingworg package. The win32-mingworg environment I have set-up is really old and no DX10.1 headers. I was thinking just for that build environment of disabling the new DirectX driver.St_W wrote:So the default fbc build requires Win 7+ if one wants to build that new gfxlib driver, if building on XP it has to be disabled. And the default fbc build generates binaries that work on XP as well as 7+, the new driver will just be inactive on XP (and if one wants to specifically target XP or older one could build a custom gfxlib without that driver for e.g. reduced size).
Code: Select all
FBC src/compiler/obj/linux-arm/ir-gas64.o
src/compiler/ir-gas64.bas(1462) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(1596) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(2253) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(2805) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(2835) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(2861) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5518) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5618) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5637) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5715) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5734) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5767) warning 38(0): Mixing operand data types may have undefined results
src/compiler/ir-gas64.bas(5804) warning 38(0): Mixing operand data types may have undefined results
src/compiler/obj/linux-arm/ir-gas64.c: In function ‘TEST_SSE41’:
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘esi’ in ‘asm’
__asm__ __volatile__( "\tmov eax,1\n" : : : "cc", "memory", "eax", "ebx", "ecx", "edx", "esp", "edi", "esi" );
^
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘edi’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘esp’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘edx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘ecx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘ebx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1894:2: error: unknown register name ‘eax’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘esi’ in ‘asm’
__asm__ __volatile__( "\tcpuid\n" : : : "cc", "memory", "eax", "ebx", "ecx", "edx", "esp", "edi", "esi" );
^
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘edi’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘esp’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘edx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘ecx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘ebx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1895:2: error: unknown register name ‘eax’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘esi’ in ‘asm’
__asm__ __volatile__( "\tmov [%0],ecx\n" : "=m" (LECX$1) : "m" (LECX$1) : "cc", "memory", "eax", "ebx", "ecx", "edx", "esp", "edi", "esi" );
^
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘edi’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘esp’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘edx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘ecx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘ebx’ in ‘asm’
src/compiler/obj/linux-arm/ir-gas64.c:1896:2: error: unknown register name ‘eax’ in ‘asm’
There isn't. I kind of thought it would be like the other backends where fbc can be used as a cross compiler on any host.St_W wrote:Looks like there's some x86 assembly, which (obviously) doesn't compile when targeting ARM. Is there any configuration to disable the new GAS64 backend for ARM?
Yeah, that shouldn't be on the host ever. Should be either a user run-time test or a command line switch. I'll email SARG let him know. In the meantime I can disable that bit of code.St_W wrote:Why do we test the host here, running the compiler? shouldn't this be dependent on the compiler target instead? cause as far as I can see this influences the generated code, not the compilation process itself.
OK, I've pushed changes to freebasic/fbc/master to disable the ASM used in ir-gas64.bas. I'm thinking it should build now. ir-gas64.bas still includedSt_W wrote:@coderJeff: unfortunately the ARM builds fail since the GAS64 changes were merged:
Yes it does, thanks!coderJeff wrote:OK, I've pushed changes to freebasic/fbc/master to disable the ASM used in ir-gas64.bas. I'm thinking it should build now. ir-gas64.bas still included