Prepare next release 5.0.3

[MartinKoeditz]

I think next release should be 5.0.4. What do you think? When can we release it?

[mlazdans]

I thought a bit about versioning. It's kind good idea to keep versioning 3 and 5 to indicate against which client library extension was compiled against. If compiling against fbclient 3 ever needed though.

Why not Is 5.0.3? Is it taken?

[mlazdans]

I want to will play with github actions a bit. Maybe something useful like auto builds could be extracted out of them.

Btw, do we need providing Linux binaries? Compiling on Linux is quite straightforward. Will they even work on other distros when compiled on say latest Ubuntu?

[MartinKoeditz]

Oh, my fault. 5.0.3 is ok.

Yes, we need Linux binaries. They are compatible to other distros.

[MartinKoeditz]

I tried using github actions. But I didn't get them to work.

[MartinKoeditz]

Linux builds are no problem. It's been created in few minutes. Windows build are time consuming since I have to build them one by one. Maybe we can create some automatic task here.

[mlazdans]

I'm currently exploring how to automate windows building. On my machine I successfully built current master with fb5 client lib and these PHP (each x86/x64 and x86-nts/x64-nts): php-7.3.33 php-7.4.13 php-8.0.30 php-8.1.33 php-8.2.29 php-8.3.26 php-8.4.13 php-8.5.0RC2

[mlazdans]

I did not notice you tagged 5.0.3 and made it a pre-release. This will crash when using service attach due to this https://github.com/FirebirdSQL/php-firebird/commit/3eb5e4eea7155a1e14c47331151a3320e0434a26

[mlazdans]

Please delete it for now so that buggy extensions does not get distributed around.

[mlazdans]

I deleted it for now myself.

[MartinKoeditz]

OK. Then we need a test case for that.

[mlazdans]

No plans for x86 Linux builds?

[MartinKoeditz]

Well, I have to setup the environment first. Then yes.

[mlazdans]

I would suggest version naming: 5.0.x.x -> indicating compiling against FB5.0 client libs 3.0.x.x -> indicating compiling against FB3.0 client libs (if ever needed) 2.5.x.x -> indicating compiling against FB5.0 client libs (if ever needed)

x.x then would be for php-firebird versions e.g. 5.0.3.0 would be the next release.

Any thoughts?

[mlazdans]

Suggestion about binary file naming.

Windows:

php8.4_interbase-3.0.1-vs17.dll php8.4_interbase-3.0.1-vs17-nts.dll php8.4_interbase-3.0.1-vs17-nts-x86.dll php8.4_interbase-3.0.1-vs17-x86.dll

Linux:

php8.4-interbase-5.0.3-linux.so php8.4-interbase-5.0.3-linux-x86.so

Other platforms: ???

Do we need explicitly adding x86_64? Maybe defaulting to 64-bit if not specified explicitly. I find this very distracting and confusing with x86 especially if I end up with tons of files (like on Windows) 😅

[mlazdans]

Second thoughts.

Putting FB client version in php-firebird version seem kind of redundant? Instead lets define proper version for php-firebird itself in style x.x.x (major.minor.revision). Let's define PHP_INTERBASE_VER as major*10+minor (same style as FB_API_VER) and expose it via constant to extension users. Soi that changing major version would indicate to users possible breaking changes (if any).

Due to fact 5.x.x is already taken, let's start with 6.1.1? Here's a draft of what I've come up with:

#define PHP_INTERBASE_VER_MAJOR 6
#define PHP_INTERBASE_VER_MINOR 1
#define PHP_INTERBASE_VER_REV 1

// Keep in FB_API_VER two digit style
#define PHP_INTERBASE_VER PHP_INTERBASE_VER_MAJOR * 10 + PHP_INTERBASE_VER_MINOR
#define PHP_INTERBASE_VER_STR TO_STRING(PHP_INTERBASE_VER_MAJOR) "." TO_STRING(PHP_INTERBASE_VER_MINOR) "." TO_STRING(PHP_INTERBASE_VER_REV)

I still wan to indicate against which client library version extension was compiled against so let's and that to filename same style as PHP API version: php84_interbase50-6.1.1-vs17-x86.dll

[mlazdans]

I've been experimenting with a bit newer API with fb_get_master_interface() looks nice and promising. There is one issue however.

I can disable use of fb_get_master_interface() at compile time by checking FB_API_VER >= 40 and fallback to older API if needed. But in case of older fbclient libs could be picked up by dynamic linker this will now crash with dynamic linking errors like:

symbol lookup error: ./modules/interbase.so: undefined symbol: fb_get_master_interface

and needlessly flood Issues section I feel. And I absolutely do not want to deal with that.

Possible solutions:

1. Check client version at runtime and do runtime checks each time we need call to newer API. <- probably simplest solution
2. Require matching compile time and runtime libraries.
3. Link fbclient statically into extension.

Because of fbclient is not shipped with static libs probably means there is a good reason for that and this feels like a potential massive rabbit hole, will increase a size and other potential unforeseen issues, maybe conflicting with PDO_Firebird. Maybe @AlexPeshkoff can comment more static linking. Possible benefit - no need for user to search fbclient library and extension will contain matching versions.

Any thoughts?

[AlexPeshkoff]

On 10/24/25 15:44, mlazdans wrote:

mlazdans left a comment (FirebirdSQL/php-firebird#70) https://github.com/FirebirdSQL/php-firebird/issues/70#issuecomment-3442962045

I've been experimenting with a bit newer API with |fb_get_master_interface()| looks nice and promising. There is one issue however.

I can disable use of |fb_get_master_interface()| at compile time by checking |FB_API_VER >= 40|

= 30 is enough

and fallback to older API if needed. But in case of older fbclient libs could be picked up by dynamic linker this will now crash with dynamic linking errors like:

symbol lookup error: ./modules/interbase.so: undefined symbol:
fb_get_master_interface

and needlessly flood Issues section I feel. And I absolutely do not want to deal with that.

Martin, I do not know how do you access dynamic linker from PHP driver code. If you use command line parameter -lfbclient - yes, such message is unavoidable (and prevents load of binary module which has unresolved reference). But if you use dlopen() on linux / LoadLibrary() on windows nothing should go to tty.

Possible solutions:

    0. Take into an account that FB2.5 is not supported by us for many years and require client library from supported versions.  :-)

1. Check client version at runtime and do runtime checks each time we need call to newer API. |<- probably simplest solution|

This should work.

1. Require matching compile time and runtime libraries.

Not best option. Imagine you built with FB4 client but users deal with FB5 which can work perfectly with PHP driver but looks like exact match will cause problems.

1. Link fbclient statically into extension.

Because of fbclient is not shipped with static libs probably means there is a good reason for that and this feels like a potential massive rabbit hole, will increase a size and other potential unforeseen issues, maybe conflicting with PDO_Firebird. Maybe @AlexPeshkoff https://github.com/AlexPeshkoff can comment more static linking. Possible benefit - no need for user to search fbclient library and extension will contain matching versions.

On the on hand static library can be built - but taking into an account plugins-based architecture this makes very small sense on my mind.

PS. Once again - for me problem appears artificial. At least you do not require compatibility with windows 3.11 :-)

[mlazdans]

Thanks for insights. So the best solution indeed would be runtime checks. For fb_get_master_interface FB 30 is enough but fb_get_statement_interface needs 40 if I understand correctly. So these checks will not go away even if we drop 2.5.x support. So I'm thinking I might still keep supporting 2.5.x mostly because we still have bunch of FB 2.5.9 servers and dozens of old databases 😅 I still have to support them for some (long?) time so I may as well do it "officially" as well. Few more checks here and there won't change much in this situation.

In PHP extension this is how they checked symbols and then fetch client version (and appropriate Windows counterpart):

info_func = (info_func_t)dlsym(RTLD_DEFAULT, "isc_get_client_version");

So I think I will experiment some more with runtime checks.

[AlexPeshkoff]

On 10/24/25 17:02, mlazdans wrote:

mlazdans left a comment (FirebirdSQL/php-firebird#70) https://github.com/FirebirdSQL/php-firebird/issues/70#issuecomment-3443329008

Thanks for insights. So the best solution indeed would be runtime checks. For |fb_get_master_interface| FB 30 is enough but |fb_get_statement_interface|

Ahh, I see - you plan to have a mix of 2 APIs.

needs 40 if I understand correctly. So these checks will not go away even if we drop 2.5.x support. So I'm thinking I might still keep supporting 2.5.x mostly because we still have bunch of FB 2.5.9 servers and dozens of old databases 😅 I still have to support them for some (long?) time so I may as well do it "officially" as well. Few more checks here and there won't change much in this situation.

New client works just fine with old servers. Certainly it's not embedded access - but for 2.5 special library instead fbclient is anyway needed.

In PHP extension this is how they checked symbols and then fetch client version (and appropriate Windows counterpart):

info_func = (info_func_t)dlsym(RTLD_DEFAULT,"isc_get_client_version");

So I think I will experiment some more with runtime checks.

|get_master_interface = (master_type_t) dlsym(RTLD_DEFAULT, "fb_get_master_interface");

should also do what you want, and this appears a little simpler

|

[mlazdans]

I'm very curious about "for 2.5 special library instead fbclient is anyway needed." To what special lib are you referring?