January 2016 - Boost - lists.preview.boost.org

Ynt: Building Boost (1.60) with Clang and NDK
by Fatih Kıralioğlu 07 Jan '16

07 Jan '16

Ok, I am sharing my build.bat user-config-android.jam file below, from the outputs, clang is using mingw headers, for clang build, is mingw headers really necessary? build.bat: set CXXFLAGS="-I%ANDROID_NDK%/platforms/android-9/arch-arm/usr/include -I%ANDROID_NDK%/sources/cxx-stl/gnu-libstdc++/4.9/include -I%ANDROID_NDK%/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include" set TOOLSET=gcc-android b2 --toolset=%TOOLSET% --user-config=./user-config-android.jam cxxflags=%CXXFLAGS% threadapi=pthread --prefix=..\boost_android_arm --builddir=./ target-os=linux --with-date_time --with-filesystem --with-regex --with-log define=BOOST_FILESYSTEM_VERSION=3 --with-program_options --with-signals --with-system --with-thread link=static runtime-link=shared threading=multi install user-config-android.jam: androidNDKRoot = android-ndk-r10e ; # put the relevant path using clang : android : $(androidNDKRoot)/toolchains/llvm-3.6/prebuilt/windows-x86_64/bin/clang++ : <compileflags>--sysroot=$(androidNDKRoot)/platforms/android-21/arch-arm <compileflags>-Os <compileflags>-fno-strict-aliasing <compileflags>-O2 <compileflags>-DNDEBUG <compileflags>-g <compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/include <compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include <compileflags>-D__GLIBC__ <compileflags>-D__ANDROID__ <compileflags>-D_GLIBCXX__PTHREADS <compileflags>-D__arm__ <compileflags>-D_REENTRANT And I'am getting this error: g++: error: unrecognized command line option '-stdlib=libc++' clang++.exe: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) "android-ndk-r10e/toolchains/llvm-3.6/prebuilt/windows-x86_64/bin/clang++" -o "bin.v2\libs\date_time\build\clang-linux-andr oid\release\target-os-android\threadapi-pthread\threading-multi\libboost_date_time-clang-mt-1_60.so.1.60.0" -Wl,-soname -Wl,libboost_date_time-clang-m t-1_60.so.1.60.0 -shared -Wl,--start-group "bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-mult i\gregorian\greg_month.o" "bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\gregorian\greg_ weekday.o" "bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\gregorian\date_generators.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -stdlib=libc++ -lc++_shared -Landroid-ndk-r10e/sources/cxx-stl/llvm-libc++/libs/ar meabi ...failed clang-linux.link.dll bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\libboost_da te_time-clang-mt-1_60.so.1.60.0... ...skipped <p..\boost_android_arm\lib>libboost_date_time-clang-mt-1_60.so.1.60.0 for lack of <pbin.v2\libs\date_time\build\clang-linux-android\release \target-os-android\threadapi-pthread\threading-multi>libboost_date_time-clang-mt-1_60.so.1.60.0... clang-linux.compile.c++.without-pth bin.v2\libs\system\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\error_cod e.o In file included from libs\system\src\error_code.cpp:16: In file included from .\boost/system/error_code.hpp:19: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\ostream:38: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\ios:42: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\bits/ios_base.h:39: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\ext/atomicity.h:35: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include\bits/gthr.h:148: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include\bits/gthr-default.h:48: android-ndk-r10e/platforms/android-21/arch-arm/usr/include\pthread.h:164:58: error: unknown type name 'clockid_t'; did you mean ' clock_t'? int pthread_condattr_getclock(const pthread_condattr_t*, clockid_t*) __nonnull((1, 2)); ^ c:/mingw/include\time.h:71:14: note: 'clock_t' declared here typedef long clock_t; Fatih KIRALİOĞLU R&D Engineer fatih.kiralioglu(a)sestek.com www.sestek.com ________________________________________ Gönderen: Fatih Kıralioğlu Gönderildi: 6 Ocak 2016 Çarşamba 21:13 Kime: boost(a)lists.boost.org Konu: Ynt: [boost] Building Boost (1.60) with Clang and NDK Thanks for the responses, The last error I got is: "In file included from libs\date_time\src\gregorian\greg_weekday.cpp:16: In file included from libs\date_time\src\gregorian/greg_names.hpp:14: In file included from .\boost/date_time/gregorian/greg_month.hpp:14: In file included from .\boost/shared_ptr.hpp:17: In file included from .\boost/smart_ptr/shared_ptr.hpp:35: In file included from .\boost/smart_ptr/detail/spinlock_pool.hpp:25: In file included from .\boost/smart_ptr/detail/spinlock.hpp:47: In file included from .\boost/smart_ptr/detail/spinlock_gcc_arm.hpp:12: In file included from .\boost/smart_ptr/detail/yield_k.hpp:28: In file included from .\boost/predef.h:20: In file included from .\boost/predef/hardware.h:14: .\boost/predef/hardware/simd.h:77:5: error: "Multiple SIMD architectures detecte d, this cannot happen!" # error "Multiple SIMD architectures detected, this cannot happen!" " I have also installed and set it as an include dir for b2.exe to use clang and i got the error above fatih ________________________________________ Gönderen: Boost <boost-bounces(a)lists.boost.org> adına Ben Pope <benpope81(a)gmail.com> Gönderildi: 6 Ocak 2016 Çarşamba 19:06 Kime: boost(a)lists.boost.org Konu: Re: [boost] Building Boost (1.60) with Clang and NDK On Wednesday, January 06, 2016 04:06 AM, Fatih Kıralioğlu wrote: > Has anyone built the Boost with Clang and NDK other than CryStax? If so, can you post the related config.jam and build script? I have handled gcc build but clang is very very chalnllenging and no one including the guys in Stackoverflow could answer it. I haven't noticed any problems building boost for Android with the NDK, I honestly have no idea why I see so many people asking how to do it, or patch sets or whatever. I'm using gcc-4.9 and std=c++14 on linux x64 targeting armv7. I package the toolset I want (android 15, gcc-4.9) and pass that sysroot in the CXXFLAGS, I tend not to interfere with the build system of boost or android very much, preferring to drive everything from cmake (for my own projects). What problems have you seen? The NDK is moving entirely to clang, the next release will see gcc deprecated, so I'll have to have a play with moving over to clang, but in my experience, everything I do works equally well on clang for armv7, armv8 and x64. The only problem I remember having is thread locals on iOS targets, but my memory is short, and it only takes a few lines of code to emulate that for most purposes. If you explain what problems you've seen, which libraries, toolsets and command lines, perhaps you'll trigger a memory of a problem I've solved. I can give you more details of my configuration on the weekend, if required. As a sidenote, I'm hoping to bring up a boost/clang/linux/armv8 build bot if and when my Pine64 arrives and I get Ubuntu/Debian running on it (by April if all goes well). I have no idea how quickly it will cycle though, my current x64 tests take around 16 hours for gcc-4.9, gcc-5.2 and clang-3.7, I'll probably have to drop gcc-4.9. I had to give up on my regular sanitizer builds on x64 as they just take too long and there seemed to be very little interest. Unfortunately I don't have dedicated machines to run the tests. Ben _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[review][qvm] QVM formal review report
by Adam Wulkiewicz 07 Jan '16

07 Jan '16

Dear Boost community, The review period for Emil Dotchevski's QVM library has concluded. I'd like to thank everyone who participated in the discussions, esspecially those who sent formal reviews. Only four votes were casted: - 1 vote for acceptance * Rajaditya Mukherjee - 2 votes for conditional acceptance * Rainer Deyke * Oswin Krause - 1 vote for rejection * Phil Endecott However more people commented on issues on the mailing list. Comments received during the course of the review were generally positive, with a number of technical issues identified that need to be addressed. The review identified no fundamental problems in the design or implementation of the library that would entail rejection. The final version of the library can be fully accepted once Emil has addressed the issues identified during the review. Therefore I'm happy to say: Emil Dotchevski's Boost.QVM library is CONDITIONALLY ACCEPTED. Below is a summary of technical concerns: - The identifiers should be made more verbose. This is true both for function names as well as identifers containing "q"/"v"/"m" parts. The former should be replaced with full words, e.g. "transp" -> "transpose". The latter should be replaced at least with "qua"/"quat"/"vec"/"mat" respectively, so e.g. "v_traits" -> "vector_traits"/"vec_traits", "col_m" -> "col_mat", etc. - Many participants found the swizzling syntax using comma operator confusing or not good enough. There were many suggestions about the possible replacements: * v%XY - the old operator% syntax * (v,XY) - the comma operator syntax currently used by QVM * (v,asXY) - in order to limit potential conflicts with macros * XY(v) - function syntax, MOST PREFERED * v.XY() - probably the best but currently not possible (n4165, n4174) * ref(v).XY() * ref(v)[xy] * swizzle(v, xy) * ref(v)->xy The function syntax, i.e. XY(v), was the most prefered solution. Some of the participants appreciated the comma operator as well because of the similarity with shader languages syntax. The library could provide a few alternatives that could be picked by the user, e.g. both a comma and function syntax. - There were concerns regarding deduce_xx set of traits, in particular that traits taking two arguments (deduce_q2, deduce_v2 and deduce_m2) can cause ODR issues in a case when e.g. third-party libraries depending on QVM specialized these traits differently and those libraries were used together. There were no consensus if this is indeed a library issue or how this issue could be handled in general. Taking into account that the specialization of these traits is optional it'd be sufficient to describe the issue in the documentation and discourage the users from specializing those traits for types defined outside of their own code. - There was also a suggestion to use the same names that are already being used in other well-known libraries to make the interface more intuitive, e.g. mag() could be replaced by norm() (used in Eigen and Armadillo libraries), mag2() could be replaced by norm_squared() or norm_sqr(), etc. This would also make the latter more verbose. I'd let the decission how to deal with it to Emil. - Another suggestion was to replace read/write semantics with get/set semantics or at least to make the r/w/ir/iw identifiers more verbose. Here, I'd let the decission how to deal with it to Emil as well. - Aside from the issues described above, there were also suggestions that the scope of QVM library could/should be broadened to include functionalities from domains other than computer graphics, e.g. linear algebra, geometry, physics, robotics, etc. Oswin Krause requested that an consensus on the scope of the library should be made before the acceptance of the library. Phil Endecott expressed that the library is too small to be a standalone library. However as a Boost.Geometry developer I may say that the scopes, design rationales, internal structures, etc. of both libraries are different. AFAIK it's also true for Boost.Polygon. Furthermore, if my understanding is correct after reading various discussions the community finds the library useful even in the current state, some of the participants already used the library in their projects. Furthermore I'm sure that future users of QVM will suggest additions to the QVM library if they think it's necessary, so the scope will be broadened in a natural way. Though of course I encourage Emil to start a discussion with the community regarding this issue. - Regarding the documentation, various people suggested the following improvements: * it should start with a "Quick Start" page showing how to use the QVM built-in types to do some high-school linear algebra, * make it more obvious which functions are classified as "operations" and which are "view proxies", * contain more examples of every function as well as some bigger real-life examples. Please let me know if you think something is wrong. Regards, Adam

3 4

Building Boost (1.60) with Clang and NDK
by Fatih Kıralioğlu 06 Jan '16

06 Jan '16

Has anyone built the Boost with Clang and NDK other than CryStax? If so, can you post the related config.jam and build script? I have handled gcc build but clang is very very chalnllenging and no one including the guys in Stackoverflow could answer it. Many Thanks. Fatih

4 3

[multiprecision] Creation from a range
by Fernando Pelliccioni 06 Jan '16

06 Jan '16

Hi John, hi all, Is there any way to create an Integer (or a number) from a range (bounded or counted)?; or from a string_view (string_ref)? Roughly speaking, something like: XintXXX_t make_from_bounded_range(I f, I l); XintXXX_t make_from_counted_range(I f, size_t n); If not exist, I can make a contribution, are you interested? Thank you very much and best regards, Fernando Pelliccioni.

3 3

[gsoc16] Re: Potential contribution scenarios?
by Miguel Coimbra 06 Jan '16

06 Jan '16

> It is not hard to find either myself or Antony. Both of us are here, > and both of us are at the top of Google search results for our names. Probably my bad, I only bumped into LinkedIn references. I'll wait for a reply from Antony as well, thanks. I will explore other ideas as well. > 1. A thing Boost really could do with is a decent (optionally > mmappable) dense hash map implementation, so the hash map could > contain billions of items and mostly reside on disk yet lookups would > still be very fast. I have some questions regarding this first idea. I believe a concept and implementation already exist and are actually in use at Google: http://goog-sparsehash.sourceforge.net/doc/dense_hash_map.html Quoting from that page: ** dense_hash_map is distinguished from other hash-map implementations by its speed and by the ability to save and restore contents to disk. On the other hand, this hash-map implementation can use significantly more space than other hash-map implementations, and it also has requirements -- for instance, for a distinguished "empty key" -- that may not be easy for all applications to satisfy. This class is appropriate for applications that need speedy access to relatively small "dictionaries" stored in memory, and for applications that need these dictionaries to be persistent." ** So what you want is something like this, but able to "contain billions of items and mostly reside on disk yet lookups would still be very fast"? I assume the "billions of items" is what is lacking from that dense_hash_map already in use by Google? Is this the difference between that and your idea? Assuming this is indeed what you were proposing, would the work encompass defining an API and also exploring mmap for lazy iteration for performance gains in the context of handling billions of items? Kind regards, Miguel E. Coimbra

2 1

Hi! Want to Contribute
by shubham tibra 06 Jan '16

06 Jan '16

Hello everone, I am Shubham Tibra, a student of IIT KHARAGPUR, INDIA and new to open source community. I can code in C, C++ and I would like to contribute in Boost C++ Libraries. Can someone help me in getting started? Thanks in advance.

2 1

Regarding Contribution to boost C++ Libraries
by Kanika Midha 06 Jan '16

06 Jan '16

Hello All, I am a third year undergraduate student. I am new to open source and I want to participate in GSOC with Boost C++ Libraries. Can anyone guide me on how to move forward with this. Thanking You, With Best Regards, Kanika Midha

2 1

C++Now 2106 Call for Submission
by Jon Kalb 06 Jan '16

06 Jan '16

Boost Developers, The Call for Submissions for C++Now 2016 (AKA BoostCon) has been released: http://cppnow.org/2016-conference/announcements/2015/11/17/call-for-submissi on.html The deadline for submitting is very near and cannot be extended, so don¹t delay your submission. The conference will be held in Aspen the week of May 9th. See you in Aspen! Jon

4 3

[Locale] MSVC 2015 facets issue
by Artyom Beilis 04 Jan '16

04 Jan '16

Hello, Today I had a discussion on this ticket https://svn.boost.org/trac/boost/ticket/11878 There was a basic issue with Boost.Locale that couldn't format numbers at all properly, after back and forth it was discovered an issue with MSVC library. https://svn.boost.org/trac/boost/ticket/11878#comment:10 What is the best way to address this issue (open a bug there is no github issue tracker on this :-) ... Thank You, Artyom Beilis

3 3

GSoC project Concurrent Hash Tables
by Shangtong Zhang 04 Jan '16

04 Jan '16

Hi Niall Douglas, I’m a senior student and want to take part in GSoC 2016. I’m interested in the project Concurrent Hash Tables in GSoC 2015 ideas, is it still available in GSoC 2016? I just found some links are invalid in the project description https://svn.boost.org/trac/boost/wiki/SoC2015 <https://svn.boost.org/trac/boost/wiki/SoC2015> Thanks, Shangtong Zhang, Senior Student, School of Computer Science, Fudan University, PRC.

2 1