On 29 November 2013 10:41, Alex Peshkoff <peshk...@mail.ru> wrote: > On 11/29/13 13:41, Dmitrijs Ledkovs wrote: >> On 29 November 2013 07:16, Alex Peshkoff <peshk...@mail.ru> wrote: >>> On 11/28/13 22:52, Dmitrijs Ledkovs wrote: >>>> On 28 November 2013 18:26, Leyne, Sean <s...@broadviewsoftware.com> 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? >
There is no network access on Ubuntu Distribution builders, and we don't have QA ARM64 machines. So yeah, it needs to be in the tarball, match the tarball release version, and preferably be executed upon invoking "make check". How else, one would know the binaries one re-compiles still work?! >> >>>>> 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. > In that case someone should pick-up & adapt my patch. I did a patch against 2.5.2 as current in the current Ubuntu release to unblock building a handful reverse dependencies. ARM64 is upcoming and highly viable server platform and I'd hope firebird developers are interested in enabling it. More so, ARM64 is better supported than some of the targets/platforms supported by 2.5.2. And I don't have time to work on trunk, nor deal with issues that trunk may have, and since code base is different patches on trunk wouldn't have helped my cause. i don't plan to be involved in firebird development. here is a patch =) do as you like with it. Regards, Dmitrijs. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
