David Abrahams wrote:

For example, bug reports about an inability to configure with aCC (a compiler we never supported) from 2003 could be triaged into the circular file.

I don't know what those bug reports are, perhaps, about using boost with aCC3 on PA-RISC. Things have changed since 2003: see "HP-UX aCC6 V2" column on metacomm website (full view). Boris ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Cc: "Marshall Clow" <marshall@idio.com> Sent: Tuesday, December 19, 2006 3:26 PM Subject: Re: [boost] Support requests report

Marshall Clow <marshall@idio.com> writes:

...

[ Creeping up... ]

Support count: 50 29 nobody

Marshall,

I just went through and answered, closed, or assigned a few of these. You could probably do the same with several that are very obvious. For example, bug reports about an inability to configure with aCC (a compiler we never supported) from 2003 could be triaged into the circular file.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Boris Gubenko" <Boris.Gubenko@hp.com> writes:

In rule init-unix, python.jam defines system-specific libraries to link against. There are special cases for SOLARIS, OSF, ...etc, but not for HP-UX. As a result, HP-UX falls into default clause:

extra-libs = pthread dl util

I don't know which flavour of Unix has libutil library, but HP-UX does not. Because of this issue, python library tests py-run fail to link on HP-UX.

Attached patch fixes this issue. I ran 1.34 regression tests and verified, that python tests that previously would fail to link now succeed. I also verified, that the patch does not cause any regression. Please, apply it to HEAD and RC_1_34_0 branch.

Done, thanks! -- Dave Abrahams Boost Consulting www.boost-consulting.com

On Thursday 21 December 2006 00:41, Boris Gubenko wrote:

  On a Unix system, Boost.Build creates dynamic libraries with ".so" suffix. However, on HP-UX, the Python interpreter expects ".sl". Here is an excerpt from Python configuration script:

Notice that Python 2.5 on HP-UX/ia64 uses .so suffix. Teemu

Teemu Torma wrote:

Notice that Python 2.5 on HP-UX/ia64 uses .so suffix

I built Python 2.5, ran boost python library tests and they all passed except two tests which compile only in strict ansi mode (apparently, some issue with dependent name lookup in a default mode) and a test which fails for some unknown reason. I ran the tests with the original acc.jam which does not have .so -> .sl trickery. So, Python 2.5 does indeed solve the issue with file suffix. I'm running full 1.34 tests with Python 2.5 now, we'll see tomorrow. Thanks for your help. -boris

Sorry for using the wrong list. As for the question itself, Python 2.5 solves the problem with file suffix, so, I think, I'm all set. Thanks, Boris ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Sent: Friday, December 22, 2006 10:11 AM Subject: Re: [boost] [python] a problem with suffix for shared libraries onHP-UX

"Boris Gubenko" <Boris.Gubenko@hp.com> writes:

...

Is there a better solution to this problem?

You really ought to ask this question on the Boost.Build list.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Martin Ecker" <martin.ecker@gmx.net> wrote in message news:458B6BE1.1000203@gmx.net...

Hi,

Suman Cherukuri wrote:

...

Has anyone compiled (or tried to) Boost on Xenon (Xbox-360) platform?

If so, could you post the instructions on building Boost using VS-2005 for Xenon?

For the most part things "just work" since the Xbox compiler frontend is more or less VC++ 8.0. So most header-only libraries that do not depend on Win32-specifics work out of the box, such as smart_ptr, bind, function, and many others.

For libraries that need to be built you will probably have to make some modifications since by far not the entire Win32 API is supported on Xbox. Mostly you will have to replace #include <windows.h> to include the main XDK header file. This is pretty much all I needed to do to get the Boost.Threads library to build.

How do you specify the /MACHINE? Xbox 360 is Power PC and if I build it using vc-8_0 toolset, it is going to build for x86. Right?

Best regards, Martin

_______________________________________________ Unsubscribe & other changes:

http://lists.boost.org/mailman/listinfo.cgi/boost

With aCC6 on HP-UX, python library test data_members.cpp fails to compile with "more than one instance of overloaded function matches the argument list" error. x.cpp below is a reduced reproducer derived from data_members.cpp. The reason it fails to compile is that by default, aCC6 disables standard- compliant dependent template name lookup implemented by EDG in Version 2.44. The program does compile, with both aCC6 and "bare" EDG Front End Version 3.5, in strict ansi mode where "the 2-phase lookup of template names is performed as required by the standard" or when standard lookup is explicitly requested via -dep_name option -- see below. Other EDG-based compilers exhibit similar behaviour, in particular, Comeau C/C++ 4.3.8 and Intel's icc 9.0. Attached aCC6-specific patch for data_members.hpp disambigues function call in question by casting the argument, similar to the cast under the WORKAROUND macro in x.cpp below. With the attached patch, test data_members passes on HP-UX. I also verified, that the patch does not cause any regressions. Please apply it to CVS HEAD and the RC branch. Thanks, Boris x.cpp ----- namespace detail { struct not_specified {}; template <class D, class Policies> void make_getter(D* d, Policies const& policies, int); template <class D> void make_getter(D* d, not_specified policy, long) { #ifdef WORKAROUND detail::make_getter(d, static_cast<not_specified const&>(policy), 0); #else detail::make_getter(d, policy, 0); #endif } template <class D, class P> void make_getter(D& d, P& p, ...); } // namespace detail template <class D> inline void make_getter(D const& d) { detail::make_getter(d, detail::not_specified(), 0L); } const int i = 0; void compilability_test() { make_getter(&i); } cxxosf.zko.hp.com> eccp --version -c x.cpp Edison Design Group C/C++ Front End, version 3.5 (Dec 20 2004 13:57:48) Copyright 1988-2004 Edison Design Group, Inc. "x.cpp", line 11: error: more than one instance of overloaded function "detail::make_getter" matches the argument list: function template "void detail::make_getter(D *, const Policies &, int)" function template "void detail::make_getter(D *, detail::not_specified, long)" function template "void detail::make_getter(D &, P &, ...)" argument types are: (const int *, detail::not_specified, int) detail::make_getter(d, policy, 0); ^ detected during instantiation of "void detail::make_getter(D *, detail::not_specified, long) [with D=const int]" 1 error detected in the compilation of "x.cpp". cxxosf.zko.hp.com> eccp -c --dep_name x.cpp cxxosf.zko.hp.com> bash-2.03$ aCC -V aCC: HP C/aC++ B3910B A.06.14 [Dec 21 2006] bash-2.03$ aCC -c x.cpp "x.cpp", line 11: error #2308: more than one instance of overloaded function "detail::make_getter" matches the argument list: function template "void detail::make_getter(D *, const Policies &, int)" function template "void detail::make_getter(D *, detail::not_specified, long)" function template "void detail::make_getter(D &, P &, ...)" argument types are: (const int *, detail::not_specified, int) detail::make_getter(d, policy, 0); ^ detected during instantiation of "void detail::make_getter(D *, detail::not_specified, long) [with D=const int]" at line 21 1 error detected in the compilation of "x.cpp". bash-2.03$ aCC -c +dep_name x.cpp bash-2.03$