Re: [Firebird-devel] Fwd: ARM64 port

[Alex P. <pes...@ma...>]

On 11/29/13 13:41, Dmitrijs Ledkovs wrote:
> On 29 November 2013 07:16, Alex Peshkoff <pes...@ma...> wrote:
>> On 11/28/13 22:52, Dmitrijs Ledkovs wrote:
>>> On 28 November 2013 18:26, Leyne, Sean <Se...@br...> wrote:
>>>> Dmitrijs,
>>>>
>>>>> I've enabled ARM64 build of firebird2.5 in ubuntu.
>>>>> I don't have access to arm64 machines and hence i have no idea if it actually
>>>>> runs =) it does compile though.
>>>> While it is good that you worked on the port.
>>>>
>>>> If you don't have an platform to test, why would you bother with the effort?
>>>>
>>> The reason it's not tested, it's because I've never used firebird =)
>>>
>>> Hence the instructions on how to use chroot with qemu-static based
>>> emulation to test firebird on, if one wishes to try out ARM64.
>>> Furthermore since binaries are compiled, one can boot into foundation
>>> model (free of charge to download) and test it there as well.
>>>
>>> Are there any sort of testsuites for firebird that I can execute? It
>>> doesn't look like any are compiled or run at Debian/Ubuntu package
>>> build time.
>> We have 2 testsuites - official:
>> http://sourceforge.net/p/firebird/code/HEAD/tree/qa/, svn checkout
>> svn://svn.code.sf.net/p/firebird/code/qa/
>> and historical:
>> http://firebird.cvs.sourceforge.net/viewvc/firebird/fbtcs/?pathrev=B2_5_Release
>> (be aware 8 tests in the end fail)
>>
>> I've used to work with both of them on Ubuntu 12.04. QA requires python
>> and kinterbasdb installed, fbtcs requires nothing in addition to tools
>> one is using to build firebird.
>>
>>> E.g. postgresql package executes hundreds of test cases at build-time,
>>> to verify that what has been compiled actually works.
>> Not sure how are ubuntu packages are built, but suppose it's possible to
>> run QA after the build. There are also >900 tests.
>>
> Are those test cases shipped part of the tarball?

No. Are there any problems using version control systems?

>
>>>> Further, if you can't test, wouldn't it be ill-advised/dangerous to take the patch (which usually implies/requires that the change has been tested)?
>>>>
>>> Please look at my patch. It doesn't actually add or modify any code.
>>> All it does is add boiler plate defines.  It is equivalent of
>>> "autoreconf -f -i", which all what's needed for majority of portable
>>> software packages out there. Why is autoconf not used? (one doesn't
>>> need to use automake, one can use autoconf stand-alone to do
>>> target/feature discover - e.g. endianess, required libraries to link,
>>> etc)
>>>
>>>
>>> Are you saying Firebird is currently broken on all little-endian linux targets?
>> As far as I know it's OK. But there are may be issues on specific
>> platform. For example to build for Android (on ARM) we had to turn off
>> optimization - or even client hangs/segfaults very soon.
>>
> Well Android/Arm means bionic libc, which only has partial
> implementation of many calls (stubs that do nothing).

That's not due to libc. Issues with missing/stubbed calls in libc are 
the main reason we still do not have full port for Android (only client 
builds) but I do not think that they are related with bugs that are 
fixable with -O0 switch in g++. I highly suspect atomic ops but have no 
real facts.

>
>>> Not sure how can it be dangerous, the patch doesn't modify anything on
>>> any other target / architecture. And since Firebird doesn't exist on
>>> ARM64 yet, it can't possibly regress =)
>> If build completes that's already a kind of minimum test cause newly
>> built embedded engine is used during the build. Therefore I think we can
> Sounds good.
>
>
>> accept the patch provided it's done not for 2.5 only but also for trunk.
>>
> Does it not apply?
>

Definitely not.
Instead classes matching both hardware and OS we currently specify 3 
separate port characteristics: hardware, OS and compiler. Looks more 
complex but total list became much smaller. Certainly this makes changes 
in port required.