Firebird 4.0 installing in AWS Ubuntu 20.04.3 IMPOSSIBLE!

[Franz Fortuny L]

First terrible error in the install.sh file:

A line says 'x86-64' and it should be 'aarch64'. Hours to find the problem.

I thought the rest of the day would be happiness...

Total failure!

I finally got this problem:

./install.sh: 171: /opt/firebird/bin/gsec: Exec format error

Fatal error running 'systemctl --quiet start firebird.service' - exiting

gsec can not be executed:

/home/ubuntu/fb4# /opt/firebird/bin/gsec

bash: /opt/firebird/bin/gsec: cannot execute binary file: Exec format error

So it can not be installed, since it requires to be executed before the execution proceeds.

It was never possible to install it.

I had tested it and it was mostly all fine under Ubuntu 20.04 under WSL 2 (Windows 10-11). But it turned out NOT TO WORK under the real thing.

[Mark Rotteveel]

On 2021-11-05 04:01, Franz Fortuny L wrote:
> First terrible error in the install.sh file:
>
> A line says 'x86-64' and it should be 'aarch64'. Hours to find the
> problem.

That means you're using an installer for x86-64/amd64 (Intel/AMD), not
aarch64 (ARM). These are not the same thing, so it is expected not to
work. The Firebird project itself does not provide aarch64 binaries.

You need to switch to an x86-64 machine (AWS offers several), otherwise
you will probably need to build from source (though I'm not sure of the
aarch64 support in the sources, so you may want to ask on
firebird-devel), or check if Ubuntu itself packages an aarch64 build of
Firebird.

> I thought the rest of the day would be happiness...
>
> Total failure!
>
> I finally got this problem:
>
> ./install.sh: 171: /opt/firebird/bin/gsec: Exec format error
>
> Fatal error running 'systemctl --quiet start firebird.service' -
> exiting
>
> gsec can not be executed:
>
> /home/ubuntu/fb4# /opt/firebird/bin/gsec
> bash: /opt/firebird/bin/gsec: cannot execute binary file: Exec format
> error

That is because you're trying to run a x86-64/amd64 binary on an aarch64
platform. That will not work.

> So it can not be installed, since it requires to be executed before
> the execution proceeds.
>
> It was never possible to install it.
>
> I had tested it and it was mostly all fine under Ubuntu 20.04 under
> WSL 2 (Windows 10-11). But it turned out NOT TO WORK under the real
> thing.

That is because Ubuntu under WSL2 is an x86-64/amd64 platform, not
aarch64.

Mark

[Franz Fortuny L]

 

I just learned what you mention here THE HARD WAY.

At the FirebirdSQL.org site, it would be GREAT if what you have just mentioned here had been mentioned there, at the Download page.

I downloaded the 3rd option. "Linux AMD64". It is the 64-bit Kit, (option 1). It is now working.

Thank you for your response. It looks as it should have been OBVIOUS, but for the mentioned reason, it did not seem so to me.

 

[Dimitry Sibiryakov]

Franz Fortuny L wrote 05.11.2021 15:53:
> It looks as it should have been OBVIOUS, but for the mentioned reason, it did
> not seem so to me.

The difference between processor architectures IS obvious.
Less obvious may be the fact that AMD64 is compatible with Intel x86_64, but
ARM processor is definitely out of line.

--
WBR, SD.

[Mark Rotteveel]

On 05-11-2021 15:53, Franz Fortuny L wrote:
> fbimgx86.png
>
> I just learned what you mention here THE HARD WAY.
>
>
> At the FirebirdSQL.org site, it would be GREAT if what you have just
> mentioned here had been mentioned there, at the Download page.

What should have been mentioned? That you can't use the binaries for the
AMD64 instruction set (a.k.a. x86-64[1]) on processors with the
aarch64[2] (a.k.a. arm64) instruction set? That is already implied by
the use of the name AMD64, and repeating that in another form does not
improve clarity IMHO.

Mark

[1]: https://en.wikipedia.org/wiki/X86-64
[2]: https://en.wikipedia.org/wiki/AArch64
--
Mark Rotteveel

[Franz Fortuny L]

Lesson learned.

At AWS a t4g server is ARM64 and a t3a or t3 server is X86. t4g servers cost less than t3a servers.

[Franz Fortuny L]

Just for the record:

I tried to do this today (I have a couple servers doing that for 7 years already):

Server A: httpd with php with interbase extension (AARCH64)

Sever B: Firebird 4 (X86)

Nodejs (node-firebird, latest version) connected correctly from Server A to Server B ONLY AFTER IBExpert was used to CONFIRM user SYSDBA and password through User Manager. GSEC should have been able to do this, but it failed.

Server A: interbase and pdo_firebird were NEVER recognized as libraries when starting Apache2:

These were the errores logged:

[Fri Nov 05 19:10:25.844361 2021] [mpm_prefork:notice] [pid 61463] AH00171: Graceful restart requested, doing restart

PHP Warning:  PHP Startup: Unable to load dynamic library 'pdo_firebird' (tried: /usr/lib/php/20200930/pdo_firebird (/usr/lib/php/20200930/pdo_firebird: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/pdo_firebird.so (/usr/lib/php/20200930/pdo_firebird.so: undefined symbol: php_pdo_unregister_driver)) in Unknown on line 0

But locate finds them:

# locate pdo_firebird.so

/usr/lib/php/20200930/pdo_firebird.so

# locate interbase

/usr/share/php8.0-interbase

/usr/share/php8.1-interbase

/usr/share/bug/php8.0-interbase

/usr/share/bug/php8.1-interbase

/usr/share/bug/php8.0-interbase/control

/usr/share/bug/php8.0-interbase/script

/usr/share/bug/php8.1-interbase/control

/usr/share/bug/php8.1-interbase/script

/usr/share/doc/php8.0-interbase

/usr/share/doc/php8.1-interbase

/usr/share/lintian/overrides/php8.0-interbase

/usr/share/lintian/overrides/php8.1-interbase

/usr/share/php8.0-interbase/interbase

/usr/share/php8.0-interbase/interbase/pdo_firebird.ini

/usr/share/php8.1-interbase/interbase

/usr/share/php8.1-interbase/interbase/pdo_firebird.ini

/var/lib/dpkg/info/php8.0-interbase.list

/var/lib/dpkg/info/php8.0-interbase.md5sums

/var/lib/dpkg/info/php8.0-interbase.postinst

/var/lib/dpkg/info/php8.0-interbase.postrm

/var/lib/dpkg/info/php8.0-interbase.preinst

/var/lib/dpkg/info/php8.0-interbase.prerm

/var/lib/dpkg/info/php8.0-interbase.triggers

/var/lib/dpkg/info/php8.1-interbase.list

/var/lib/dpkg/info/php8.1-interbase.md5sums

/var/lib/dpkg/info/php8.1-interbase.postinst

/var/lib/dpkg/info/php8.1-interbase.postrm

/var/lib/dpkg/info/php8.1-interbase.preinst

/var/lib/dpkg/info/php8.1-interbase.prerm

/var/lib/dpkg/info/php8.1-interbase.triggers

That is the AArch64 Linux machine. (AWS t4g.small). Unusable as PHP Client of a Firebird 4.0 server.

It is is usable as client of node-firebird from the AARCH64 machine to the X86 machine exclusively for Firebird 4.0

The ONLY universal client will be node-firebird, since it doesn't require binary extensions.

Is this what would have been expected?

[Mark Rotteveel]

On 06-11-2021 05:45, Franz Fortuny L wrote:
> Just for the record:
>
> I tried to do this today (I have a couple servers doing that for 7 years
> already):
>
> Server A: httpd with php with interbase extension (AARCH64)
>
> Sever B: Firebird 4 (X86)
>
> Nodejs (node-firebird, latest version) connected correctly from Server A
> to Server B ONLY AFTER IBExpert was used to CONFIRM user SYSDBA and
> password through User Manager. GSEC should have been able to do this,
> but it failed.
>
> Server A: interbase and pdo_firebird were NEVER recognized as libraries
> when starting Apache2:
>
> These were the errores logged:
>
> [Fri Nov 05 19:10:25.844361 2021] [mpm_prefork:notice] [pid 61463]
> AH00171: Graceful restart requested, doing restart
> PHP Warning:  PHP Startup: Unable to load dynamic library 'pdo_firebird'
> (tried: /usr/lib/php/20200930/pdo_firebird
> (/usr/lib/php/20200930/pdo_firebird: cannot open shared object file: No
> such file or directory), /usr/lib/php/20200930/pdo_firebird.so
> (/usr/lib/php/20200930/pdo_firebird.so: undefined symbol:
> php_pdo_unregister_driver)) in Unknown on line 0
>
> But locate finds them:
>

[..]

>
> That is the AArch64 Linux machine. (AWS t4g.small). Unusable as PHP
> Client of a Firebird 4.0 server.
>
> It is is usable as client of node-firebird from the AARCH64 machine to
> the X86 machine exclusively for Firebird 4.0
>
> The ONLY universal client will be node-firebird, since it doesn't
> require binary extensions.
>
> Is this what would have been expected?

AFAIK - but I don't program in PHP - both pdo_firebird and interbase
require libfbclient.so, which means you need a libfbclient.so compiled
for aarch64.

You can install libfbclient2 using apt; it will give you the Firebird
3.0 client library, which means you may have to configure your Firebird
4.0 server with setting DataTypeCompatibility = 3.0 (but you already
need to do that because of Firebird PHP (Interbase) driver lacking
support for the newer types).

I don't know what the state is of aarch64 support in the sources, but
given there is an Android ARM64 build, I suspect most of it is in place.
I wonder in how far that Android ARM64 build is really Android specific.
In any case, I would recommend creating an issue asking for Linux
aarch64 support https://github.com/FirebirdSQL/firebird/issues.

Alternatively, you could consider using Firebird 3.0 for now (Ubuntu
provides an aarch64/arm64 build), until they provide a Firebird 4.0 port.

Mark
--
Mark Rotteveel

[Franz Fortuny L]

I find your comments enlightening.

If it is a matter of compiling under ARM64, maybe we could try that.

I tried compiling Firebird 4.0... no success:

I got this:

error: ICU support not found - please install development ICU package

(Nothing about it. The package ICU-DEV has been installed and the package ICU-doc ('??) was installed, too. But no success.

Las lines:

...

checking sys/sockio.h presence... no

checking for sys/sockio.h... no

checking winsock2.h usability... no

checking winsock2.h presence... no

checking for winsock2.h... no

checking whether SOCK_CLOEXEC is declared... yes

checking zlib.h usability... yes

checking zlib.h presence... yes

checking for zlib.h... yes

checking unicode/ucnv.h usability... no

checking unicode/ucnv.h presence... no

checking for unicode/ucnv.h... no

configure: error: ICU support not found - please install development ICU package

...

It stops right there.

There were two identical statements in a Google Search: both unanswered.

One since 2018 and another one form July. They are still waiting for a response.

Is that why it is not possible to compile this ARM64 version of Firebird 4.0?

[Franz Fortuny L]

After a number of installs, really, a lot, it was finally possible to run "make".

But all I needed was the interbase.so extension and the correct pdo_firebird extension.

Those did not show anywhere once the compilation was finally finished. Which means I got nowhere. I compiled the set of Firebird utilities that I will not be using on the ARM64 machine, since this machine will only take care of the HTTP requests and connect to the other machine where Firebird 4.0 is now residing and apparently doing what it needs to do correctly with a 1.2 GB database.

So, compiling was a waste of time. The extensions are needed were NOT part of the binaries generated.

... Should I forget about php and try using node-firebird instead? It is working just fine so far.

[Mark Rotteveel]

On 07-11-2021 02:07, Franz Fortuny L wrote:
> I find your comments enlightening.
>
> If it is a matter of compiling under ARM64, maybe we could try that.
>
> I tried compiling Firebird 4.0... no success:
>
> I got this:
>
> error: ICU support not found - please install development ICU package
>

[..]

> checking for unicode/ucnv.h... no
> configure: error: ICU support not found - please install development ICU
> package
> ...
>
> It stops right there.
>
> There were two identical statements in a Google Search: both unanswered.
>
> One since 2018 and another one form July. They are still waiting for a
> response.
>
> Is that why it is not possible to compile this ARM64 version of Firebird
> 4.0?

Please ask questions about building Firebird from source on the
firebird-devel list (see https://firebirdsql.org/en/mailing-lists/ under
"Firebird Developers' Lab") as that is the place to ask about building
and/or porting Firebird..

That said, have you also tried by installing the libfbclient2 library
using apt as I suggested? That would seem to be the simpler approach to
me than compiling from source. It is the Firebird 3.0 client library,
but it should be able to connect to a Firebird 4.0 database. You will
need to specify the DataTypeCompatibility setting, but that would even
be the case when you're using the Firebird 4.0 client library, because
the Firebird PHP driver also doesn't support the types introduced in
Firebird 4.0.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

On 07-11-2021 08:41, Franz Fortuny L wrote:
> After a number of installs, really, a lot, it was finally possible to
> run "make".
>
> But all I needed was the interbase.so extension and the correct
> pdo_firebird extension.

Both interbase.so and pdo_firebird use libfbclient.so.

> Those did not show anywhere once the compilation was finally finished.
> Which means I got nowhere. I compiled the set of Firebird utilities that
> I will not be using on the ARM64 machine, since this machine will only
> take care of the HTTP requests and connect to the other machine where
> Firebird 4.0 is now residing and apparently doing what it needs to do
> correctly with a 1.2 GB database.
>
> So, compiling was a waste of time. The extensions are needed were NOT
> part of the binaries generated.

The binary you need from your compilation effort is libfbclient.so.

> ... Should I forget about php and try using node-firebird instead? It is
> working just fine so far.

I'd say, use what you're comfortable with. Personally, I would choose
Java/Kotlin over PHP or Node.js.

Mark
--
Mark Rotteveel

[Franz Fortuny L]

Thanks for your advise.

My http server is now taking care of requests, retrieving data from the SECOND server, which hosts nothing but Firebird 4.0.

The http server is an ARM64 machine. All I really needed to compile was interbase.so, which I already did and now it is connecting and doing all as expected.

The interbase.so for php 8.0 or 8.1 had not been compiled for ARM64 machines.

node-firebird for nodejs was easy to install. It is working just fine.

In the future, as per your information, I will use the development mail list or forum.

I have been using Firebird since year 2000. 2.0, 2.1, 2.5, 3.0, 3.0.3, 3.0.5, 3.0.7 and now 4.0. I had never had all the trouble encountered with 4.0, as far as maintenance is concerned.

Thanks again.

[AlexPeshkoff]

Were you using ARM64 machine to serve http requests when worked with FB 3.0.7?

BTW - FB2.0 was released in year 2006, not 2000.

воскресенье, 7 ноября 2021 г. в 20:56:39 UTC+3, ffor...@gmail.com:

[Mark Rotteveel]

I'm glad you managed to solve the problem.

On 07-11-2021 18:56, Franz Fortuny L wrote:
> In the future, as per your information, I will use the development mail
> list or forum.

To be clear, this is the right place to ask for support on Firebird.
However, asking about building Firebird yourself is not. Also, for use
of Firebird with PHP, there is the firebird-php Google Group[1].

> I have been using Firebird since year 2000. 2.0, 2.1, 2.5, 3.0, 3.0.3,

> 3.0.5, 3.0.7 and now 4.0. *I had never had all the trouble encountered
> with 4.0, as far as maintenance is concerned.*

The problem was not Firebird 4.0 itself, the problem was attempting to
use an amd64/x86-64 build on an aarch64/arm64 processor architecture.
You would have had the same or similar issues if you had attempted
install an amd64/x86-64 build of previous Firebird versions on that
aarch64/arm64 system.

[1]: https://groups.google.com/g/firebird-php
--
Mark Rotteveel