Still can't get the snapshot. I see "Generating snapshot..." and it takes forever.
For sure, when I get it, I'll run builds on AIX and HP and let you know.
Currently I'm working on build for Sun SPARC.

One detail - I don't have automake installed on HP, so I used directly ./configure. Could it be the reason why HAVE___THREAD definition was missed?


On Thu, Jun 19, 2014 at 8:48 AM, Alex Peshkoff <peshkoff@mail.ru> wrote:
On 06/17/14 19:51, vv m wrote:
> Hi All,
>
> I've built  FB from the source code (v. 2.5.2.26540-0) on HP-UX IA64
> (Itanium).
>
> This is my setup: HP-UX ia64, HP C/aC++ B3910B A.06.25
>
> My settings:
> export CC=cc
> export CXX=aCC
> export CFLAGS=+DD64
> export CFLAGS=+DD64
>
> ./configure --enable-debug=yes
>
> Resolving a few build issues, I've been able to build create_db, but
> similar to a situation which I had building FB on AIX (see corresponding
> discussion) it produced a core dump:
>
> Pid 14664 received a SIGSEGV for stack growth failure.
> Possible causes: insufficient memory or swap space,
> or stack size exceeded maxssiz.
>
> I checked corresponding system settings using kctune and swapinfo, and it
> looked OK.
> I started debugging and figure out that during creation of static object
> GlobalPtr<IntlUtil::Utf8CharSet> IntlUtil::utf8CharSet
> (.../jrd/IntlUtil.cpp), the assert fb_assert(keySet) is met at
> .../common/classes/fb_tls.h:129 during a call of TLS_GET macro at
> .../common/classes/alloc.cpp:300.
> Then this assert is supposed to be stored into the log, and during that
> TLS_GET called again, then, in turn assert happens again, etc. recursively.
> Finally, it kills the stack (I've attached a file with stack details).
>
> In my understanding, it happens 'cause TLS_GET uses FB's own implementation
> of TLS instead of the one provided by the system compiler.

That's not FB's own, that's posix standard functions. But I agree that
there was firebird bug, showing itself on RISC machines with compiler
missing __thread support.

> In file .../src/include/gen/autoconfig.h, corresponding macro is defined:
>
> /* Define it if compiler supports ISO syntax for thread-local storage */
> #define HAVE___THREAD 1
>
> which means that the system supports it.
>
> Also, there is another comment in fb_tls.h:
>
> #if defined(HAVE___THREAD)
> // Recent GCC supports __thread keyword. Sun compiler and HP-UX should have
> it too
> # define TLS_DECLARE(TYPE, NAME) __thread TYPE NAME
> # define TLS_GET(NAME) NAME
>
> But all this is in contradiction with definition in file
> .../src/common/classes/common.h:
>
> #if defined (__HP_aCC)
> // aCC error, __thread can be used only with C-like structs
> #undef HAVE___THREAD
> #endif
>
> Having that, my suggestion was to comment the line "#undef HAVE___THREAD".
> After that I've been able to finalize a build successfully and pass basic
> tests.

I've committed a fix for initial problem to B2_5. When you will be able
to access snapshot (BTW, tomorrow you can get it from FB site) please
also try clean build on HPUX if possible.



------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel