BASS 2.4.8.1 Header
BASS 2.4.8.1 Header
I've translated the latest header of BASS 2.4.8.1
@sir_mud: would you upload it to the fb-header-project. Would be great to have new header with fbc 0.24.
@sir_mud: would you upload it to the fb-header-project. Would be great to have new header with fbc 0.24.
Re: BASS 2.4.8.1 Header
Thanks, it's in git now. I generated a def from the included dll since there wasn't one included.
Re: BASS 2.4.8.1 Header
Sorry, I forgot about the def file. Thank you.
Re: BASS 2.4.8.1 Header
Update:
-new example with Creative Commons Attribution-Noncommercial-Share Alike 3.0 License example sounds
They could be included as examples for the fbc-download.
(Same link - see first post)
sir_mud: the version you've uploaded differs from my version. theres at least one problem in line 420:
You've mixed 'cdecl' and 'function'.
'extern "C"' seems wrong as well.
-new example with Creative Commons Attribution-Noncommercial-Share Alike 3.0 License example sounds
They could be included as examples for the fbc-download.
(Same link - see first post)
sir_mud: the version you've uploaded differs from my version. theres at least one problem in line 420:
Code: Select all
type RECORDPROC as cdecl function (byval as HRECORD, byval as const any ptr, byval as DWORD, byval as any ptr) as BOOL
'extern "C"' seems wrong as well.
-
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
Re: BASS 2.4.8.1 Header
When I try to compile a program that uses BASS among other things, I get duplicate definitions errors on these two lines:
Any ideas?
Code: Select all
#define MAKEWORD(a,b) Cast(WORD, ((a) And &hFF) Or ((b) Shl 8))
#define MAKELONG(a,b) Cast(DWORD, ((a) And &hFFFF) Or ((b) Shl 16))
Re: BASS 2.4.8.1 Header
And why this is a bass header fault? :P
Seems like windows headers also use these definitions in windef.bi.
Seems like windows headers also use these definitions in windef.bi.
-
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
Re: BASS 2.4.8.1 Header
I'm not saying it's anyone fault, just trying to compile a program in Windows, and the compilation halted in bass.bi.
Re: BASS 2.4.8.1 Header
If you swap the include lines, it will stop on windef.bi.
You could delete the lines from bass.bi because you don't need them for every bass usage.
You could delete the lines from bass.bi because you don't need them for every bass usage.
Re: BASS 2.4.8.1 Header
@Lachie Dazdarian:
Consider to use a NAMESPACE-block around one of the headers.
Consider to use a NAMESPACE-block around one of the headers.
Re: BASS 2.4.8.1 Header
thats why we have #ifdef #endif =)
Re: BASS 2.4.8.1 Header
The current compiler 0.24 comes with mixed up files as I see. I don't know where that .dll.a comes from and the header uses extern blocks which are also a problem.
I recommend to use my files from the link in the first post.
I recommend to use my files from the link in the first post.
Re: BASS 2.4.8.1 Header
I fixed FB's BASS .def file, so the import library should be correct in the next FB release.
Checking the bass.dll and the original bass.h header, it exports stdcall functions without @N suffix. FB's bass.bi header was changed to use Extern "windows-ms" to match this, however the import library was not adjusted accordingly. In the past the bass.bi header used @N suffixes, and the import library provided the symbols with @N too, and then linked them up with the corresponding symbols without @N from the bass.dll, by using dlltool's --kill-at switch. Now that the header itself uses the correct mangling (no @N suffix), the import library doesn't need to do any tricks anymore.
By the way, the import library still seems to be required: I tried letting ld link against the bass.dll directly, but it failed with a "file format not recognized" error. This worked with other DLLs for me in the past, but apparently it doesn't like the bass.dll for some reason.
Checking the bass.dll and the original bass.h header, it exports stdcall functions without @N suffix. FB's bass.bi header was changed to use Extern "windows-ms" to match this, however the import library was not adjusted accordingly. In the past the bass.bi header used @N suffixes, and the import library provided the symbols with @N too, and then linked them up with the corresponding symbols without @N from the bass.dll, by using dlltool's --kill-at switch. Now that the header itself uses the correct mangling (no @N suffix), the import library doesn't need to do any tricks anymore.
By the way, the import library still seems to be required: I tried letting ld link against the bass.dll directly, but it failed with a "file format not recognized" error. This worked with other DLLs for me in the past, but apparently it doesn't like the bass.dll for some reason.