Firebird vcpkg registry

[Adriano dos Santos Fernandes]

Hi!

I had another attempt to put Firebird client in vcpkg but decided to
stop. The reviewers are not going to allow it. We are not nearly going
to pass their requirements. We mix static and dynamic linkage, we depend
on libraries imported in our repository, we depend on external libraries
not present in their registry, etc.

So I decided to create a custom registry instead, with less policies and
politics:

https://github.com/asfernandes/firebird-vcpkg-registry

This registry currently has the Firebird client 5.0.3 and fb-cpp 0.0.1,
working in Linux, Windows and MacOS.

If you are interested, please test it.

And if there is no objection, I plan to later move this registry to the
FirebirdSQL github org.


Adriano

[F. D. Castel]

Is it really such a bad idea to keep everything statically linked nowadays?

It’s 2025 -- we have automated builds and releases.

What’s the actual downside? Disk space? My video driver alone is almost one gigabyte.

Depending on external components just makes testing and reproducibility more difficult, not to mention the installation nightmares that come with it.

And if a bug appears in any of those components -- I believe this was cited recently -- publishing a patched version is (or should be) as simple as pushing a new Git tag to the official repository.

[Adriano dos Santos Fernandes]

On 11/18/25 23:08, F. D. Castel wrote:
> Is it really such a bad idea to keep everything statically linked nowadays?
>
> It’s 2025 -- we have automated builds and releases.
>
> What’s the actual downside? Disk space? My video driver alone is almost
> one gigabyte.
>
> Depending on external components just makes testing and reproducibility

> more difficult, not to mention the *installation nightmares <https://
> github.com/FirebirdSQL/firebird/issues/6418#issuecomment-826245785>*

> that come with it.
>
> And if a bug appears in any of those components -- I believe this was
> cited recently -- publishing a patched version is (or should be) as
> simple as pushing a new Git tag to the official repository.
>

I don't buy the Alex argument in the another thread about libtom*,
specially because in Windows they are statically linked. Would we
release a Windows-only version of Firebird because of a dependency? Much
probably not.

But the thing about static/dynamic in vcpkg is much large thing. First,
this is user choice and the Linux default is static, but Windows default
is dynamic (and pure dynamic, not a dynamic library sometimes linked
with static dependencies).

We have in the default package code to locate non-binary dependencies
based in the dynamic library location. A static library would switch
this to the user application/library location.

We override the default "new operator". That's very problematic for a
static library.

But not problematic only for static library. Considering engine code, we
already had problem when linking dynamic libre2 with dynamic libEngine.
C++ classes may have inline destructors and non-inline constructors.
When we override the new operator and don't export it (like we do), that
causes problems. Even when linking the std libraries dynamically.

But also, we link the libstdc++ library statically in Linux to avoid
this type of problems too. In MacOS, we need to build libc++ statically
ourselves as the dynamic one caused problems.

I don't know why we don't have such problems in Windows. Maybe the std
library is internally well implemented to avoid this type of problems.


Adriano