headers
Beman Dawes | 1 Aug 02:02
Picon
Favicon
Gravatar

Re: [PATCH]: filesystem: Shadow Variables Cause Warnings/Errors When Headers Are Not in System Path

Grant Erickson wrote:
> In working through cross-compilation issues with boost, particularly the
> filesystem library, I discovered the following error reproduced with the
> following test case with both boost 1.34.1 and 1.35.0:
> 
>     FAILS:
>         echo "#include <boost/filesystem.hpp>\nint main (void) { return (0);
> }" | g++ -o test -I/${BuildRoot}/results/boost/include -Werror -Wall
> -Wshadow -x c++ -
>     
>     PASSES:
>         echo "#include <boost/filesystem.hpp>\nint main (void) { return (0);
> }" | g++ -o test -I/usr/include -Werror -Wall -Wshadow -x c++ -
> 
> The failing case complains about 'what', 'path1' and 'path2' argument
> shadowing in boost/filesystem/path.hpp with respect to like-named member
> functions.
> 
> Since GCC does not enforce warning options on headers in /usr/include, this
> only shows up when building against a boost installation outside
> /usr/include, as in the above failure example.
> 
> The patch to address this is:
> 
> Signed-off-by: Grant Erickson <gerickson <at> nuovations.com>
> ---
> --- boost_1_35_0/boost/filesystem/path.hpp    2008-07-30 16:54:53.000000000
> -0700
> +++ boost_1_35_0/boost/filesystem/path.hpp.N    2008-07-30
> 16:59:42.000000000 -0700
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beman Dawes | 1 Aug 02:44
Picon
Favicon
Gravatar

Re: Boost.Endian missing integer_cover_operators.hpp

Seika van Olstroem wrote:
> Hello,
> 
> in 2000 and 2006 Darin Adler and Berman Dawes tried to get a library 
> called Boost.Endian into Boost, but it seems the process stopped 
> somewhere.
> 
> This library would help me a lot when working with different byte
> orders.
> 
> Here are the threads: 
> http://lists.boost.org/Archives/boost/2000/03/2495.php 
> http://lists.boost.org/Archives/boost/2006/06/106655.php
> 
> Using Google I've found a recent endian.hpp but I can't find 
> integer_cover_operators.hpp. 
> http://lists.boost.org/Archives/boost/att-105789/endian.hpp
> 
> Beman, what happend with Boost.Endian?

It stalled when I became convinced that C++ core language changes were
what was really needed. Work on Boost.Endian stopped while I shepherded 
proposals through the standards committee for C++0x. That's now done and 
reflected in the working draft of the standard.

I recently started to update Boost.Endian and could post a copy if you 
are still interested.

--Beman
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lothar Werzinger | 1 Aug 03:11

Re: [1.36.0 beta] Beta release available on SourceForge

There is a bug in the datetime library iostream operators

$ /opt2/linux/ix86/bin/g++-4.3.1 -I/opt2/linux/x86_64/include/boost-1_36 -o 
boost1 boost1.cpp; ./boost1; ./boost1 1; ./boost1 1 2; ./boost1 1 2 3
testing testInputIso ...
expected=2005
actual  =2005
expected=Sep
actual  =Sep
expected=30
actual  =30
expected=18
actual  =19
boost1: boost1.cpp:97: void testInputIso(): Assertion 
`(static_cast<int32_t>(18)) == (ldt.utc_time().time_of_day().hours())' 
failed.
Aborted
testing testInputIsoWide ...
expected=2005
terminate called after throwing an instance of 'boost::gregorian::bad_year'
  what():  Year is out of valid range: 1400..10000
Aborted
testing testOutputIso ...
expected=2005-09-30 19:25:17+01:00
actual  =2005-09-30 19:25:17+01:00
expected=2005-09-30 19:25:17-08:00
actual  =2005-09-30 19:25:17-08:00
testing testOutputIso OK
testing testOutputIsoWide ...
expected=2005-09-30 19:25:17+01:00
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrej van der Zee | 1 Aug 03:18
Picon
Favicon

boost_1.36 beta on AIX 5.3 with gcc 4.2.4: Compile errors in math

Hi,

Building on IBM AIX 5.3 with gcc 4.2.4 gives me the compile-time error below in math repeating itself
endlessly. No such problems for boost_1.35.

...failed gcc.compile.c++ bin.v2/libs/math/build/gcc-4.2.4/release/threading-multi/cbrt.o...
gcc.compile.c++ bin.v2/libs/math/build/gcc-4.2.4/release/threading-multi/copysign.o
In file included from libs/math/build/../src/tr1/copysign.cpp:7:
./boost/math/tr1.hpp:438: error: 'boost::math::tr1::expm1' declared as an 'inline' variable
./boost/math/tr1.hpp:438: error: 'long double boost::math::tr1::expm1' redeclared as different
kind of symbol
./boost/math/tr1.hpp:436: error: previous declaration of 'double boost::math::tr1::expm1(double)'
./boost/math/tr1.hpp:438: error: expected primary-expression before 'double'
./boost/math/tr1.hpp:438: error: expected `)' before 'double'
./boost/math/tr1.hpp:459: error: expected primary-expression before 'class'
./boost/math/tr1.hpp:460: error: 'T2' was not declared in this scope
./boost/math/tr1.hpp:460: error: '::type' has not been declared
./boost/math/tr1.hpp:467: error: expected primary-expression before 'class'
./boost/math/tr1.hpp:468: error: 'T2' was not declared in this scope
./boost/math/tr1.hpp:468: error: '::type' has not been declared
./boost/math/tr1.hpp:475: error: expected primary-expression before 'class'
./boost/math/tr1.hpp:476: error: 'T2' was not declared in this scope
./boost/math/tr1.hpp:476: error: '::type' has not been declared
./boost/math/tr1.hpp:553: error: expected primary-expression before 'class'
./boost/math/tr1.hpp:554: error: 'T2' was not declared in this scope
./boost/math/tr1.hpp:554: error: '::type' has not been declared
./boost/math/tr1.hpp:561: error: expected primary-expression before 'class'
./boost/math/tr1.hpp:562: error: 'T2' was not declared in this scope
./boost/math/tr1.hpp:562: error: '::type' has not been declared
./boost/math/tr1.hpp:611: error: expected initializer before '<' token
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Watanabe | 1 Aug 03:29
Picon

Re: boost_1.36 beta on AIX 5.3 with gcc 4.2.4: Compile errors in math

AMDG

Andrej van der Zee wrote:
> It seems that the compiler sees the two following functions as the same symbols, although the name slight
differs: 
>
> inline double expm1(double x)
> { return boost::math::tr1::boost_expm1(x); }
> inline long double expm1l(long double x)
> { return boost::math::tr1::boost_expm1l(x); }
> <snip>
> Well, there is a clear pattern. After prefixing the second function with __ makes the errors go away. Could
somebody enlighten me why this is?
>   

Does it work with

inline long double expm1l BOOST_PREVENT_MACRO_SUBSTITUTION(long double x)

In Christ,
Steven Watanabe
Permalink | Reply | 0 comments |
headers
Andrej van der Zee | 1 Aug 03:54
Picon
Favicon

boost_3.6 beta: Linking boost serialisation (and other libs) gives duplicate symbol on AIX 5.3 with gcc 4.2.4

Hi,

When (natively) linking on IBM AIX 5.3 after compiling with with gcc 4.2.4, I get the a bunch of
link-warnings like below for many libraries. It seems that the reason is that inline function are linked externaly:
http://www-1.ibm.com/support/docview.wss?uid=swg21044588

I am not sure what is the right way to solve the issue:
1) Force compiler to staticaly inline
2) Add the native AIX linker option: -bhalt:5 to suppress the warning
3) Explicitely declare inline functions static

For now, the first seems best to me. But I dont think there is such an option. Or is there?

Any other solutions?

Cheers,
Andrej

gcc.link.dll bin.v2/libs/serialization/build/gcc-4.2.4/release/threading-multi/libboost_serialization-gcc42-mt-1_36.so
ld: 0711-224 WARNING: Duplicate symbol: .virtual thunk to
boost::archive::archive_exception::what() const
ld: 0711-224 WARNING: Duplicate symbol: .virtual thunk to boost::archive::archive_exception::~archive_exception()
ld: 0711-224 WARNING: Duplicate symbol: .virtual thunk to boost::archive::archive_exception::~archive_exception()
ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to
boost::exception_detail::exception_clone<boost::exception_detail::error_info_injector<boost::archive::archive_exception>
>::release() const
ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to
boost::exception_detail::exception_clone<boost::exception_detail::error_info_injector<boost::archive::archive_exception>
>::add_ref() const
ld: 0711-224 WARNING: Duplicate symbol: .non-virtual thunk to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrej van der Zee | 1 Aug 04:06
Picon
Favicon

Re: boost_1.36 beta on AIX 5.3 with gcc 4.2.4: Compile errors in math

Hi,

> Does it work with inline long double expm1l BOOST_PREVENT_MACRO_SUBSTITUTION(long double x)

Yes it does. I found in total 4 instances of this error in the file ./boost/math/tr1.hpp. Shall I send a patch
or are you doing it by hand?

And uhhh, what triggered the error? I don't really get it....

Cheers,
Andrej

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
Permalink | Reply | 501 comments |
headers
Steven Watanabe | 1 Aug 04:19
Picon

Re: boost_1.36 beta on AIX 5.3 with gcc 4.2.4: Compile errors in math

AMDG

Andrej van der Zee wrote:
>> Does it work with inline long double expm1l BOOST_PREVENT_MACRO_SUBSTITUTION(long double x)
>>     
>
> Yes it does. I found in total 4 instances of this error in the file ./boost/math/tr1.hpp. Shall I send a
patch or are you doing it by hand?
>   

Please submit a patch.

> And uhhh, what triggered the error? I don't really get it....
>   

expm1l is defined as a macro somewhere.

In Christ,
Steven Watanabe
Permalink | Reply | 501 comments |
headers
Steven Watanabe | 1 Aug 04:38
Picon

Re: boost_3.6 beta: Linking boost serialisation (and other libs) gives duplicate symbol on AIX 5.3 with gcc 4.2.4

AMDG

Andrej van der Zee wrote:
> Hi,
>
> When (natively) linking on IBM AIX 5.3 after compiling with with gcc 4.2.4, I get the a bunch of
link-warnings like below for many libraries. It seems that the reason is that inline function are linked externaly:
> http://www-1.ibm.com/support/docview.wss?uid=swg21044588
>
> I am not sure what is the right way to solve the issue:
> 1) Force compiler to staticaly inline
>   

I don't like to force the compiler to behave in a way that is not
standard compliant.  Or do you mean to force the compiler to
actually inline all inline functions?  This is impossible for
virtual functions.

> 2) Add the native AIX linker option: -bhalt:5 to suppress the warning
>   

This is dangerous, since it may suppress real diagnostics, but at least
it is unlikely to break correct code.

> 3) Explicitely declare inline functions static
>   

This can violate the ODR.  It is out of the question as far as I am 
concerned.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Watanabe | 1 Aug 04:40
Picon

Re: [1.36.0 beta] Beta release available on SourceForge

AMDG

Lothar Werzinger wrote:
> There is a bug in the datetime library iostream operators
>   

So, why exactly is it a bug for "2005-09-30 19:25:17+01:00"
to yield 19 in the hours?  What am I missing?

In Christ,
Steven Watanabe
Permalink | Reply | 2 comments |

Gmane