But the compiler needs to know about the existence of these functions. There aren't any "most-general" versions defined anywhere. If you're not including a graph implementation, there's no way the compiler can know about the interface.

You might be able to get around this by including the adjacency_matrix.hpp in your .cpp files before the headers that are using

the generic interface.

You're totally right. And thanks for your hint, as I think it is the right way to deal with this "problem?". Now the compiler doesn't complain about any of those functions. But I still get errors I can't find explanation for. Mainly, it complains when using BOOST_CONCEPT_REQUIRES to check for adjacency_matrix implementing BidirectionalGraphConcept. The error follows: /usr/local/include/boost-1_38/boost/concept_check.hpp:207: error: se solicitó la conversión desde ‘boost::adj_matrix_traversal_tag’ al tipo no escalar ‘boost::bidirectional_graph_tag’ In English, it means I asked for conversion from boost::adj_matrix_traversal_tag to nonscalar type boost::bidirectional_graph_tag. copy_graph also complains about not finding a suitable operator= when assigning vertex bundled properties from the adjacency_matrix to an adjacency_list. This is working when assigning from a bidirectional adjacency_list to a directed adjacency_list and, in fact, my vertex property bundle has an explicitly defined operator=, and my edge property bundle keeps the default byte-to-byte operator=. Any hints on what might be happenning? As I said in my last message, I can send the full error listing, if you need it. Thanks again, Juan

I just installed a Fedora 10 for x86_64 linux distribution. I need to build boost for this platform, but, with the "easy" build using configure and make install, it doesn't look to build for 64 bits platforms. In particular it doesn't find the 64-bit versions of the needed libraries. How can I build it?

After running configure, edit Makefile and set BJAM_CONFIG=address-model=64 F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

It still complains at compile-time that it can't find ICU shared libraries, but for the moment building in 64-bit mode looks to work. I'll see later if that's a problem. Thanks a lot :)

Yes I have the same issue but it has never been a problem to me, I do not know what it means: Building Boost.Regex with the optional Unicode/ICU support disabled F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

Here is the command I used to build regex with icu support on linux machine. I specified where is the icu library I installed instead of system library directory. ./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install The regex library I built is dependent on icu library. If you don't specify HAVE_ICU=1 then you don't need ICU_PATH either. Then the regex will not be dependent on icu library. You can't create a u32regex by calling make_u32regex to match or search unicode string. Hope my explain is helpful. Qihong On Thu, Apr 2, 2009 at 11:45 AM, Juan Antonio Farré Basurte wrote:

...

Yes I have the same issue but it has never been a problem to me, I do not

know what it means:

...

Building Boost.Regex with the optional Unicode/ICU support disabled

Oh, that is a different problem than mine. It means that you don't have ICU libraries (or it can't detect them). The only effect is that you cannot use unicode in regular expressions. You just have to install ICU (libicu and libicu-devel) libraries and it'll detect them automatically. For me, it just complains it cannot find the shared libraries, probably because it searches in /usr/lib and not /usr/lib64, but I don't know if that is a problem. Cheers,

Juan

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

I'm confused by your new question now. If you just feel the library is installed to the the wrong directory, by passing prefex to bjam should work. If your problem is on a x86_64 matchine and you are not doing cross compliation, but your boost library is 32 bits instead of 64 as default, because you found they are dependent on 32 bits libraries in /usr/local/lib. I'm not sure the real reason. You can try passing 'address-model=64 architecture=x86' to force bjam to build a library of 64. If it failed, the error message may tell you why it couldn't. Qihong On Thu, Apr 2, 2009 at 1:27 PM, Juan Antonio Farré Basurte wrote:

...

Here is the command I used to build regex with icu support on linux machine. I specified where is the icu library I installed instead of system library directory.

./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install The regex library I built is dependent on icu library. If you don't specify HAVE_ICU=1 then you don't need ICU_PATH either. Then the regex will not be dependent on icu library. You can't create a u32regex by calling make_u32regex to match or search unicode string. Hope my explain is helpful.

Now I'm correctly building 64-bit versions of the libraries, but they are still installed in /usr/local/lib. Is there a way to tell the installer to use /usr/local/lib64 instead?

Thanks,

Juan _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

It's not the prefix that is screwed up. It's the libdir, which he is claiming is hardcoded as `${PREFIX}/lib'. On x86_64 multilib systems, this should almost always be `${PREFIX}/lib64'.

For reference, the autoconf way to do this is by using:

./configure --prefix=/x --libdir=/x/lib64  

This answers my question. Thanks a lot :) Juan

The function multi_array::resize() returns a multi_array reference. Does it mean that resize can change the memory location of the current multi_array object?

No, the multi-array object it self does not change it position in memory, if you read the code it returns simply (*this) after swapping member fields with another object. But, what can change is the memory location of the actual data, since the data sometimes (always?) is reallocated and copied to the new location. That means that the return value of origin() (i.e. pointer to the first element in memory) can change after resize. Like you, I don't know why the author choose to return a reference to (*this) after resize. Maybe it is to be able to easily keep track of the pointer to memory, as follows boost::multi_array A(....); double* actual_data=A.origin(); ... actual_data=A.resize(...).origin(); But, to be honest, I don't know if this is compelling enough to actually provide such return behavior. Another reason to do this is that, suppose that you want to resize the matrix but you are not interested in keeping the elements as resize tries to do. If you use resize directly then there is a waste in copying elements that you are not interested in, then I am pretty sure that it doesn't try to copy elements if you do: boost::multi_array A(extents[5][5]); A.resize(extents[0][0]).resize(extents[10][10]); //equivalent to A.resize(extents[10][10]); but elements are not preserved. As I tell you, these are wild guesses, I wish one of the authors can explain the reason for that.

can I just do my_array->resize()

yes, this is enough in my opinion.

or I should do my_array=my_array->resize()

this is not necessary. Cheers, Alfredo

On Sat, 29 Aug 2009, Juan Antonio Farré Basurte wrote:

Hello, When I try to build boost 1.40, I get errors compiling MPI-related stuff. I'm working on a Fedora 11 64-bit system.

I set the following environment variables:

ICU_LINK='-L/usr/lib64' EXPAT_INCLUDE=/usr/include EXPAT_LIBPATH=/usr/lib64

The bootstrap command is:

./bootstrap.sh --libdir=/usr/local/lib64

I modify the project-config.jam to add using mpi ; The resulting file is attached.

Finally, the bjam command is:

./bjam variant=release address-model=64

I get error such as, for example,

...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.1/release/address-model-64/threading-multi/packed_skeleton_iarchive.o... gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.1/release/address-model-64/threading-multi/packed_skeleton_oarchive.o In file included from ./boost/mpi/detail/mpi_datatype_cache.hpp:14,                  from ./boost/mpi/datatype.hpp:28,                  from ./boost/mpi/packed_iarchive.hpp:22,                  from ./boost/mpi/skeleton_and_content.hpp:29,                  from libs/mpi/src/packed_skeleton_oarchive.cpp:11: ./boost/mpi/detail/mpi_datatype_oarchive.hpp: In member function ‘void boost::mpi::detail::mpi_datatype_oarchive::save_enum(const T&, mpl_::true_)’: ./boost/mpi/detail/mpi_datatype_oarchive.hpp:64: error: expected primary-expression before ‘enum’ ./boost/mpi/detail/mpi_datatype_oarchive.hpp:64: error: expected ‘;’ before ‘enum’

This is a known issue related to serialization of enums on many compilers. I believe it is being worked on, but your message shows another compiler and another user that is having trouble with the issue. -- Jeremiah Willcock

On Sat, 29 Aug 2009, Robert Ramey wrote:

It's not known to me. Make track item on this.

Robert Ramey

It is #3371 and #3372 in Trac already. -- Jeremiah Willcock

none reported. Robert Ramey Matthias Troyer wrote:

On Aug 29, 2009, at 7:08 PM, Jeremiah Willcock wrote:

...

On Sat, 29 Aug 2009, Robert Ramey wrote:

...

It's not known to me. Make track item on this.

Robert Ramey

It is #3371 and #3372 in Trac already.

These are Boost.MPI tickets and seem to be caused by bugs related to is_enum in the type traits library. Are there alreay bug reports for enums with Boost.Serialization?

Matthias