qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Huston <shus...@riverace.com>
Subject RE: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)
Date Tue, 16 Dec 2014 21:14:55 GMT
Hi Chris,

I don't have any insight into the gcc error. However, I've spent many years working on AIX
with C++. I've had my share of long and unfruitful nights dealing with gcc. IBM has people
involved with gcc and it still seems to have never-ending problems for some reason.

For my 2 cents, I recommend biting the bullet and going with xlC++.

-Steve Huston

From: Chris Whelan [mailto:Chris.Whelan@systemsandsoftware.net]
Sent: Tuesday, December 16, 2014 3:54 PM
To: users@qpid.apache.org
Subject: Compiling qpid on aix 6.1 with gcc 4.8.2 (or gcc 4.8.3)


We have been struggling mightily to get qpid to compile on aix 6.1 with gcc.  We have tried
both 4.8.2 and 4.8.3 and the error we have run into is:

/home/dbapi/enquesta_5_0/qpid-cpp-0.30/src/qpid/sys/posix/PosixPoller.cpp:796:2: internal
compiler error: in function_and_variable_visibility, at ipa.c:868
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: 1254-004 The error code from the last command is 1.

This appears to be a problem with gcc itself rather than qpid code, but since we are utilizing
the latest version of the gcc compiler I could find for aix and it still does not work, any
help in providing a workaround would be greatly appreciated.  My coworker was able to identify
the problematic lines.  Two of the errors appear to be related to the use of the PollerHandleDeletionManager
(Line 701 and 712) and  Event (Line 729)

PollerHandleDeletionManager.destroyThreadState();  (2 occurrences)
Event event = impl->eventStream.next(timeout);  (1 occurrence)

When he commented out those lines (and additional affected code in the case of the Event line),
the compilation of PosixPoller.cpp succeeded.  We surmised that it has something to do with
gcc handling of namespaces, but could not come up with a way to get around this issue.  We
are planning on trying IBM's xlc compiler, but we have invested a lot of time in this already
and would like to avoid xlc licensing costs if possible.

Thanks in advance,


Chris Whelan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message