Where can I get a Recent-Git-Build of FreeBASIC?

[dkl]

When returning a "class", FB allows either Return or Function = foo/Exit Function, but not both. That's due to their current implementation which would conflict when used at the same time, unlike for simple data types like Integer where both can be used within the same function.

[fxm]

'RETURN' mixed with 'FUNCTION =' or 'EXIT FUNCTION' is unsupported when returning objects with constructors:
see dkl's post at http://www.freebasic.net/forum/viewtopi ... 12#p196012

I think this restriction (already in fbc version 0.17) has never been noted in the documentation, if not by the compiler error message!

[fxm]

Documentation updated:
KeyPgFunction ⇒ FxMwikki [Mixing Return and Function= is unsupported when returning objects with constructors]

[St_W]

Recent Git-Builds for DOS, Windows (32/64 bit) and Linux (32/64 bit) platforms are and will be available at:

http://users.freebasic-portal.de/stw/builds/

I have set up a small Jenkins CI Server that automatically triggers builds for the platforms mentioned above when a change is pushed to the FreeBasic master branch at Github. The server is running since february this year, but its bandwidth is very limited. To allow public downloads it does now upload the the latest builds (in case any new builds exist / any changes exist) every night (at around 2:00 GMT+1) to Sebastian's fast FBP Server (see link above).

The file name contains the Jenkins build id and the build date. The packages are currently using ZIP-Compression (done by 7zip). The content of the various packages differs. e.g. the windows and dos packages contain the toolchain binaries (mingw / djgpp), the linux version only contains the compiled binaries.
Please note that you may have to force page reload/refresh (usually by hitting F5, Ctrl+F5 or similar) to see the latest uploads (at least Firefox requires me to do that).

If you have any comments, questions, suggestions, improvements do not hesitate to tell me.

[fxm]

Could we have a full win32 build (.zip) without using mingw?

[St_W]

I currently have two win32 build-jobs: one using mingw and another one using tdm-gcc. As far as I know the official FreeBasic builds are made using the MinGW toolchain again; after a few Versions were built with the tdm-gcc toolchain.

I have forgotten to include 2 DLLs needed for win32 mingw in the package, these will be included in the next builds. Additionally the toolchain binaries will be upx compressed to save space. These settings will be used for new builds from now on. Please tell me if and which other files should be included / excluded.

I've manually triggered a new win32 mingw build which includes these changes: http://users.freebasic-portal.de/stw/bu ... -05-04.zip

[fxm]

Could we have a full win32 build (.zip) without using mingw?

Win32 Binaries

• FreeBASIC-0.90.1-win32.exe
  Windows installer.
• FreeBASIC-0.90.1-win32.zip (or as .7z)
  FB in a .zip - can be extracted anywhere.
• fbc-0.90.1-mingw32.zip (or as .7z)
  fbc for installation into a MinGW tree, like a MinGW.org package. Built for the MinGW.org toolchain.
• Windows Libraries: third-party libraries used by many of the headers and examples
• Windows Add-ons: additional programs used for cross-compiling or compiling with gcc. (Note: cross-compiling will require the lib subfolder from that platform's FreeBASIC installation.)

I spoke about the second bullet (FreeBASIC-0.90.1-win32.zip), as MOD builds!

[Edit]
OK with the last build above.

[St_W]

The mingw package should contain everything that is needed to compile a freebasic program except Microsoft C Runtime. So no additional mingw installation or tools are needed. The compiled programs do not depend on any external mingw libraries either. That's why I didn't understand your request for a build "without using mingw".

I've compared my package to the release package and a package by MOD. What is not included currently in my packages is:
- gdb and gprof
- examples
- most third-party include files
- third-party import libraries
- readme, changelog, doc folder
If I understood you correctly you want all that stuff included in the package, right? Third-Party import libs are currently not generated so give me some time for changing that. I will change the packaging job to include all these files. Please tell me if I've missed something.

I hope that's what you want :-)

[fxm]

Excuse me but I only tested your previous builds that don't worked!
With the build 067, all is right.
Not necessary to add any files.
Thanks.

[maxarg]

@MOD

Hi to All! I'm new to this forum.
Excellent work MOD for the x64 build, but I'm unable to compile 64bit dll with exported functions

Public Function Test_Exp(i As integer) As Integer Export
Return 1
End Function

*** Error: Cannot export TEST_EXP@8: symbol not found

Some hints?

Thanks a lot

[dkl]

Oh, looks like fbc is still using the @N suffix for stdcall procedures on 64bit, even though there's no stdcall on 64bit. That should be easy to fix though.

Overall however, building 64bit Win32 DLLs or Linux .so's isn't working yet anyways, as fbc doesn't use -fPIC when invoking gcc, and the FB runtime libraries aren't built with -fPIC, and fbc doesn't use the -fPIC-specific gcc libraries/objects, and so on.

[maxarg]

@dkl

Thank you a lot for the explanation,
i tried to "force" the CDecl calling convention and the compilation was successful but with a warning, :-|
...\ld.exe: warning: cannot find entry symbol _Dll MainCRTStartup@12; defaulting to 0000000010001000
But DLL was generated and Dll_export_viewer shows now the exported function (not decorated)

Do you think that in the near future fbc will be able to generate x64 libraries?

Cheers to you and all the fbc team, ;-)
Massimiliano

[dkl]

The -e _DllMainCRTStartup@12 ld argument is hard-coded in fbc, that also needs adjustment. I'll have to check what MinGW-w64 uses in this case, but probably just _DllMainCRTStartup (without the @N suffix).

Yea, I'm going to work on that soon - it's needed for the next release. I wouldn't want to release 64bit support without supporting building DLLs.

[maxarg]

@dkl
Hi, give a look at this scenario (fbc 0.91 32bit DLL invoked by VB6):

'freebasic 32bit DLL
Public Function TEST_DLL StdCall (ByVal dllName As String) As Any Ptr Export
Return DylibLoad(dllName)
End Function

'VB6 form
Private Declare Function TEST_DLL Lib "D:\TEST\TEST.dll" Alias "TEST_DLL@4" (ByVal dllName As String) As Long

Private Sub Form_Load()
Debug.Print TEST_DLL("user32")
End Sub

VB6 crash in dll load with 0.91devel, with fbc 0.90.1release all is OK
I'm doing something wrong?

Many thanks

[dkl]

Byval As String is now implemented "properly". In older versions it's just a Byval As Zstring Ptr, but now it's implemented by passing a pointer to a temporary FBSTRING descriptor, to get the true Byval semantics.

I guess it's now incompatible to VisualBasic's Byval As String? It should work again by declaring the parameter as Byval As Zstring Ptr on the FB side.