Hello everyone.
I'm wondering how the libraries work, i can see a lot of xxxxx.dll.a and xxxxx.bi are coming with the freebasic compiler but i don't get what are they for and how to use them.
I've seen a tutorial using '$include: "allegro.bi" but this doesn't tell what version is it. Also I 've read on these forums that nearly any C library can work with freebasic, but i don't know how to add them since libraries for C don't include .bi files.
So, how to import any C libs in my freebasic sources, if that's possible ?
Libraries, how do they work ?
-
anonymous1337
- Posts: 5494
- Joined: Sep 12, 2005 20:06
- Location: California
Re: Libraries, how do they work ?
Hello, hide.
I can't answer your question fully, but I can give some short answers until someone else comes along.
- FreeBASIC's .bi files are the equivalent of C's .h files. They're both header files and contain declarations so that the compiler knows what function definitions to look for in a library.
- FreeBASIC's libraries (.dll, .a) are compiled, just like libraries in C. Ex: They're not human-readable. They're just portable lists of compiled functions.
- You use libraries by including their respective header files, and then including the library in your executable. (The latter can be done in various ways.)
- Yes, you can use C libraries in FreeBASIC. I think FreeBASIC's binary interfacing is 100% (or very close) compatible with C. C++, not so much :)
- C libraries can be used by declaring external functions with the Cdecl calling convention. The default FreeBASIC calling convention is StdCall, which does things a little differently.
I hope that gives a sense of direction!
I'm off to bed :(
Will try to assist more later...
I can't answer your question fully, but I can give some short answers until someone else comes along.
- FreeBASIC's .bi files are the equivalent of C's .h files. They're both header files and contain declarations so that the compiler knows what function definitions to look for in a library.
- FreeBASIC's libraries (.dll, .a) are compiled, just like libraries in C. Ex: They're not human-readable. They're just portable lists of compiled functions.
- You use libraries by including their respective header files, and then including the library in your executable. (The latter can be done in various ways.)
- Yes, you can use C libraries in FreeBASIC. I think FreeBASIC's binary interfacing is 100% (or very close) compatible with C. C++, not so much :)
- C libraries can be used by declaring external functions with the Cdecl calling convention. The default FreeBASIC calling convention is StdCall, which does things a little differently.
I hope that gives a sense of direction!
I'm off to bed :(
Will try to assist more later...
Re: Libraries, how do they work ?
Hi hide, and welcome to the forum :-)
To use a library written and compiled with C you just need to port the header (the .h file/s) to FB headers (the .bi file/s), which is actually reasonably simple most of the time but it can take a while if the headers are long. A lot of the commonly used headers are already ported to FB but if you find one you want to use that isn't then you can try and port it yourself, or ask about it on the forum.
A quick run down of the file types, although I'm not sure or your level of experience so forgive me if I overdo it. Also, if I mess any of these up I'm sure someone will correct me.
.bas --the normal place to put FB code (equivalent to C's .c files).
.bi --the normal place to put function declarations and stuff (equivalent to C's .h files)
.exe -- is of course the compiled program code. Machine readable code.
.dll -- is compiled program code that is set up as a library of functions instead of a program
.dll.a -- is used to link your final .exe to any .dll files that it may need
.o -- is a library like a .dll but is build into the .exe at compile time so no extra dll file is required at run time. This makes the .exe larger in size but may be easier for the end user of the program
.a -- can behave like either a .dll.a file or an .o file
.lib -- is similar in purpose to a .a file but cannot be used by the FB linker.
.so -- the Linux/Unix version of a Windows .dll
You can get programs to convert .lib files to .a files if you find a library that you want to use that has a .lib file but not a .a file. Or you could ask on the forum and someone may be able to convert it for you. I think .lib is the Windows standard library file and .a is the Linux/Unix standard, so if the library is written for Windows then it will probably have a .lib file instead of a .a file.
Also, I said that .bi files are the normal place to put file declaration and stuff, but you don't actually have to, it's just the standard layout or format that most people seem to use.
Also also, FB comes with most of the .o .a and .dll.a file that you may need. However depending on the library you may need to download the .dll separately. Libraries like the windows library and OpenGL will be in your system files somewhere are will work straight away, however things like zlib, GTK and many other libraries you will probably need to download the .dll
To use a library written and compiled with C you just need to port the header (the .h file/s) to FB headers (the .bi file/s), which is actually reasonably simple most of the time but it can take a while if the headers are long. A lot of the commonly used headers are already ported to FB but if you find one you want to use that isn't then you can try and port it yourself, or ask about it on the forum.
A quick run down of the file types, although I'm not sure or your level of experience so forgive me if I overdo it. Also, if I mess any of these up I'm sure someone will correct me.
.bas --the normal place to put FB code (equivalent to C's .c files).
.bi --the normal place to put function declarations and stuff (equivalent to C's .h files)
.exe -- is of course the compiled program code. Machine readable code.
.dll -- is compiled program code that is set up as a library of functions instead of a program
.dll.a -- is used to link your final .exe to any .dll files that it may need
.o -- is a library like a .dll but is build into the .exe at compile time so no extra dll file is required at run time. This makes the .exe larger in size but may be easier for the end user of the program
.a -- can behave like either a .dll.a file or an .o file
.lib -- is similar in purpose to a .a file but cannot be used by the FB linker.
.so -- the Linux/Unix version of a Windows .dll
You can get programs to convert .lib files to .a files if you find a library that you want to use that has a .lib file but not a .a file. Or you could ask on the forum and someone may be able to convert it for you. I think .lib is the Windows standard library file and .a is the Linux/Unix standard, so if the library is written for Windows then it will probably have a .lib file instead of a .a file.
Also, I said that .bi files are the normal place to put file declaration and stuff, but you don't actually have to, it's just the standard layout or format that most people seem to use.
Also also, FB comes with most of the .o .a and .dll.a file that you may need. However depending on the library you may need to download the .dll separately. Libraries like the windows library and OpenGL will be in your system files somewhere are will work straight away, however things like zlib, GTK and many other libraries you will probably need to download the .dll
Re: Libraries, how do they work ?
Hello hide, welcome to the forum!
The use of libraries in FB is different on the platforms, ie
To get reasonable help here I recommend that you tell us which OS you want to use.
The best way to get into that stuff is checking some examples in
Ie
will show you how to use the SQLite3 library (you'll have to install additional files to compile and run this example, how to do that is OS specific).
The use of libraries in FB is different on the platforms, ie
- on UNIX the standard calling convention is CDECL, (STDCALL on other systems as Prichard mentioned)
- on UNIX you can easily get the binaries by using the package manager (for windows you have to download and install the DLL
yourself) -
...
To get reasonable help here I recommend that you tell us which OS you want to use.
The best way to get into that stuff is checking some examples in
.../FreeBasic/examples/...
Ie
.../FreeBasic/examples/database/sqlite3_test.bas
will show you how to use the SQLite3 library (you'll have to install additional files to compile and run this example, how to do that is OS specific).
Re: Libraries, how do they work ?
Thanks everyone for your help, I think I get it.
Re: Libraries, how do they work ?
Coming from the past ;], I need some precisions :
For example with Allegro 5, I found binaries here : https://www.allegro.cc/files/.
Now do i need the MinGW ones or MVSC and what version when i'm using the default windows 1.01.0-win64 freebasic ?
Where do i put them ?
Do I need to rename them (if yes, where do i find the name needed ?)
I've tried with the lastest MinGW ones, put them in ~Freebasic\bin\win64\ but the example coming with freebasic don't compile because : "FreeBASIC\inc\allegro5\allegro.bi(1287) error 70: Incomplete type in 'extern _AL_DLL _al_joydrv_directx as ALLEGRO_JOYSTICK_DRIVER'"
For example with Allegro 5, I found binaries here : https://www.allegro.cc/files/.
Now do i need the MinGW ones or MVSC and what version when i'm using the default windows 1.01.0-win64 freebasic ?
Where do i put them ?
Do I need to rename them (if yes, where do i find the name needed ?)
I've tried with the lastest MinGW ones, put them in ~Freebasic\bin\win64\ but the example coming with freebasic don't compile because : "FreeBASIC\inc\allegro5\allegro.bi(1287) error 70: Incomplete type in 'extern _AL_DLL _al_joydrv_directx as ALLEGRO_JOYSTICK_DRIVER'"
Re: Libraries, how do they work ?
Hi,
that's a bug in the FreeBASIC/inc/allegro5/allegro.bi file. I've fixed it in the development version of FB:
https://github.com/freebasic/fbc/commit ... 766af1bb01
(that's just removing the declaration where the error appeared, as it appears to be internal to Allegro 5.0.10)
MinGW is correct; the development libraries go into FreeBASIC\lib\win64.
that's a bug in the FreeBASIC/inc/allegro5/allegro.bi file. I've fixed it in the development version of FB:
https://github.com/freebasic/fbc/commit ... 766af1bb01
(that's just removing the declaration where the error appeared, as it appears to be internal to Allegro 5.0.10)
MinGW is correct; the development libraries go into FreeBASIC\lib\win64.
Re: Libraries, how do they work ?
Oh yep, I had put the .dll in \bin\win64 and the .a in \lib\win64.
Still i have that :
Still i have that :
Code: Select all
C:\Program Files\Dev\FreeBASIC\fbc -s console "hello.bas"
C:\PROGRA~1\Dev\FREEBA~1\bin\win64\ld.exe: cannot find -lallegro
C:\PROGRA~1\Dev\FREEBA~1\bin\win64\ld.exe: cannot find -lallegro_font
C:\PROGRA~1\Dev\FREEBA~1\bin\win64\ld.exe: cannot find -lallegro_ttf
Re: Libraries, how do they work ?
Currently the allegro5/allegro.bi contains
which assumes that there will be a liballegro.a or liballegro.dll.a, but apparently that's wrong.
After looking into the allegro-5.0.10-mingw-4.7.0.7z package I downloaded from the Allegro homepage, there are multiple libraries to choose from:
(or, alternatively, keep using #inclib "allegro" and rename the library file that you want to use to liballegro.a)
I found more information on these various libraries here:
https://www.allegro.cc/manual/5/install/windows.html
I'm going to try and improve allegro5/allegro.bi to support this out-of-the-box.
Code: Select all
#inclib "allegro"After looking into the allegro-5.0.10-mingw-4.7.0.7z package I downloaded from the Allegro homepage, there are multiple libraries to choose from:
Currently you'd have to adjust the allegro5/allegro.bi to use one of the libraries that really exist, for example:liballegro-5.0.10-md.a
liballegro-5.0.10-md-debug.a
liballegro-5.0.10-monolith-md.a
liballegro-5.0.10-monolith-md-debug.a
liballegro-5.0.10-monolith-mt.a
liballegro-5.0.10-monolith-mt-debug.a
liballegro-5.0.10-monolith-static-md.a
liballegro-5.0.10-monolith-static-md-debug.a
liballegro-5.0.10-monolith-static-mt.a
liballegro-5.0.10-monolith-static-mt-debug.a
liballegro-5.0.10-mt.a
liballegro-5.0.10-mt-debug.a
liballegro-5.0.10-static-md.a
liballegro-5.0.10-static-md-debug.a
liballegro-5.0.10-static-mt.a
liballegro-5.0.10-static-mt-debug.a
Code: Select all
#inclib "allegro-5.0.10-md"I found more information on these various libraries here:
https://www.allegro.cc/manual/5/install/windows.html
I'm going to try and improve allegro5/allegro.bi to support this out-of-the-box.
Re: Libraries, how do they work ?
I tried that but still give me an error :
This with the -monolith-md and monolith-mt. Also double checked i'm using the mingw ones.
Code: Select all
C:\PROGRA~1\Dev\FREEBA~1\bin\win64\ld.exe: skipping incompatible C:\Program Files\Dev\FreeBASIC\lib\win64\liballegro.a when searching for -lallegro
Re: Libraries, how do they work ?
Oh, oops, it looks like those libraries are all 32bit, but you're using FB-win64 which needs 64bit libraries. You'd have to get 64bit versions of these libraries, or use FB-win32. Unfortunately I don't see downloads for 64bit versions of the Allegro 5 libraries.
Re: Libraries, how do they work ?
Question here about the dll.a files. Mingw can link directly against a dll file without needing a .dll.a or a .lib file. Cannot FreeBasic do this too since it's using mingw's linker?
Re: Libraries, how do they work ?
Yea, the GNU linker can link against DLLs directly (by reading the DLL and building the lib*.dll.a stuff in-memory on-the-fly), though it doesn't work with all DLLs (I once tried with the BASS.dll, but it failed, probably because that's made with/for MSVC and there are some differences to a "normal" MinGW DLL).
Re: Libraries, how do they work ?
To make Allegro work I just had to use and rename the liballegro_font.a and liballegro_ttf.a for compiling cause looks like monolith isn't enough, when "al_init_font_addon()" "al_init_ttf_addon()" are called.
Then even while using the MT version (should include the dll with the exe?) of all of these i had to put the monolith dll in the folder of my executable for it to run.
But now it works well :D
Thanks dkl.
Then even while using the MT version (should include the dll with the exe?) of all of these i had to put the monolith dll in the folder of my executable for it to run.
But now it works well :D
Thanks dkl.