FB-1.07.1-gcc-6.4
FB-1.07.1-gcc-6.4
from my tests, FB-gcc-6.4 is the latest gcc-toolchain that correctly builds DLL's, so here are the builds if you are interested
FreeBASIC-1.07.1-gcc640-win32.7z
FreeBASIC-1.07.1-gcc640-win64.7z
FreeBASIC-1.07.1-gcc640-win32.7z
FreeBASIC-1.07.1-gcc640-win64.7z
Re: FB-1.07.1-gcc-6.4
Hi srvaldez,
I don't quite understand. Just quickly made a test .DLL and a lil' proggie using it, with
your GCC 9.2 - x64 - WIN - build (FBC 1.07.1 -- 2019-10-08) and all works as expected?!?
I don't quite understand. Just quickly made a test .DLL and a lil' proggie using it, with
your GCC 9.2 - x64 - WIN - build (FBC 1.07.1 -- 2019-10-08) and all works as expected?!?
Re: FB-1.07.1-gcc-6.4
Hi MrSwiss
sometimes the simplest of examples fail to build a working 64-bit dll, have you tried paul doe's example? viewtopic.php?f=3&t=27966
sometimes the simplest of examples fail to build a working 64-bit dll, have you tried paul doe's example? viewtopic.php?f=3&t=27966
Re: FB-1.07.1-gcc-6.4
Hi srvaldez,
after finishing the DLL-code (was IMO incomplete) it compiles, without a hitch.
DLL-code:
after finishing the DLL-code (was IMO incomplete) it compiles, without a hitch.
DLL-code:
Code: Select all
Declare Function createComponent alias "createComponent"(byref aComponentName as const string) As any Ptr
Extern "windows"
function _
createComponent alias "createComponent"( _
byref aComponentName as const string ) _
as any ptr export
? "Component " & aComponentName & " created."
return( 0 )
end function
End Extern
Re: FB-1.07.1-gcc-6.4
thank you MrSwiss
so basically all that was needed was Extern "windows"/End Extern?
so basically all that was needed was Extern "windows"/End Extern?
Re: FB-1.07.1-gcc-6.4
Not quite: without the "declaration", there may also be problems (not 100% certain).
The Extern "..."/ End Extern is of course mandatory (for DLL's & SO's).
The Extern "..."/ End Extern is of course mandatory (for DLL's & SO's).
Re: FB-1.07.1-gcc-6.4
what's your compile command? (options)
Re: FB-1.07.1-gcc-6.4
The simplest I could come up with: fbc -dylib -export "blah-dll.bas"
(implicit: console/-gen gcc)
(implicit: console/-gen gcc)
Re: FB-1.07.1-gcc-6.4
yes, that works, however, optimization options seem to cause problems
try paul doe's compile options fbc -s console -dll -export -gen gcc -Wc -Ofast "blah-dll.bas"
granted that -s console is not needed to build a dll
try paul doe's compile options fbc -s console -dll -export -gen gcc -Wc -Ofast "blah-dll.bas"
granted that -s console is not needed to build a dll
Re: FB-1.07.1-gcc-6.4
Yes, that's the problem just added: "-O 2" and, I'm getting garbage ... as described.srvaldez wrote:yes, that works, however, optimization options seem to cause problems
Re: FB-1.07.1-gcc-6.4
srvaldez wrote:yes, that works, however, optimization options seem to cause problems
try paul doe's compile options fbc -s console -dll -export -gen gcc -Wc -Ofast "blah-dll.bas"
granted that -s console is not needed to build a dll
So, it is optimization what's causing the problem? Mmm. Will look into it. Thanks.MrSwiss wrote:Yes, that's the problem just added: "-O 2" and, I'm getting garbage ... as described.srvaldez wrote:yes, that works, however, optimization options seem to cause problems
Re: FB-1.07.1-gcc-6.4
gcc-5.2 and gcc-6.4 don't have issues compiling with optimization, as far as I know.
Re: FB-1.07.1-gcc-6.4
Indeed, it is optimizations that are causing the problems in the gcc 8 toolchain. As you point out, there are no problems with those older versions. Nevermind then. I'll just use the old trusty 5.2 until I can look at the issue in more detail.srvaldez wrote:gcc-5.2 and gcc-6.4 don't have issues compiling with optimization, as far as I know.
-
- Posts: 4292
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: FB-1.07.1-gcc-6.4
It seems to me that with each new gcc version the optimization gets more aggressive and does not do FB any favours. Since 6.4 is only 'one up' on 5.2 it is no surprise that "gcc-5.2 and gcc-6.4 don't have issues compiling with optimization, as far as I know."
Things start to get flaky with 7 which, for some reason, is flakier than 8 or 9. After much testing with 8 and 9 I couldn't find any reason to go with 9 so I ended up using 8.3 as my default.
However, with 8.3 I sometimes get warnings like 'array subscript is below array bounds ...' with -O2 and -O3 which is simply not true. I get other warnings which do not make sense either. That is with 32-bit. With 64-bit I often get issues 'invalid use of register frame'. With 5.2 there are no such warnings.
The later gcc compilers produce smaller binaries with each new version but performance benefits, if any, do not take my breath away.
I am easily persuaded that 8.3, for example, should be better than 5.2 but putting my 100% objective hat on the argument for the later compilers is not that strong. I have been advocating putting 5.2 to one side but, I suspect, I may have been wearing my subjective hat.
I reckon that the real benefits in the future will be FB 1.08, 1.09 and so on and not the 'latest and greatest' gcc which just get flakier and flakier for FB. Reviews on the internet give the thumbs up for each new gcc version, but they are being tested with C Code and not FB code.
Bit of a turn around for me but if the road ahead is getting progressively more difficult to drive along then, at some point, we should stop, take a deep breath, and ... turn around.
Things start to get flaky with 7 which, for some reason, is flakier than 8 or 9. After much testing with 8 and 9 I couldn't find any reason to go with 9 so I ended up using 8.3 as my default.
However, with 8.3 I sometimes get warnings like 'array subscript is below array bounds ...' with -O2 and -O3 which is simply not true. I get other warnings which do not make sense either. That is with 32-bit. With 64-bit I often get issues 'invalid use of register frame'. With 5.2 there are no such warnings.
The later gcc compilers produce smaller binaries with each new version but performance benefits, if any, do not take my breath away.
I am easily persuaded that 8.3, for example, should be better than 5.2 but putting my 100% objective hat on the argument for the later compilers is not that strong. I have been advocating putting 5.2 to one side but, I suspect, I may have been wearing my subjective hat.
I reckon that the real benefits in the future will be FB 1.08, 1.09 and so on and not the 'latest and greatest' gcc which just get flakier and flakier for FB. Reviews on the internet give the thumbs up for each new gcc version, but they are being tested with C Code and not FB code.
Bit of a turn around for me but if the road ahead is getting progressively more difficult to drive along then, at some point, we should stop, take a deep breath, and ... turn around.
Re: FB-1.07.1-gcc-6.4
@David: interestingly enough, this only happens when compiling a shared lib with optimizations enabled, not with executables. I have a pretty sizable codebase for FreeBasic and all of it compiled flawlessly under the same switches in the Gcc 8 branch. Using -Ofast is merciless, though, and requires pristine code to work right (I tried it with some sloppy old code I have on my HDD and it failed miserably).