Fails to build with LLVM

[sebhtml]

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix

Reported-by: François Olivier Gagnon-Hébert francois-olivier.gagnon-hebert.1@ulaval.ca

[sebhtml]

Shaun Jackman also reported this:

https://gist.github.com/sjackman/8106970

[sebhtml]

Reported-by: Bede Constantinides [bede.constantinides@manchester.ac.uk] Reported-by: sjackman@bcgsc.ca

[sebhtml]

Ray is fine with clang 3.3 in Fedora.

[seb@krazy-5 Ray-2.3.0]$ module use ~/modulefiles/

[seb@krazy-5 Ray-2.3.0]$ module load openmpi/1.6.5-1-llvm

[seb@krazy-5 Ray-2.3.0]$ mpicxx -showme clang++ -I/home/seb/software/openmpi/1.6.5-1/include -pthread -L/home/seb/software/openmpi/1.6.5-1/lib -lmpi_cxx -lmpi -ldl -lm -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl

[seb@krazy-5 Ray-2.3.0]$ clang++ --version clang version 3.3 (tags/RELEASE_33/final) Target: x86_64-redhat-linux-gnu Thread model: posix

[sebhtml]

[seb@krazy-5 Ray-2.3.0]$ hostname krazy-5 [seb@krazy-5 Ray-2.3.0]$ pwd /home/seb/ray-test/Ray-2.3.0 [seb@krazy-5 Ray-2.3.0]$ ./Ray -version Ray version 2.3.0 License for Ray: GNU General Public License version 3 RayPlatform version: 2.0.0 License for RayPlatform: GNU Lesser General Public License version 3

MAXKMERLENGTH: 32 Maximum coverage depth stored by CoverageDepth: 4294967295 MAXIMUM_MESSAGE_SIZE_IN_BYTES: 4000 bytes FORCE_PACKING = n ASSERT = n HAVE_LIBZ = n HAVE_LIBBZ2 = n PROFILER_COLLECT = n MINIRANKS = y CLOCK_GETTIME = n linux = y _MSC_VER = n GNUC = y RAY_32_BITS = n RAY_64_BITS = y MPI standard version: MPI 2.1 MPI library: Open-MPI 1.6.5 Compiler: GNU gcc/g++ 4.2.1 Compatible Clang 3.3 (tags/RELEASE_33/final) MPI I/O: n

[sebhtml]

This is due presumably to the stdlib library on Mavericks.

http://comments.gmane.org/gmane.science.biology.ray-genome-assembler/820

[sjackman]

Ray 2.2.0 builds fine on Mavericks.

[sebhtml]

Hi Shaun,

I checked the code and it is a overloaded operator>> on a Ray class. But from the error message, it look likes it is trying to overload operator<< with uint64_t.

Ray 2.3.0 has some new code for merging seeds and the code associated to the compilation error was not in Ray 2.2.0.

The problem is that I can't reproduce the issue since I don't have access to Mac Mavericks.

From your gist, I think the problem could be solved by making the call unambiguous.

The problem:

code/SeedingData/PathHandle.cpp:66:9: error: use of overloaded operator '>>' is ambiguous (with operand types 'ostream' (aka 'basic_ostream') and 'const uint64_t' (aka 'const unsigned long long')) stream >> handle.m_value;

This is the code:

ostream & operator >>(ostream & stream, const PathHandle & handle) { stream >> handle.m_value; return stream; }

• stream is an ostream
• handle.m_value is a uint64_t.

So I don't see how "stream >> handle.m_value;" is ambiguous, right ?

seb

[sjackman]

Hi, Sebastien. Have you tried making the PathHandle(const uint64_t & value) construct explicit?

https://github.com/sebhtml/ray/blob/master/code/SeedingData/PathHandle.h#L40

    explicit PathHandle(const uint64_t & value);

The implicit conversion from uint64_t to a PathHandle is causing the grief, I believe.

code/SeedingData/PathHandle.cpp:65:11: note: candidate function
ostream & operator >>(ostream & stream, const PathHandle & handle) {
          ^
code/SeedingData/PathHandle.cpp:66:9: note: built-in candidate operator>>(int, unsigned long long)
        stream >> handle.m_value;

Cheers, Shaun

[sebhtml]

Hi Shaun, good idea. I did not know about this keyword.

Meanwhile, I though about removing the friend operators (which break encapsulation of the class anyway) and to use a distinct variable to pull/push the internal value for the path handle.

Furthermore, thanks to your comment, I spotted a problem:

The prototype is:

ostream & operator >>(ostream & stream, const PathHandle & handle);

but handle can not be const since operator>> will change it. (and I wonder why this worked in the first place).

[sebhtml]

And operator>> should obviously take a istream (and return istream, not ostream).

[sebhtml]

I tried the explicit keyword, but I am getting a bunch of error due to assumed implicit casts in the code.

[sebhtml]

I wrote a toy example with a similar code and it works.

https://gist.github.com/sebhtml/8669188

[sebhtml]

I think I solved the issue of compiling Ray on Mavericks.

Adding explicit caused too much colaterals.

The problem was that I did not include any istream classes (like fstream or sstream or iostream) in PathHandle.cpp.

So Mavericks was right to complain.

Thanks a lot for your expertise and help for this issue on the Mac platform.

[sebhtml]

patch against f7dc4c839cb3bd8eb912854d6c95b888d5393afb

https://gist.github.com/sebhtml/8670728/raw/58b42ea608a656191726ff45da7cb97230132d89/fix.patch

[sebhtml]

https://github.com/sebhtml/ray/commit/605b6fcb6952e706ecfbbdd9f67e89577bed7a42

[sebhtml]

community will test the change.