These are chat archives for symengine/symengine

30th
Jun 2015
Isuru Fernando
@isuruf
Jun 30 2015 05:39
Nope. curl branch is on top of cmake branch
Isuru Fernando
@isuruf
Jun 30 2015 05:48
You can use this to download if you are in a proxy, https://gist.github.com/isuruf/291f1175a518fb27f574
Sumith Kulal
@Sumith1896
Jun 30 2015 06:55
Also in travis for clang cases
I don't have to add CC=clang and CXX=clang++, right?
they are the compilers by default, or are they not?
Sumith Kulal
@Sumith1896
Jun 30 2015 07:11
Made edits to Travis tests, have a look Sumith1896/csympy@62b25eb
Isuru Fernando
@isuruf
Jun 30 2015 07:52
@Sumith1896, why are you building clang?
Sumith Kulal
@Sumith1896
Jun 30 2015 07:53
Sorry @isuruf some of your comments got erased, let's converse here
Because I tried other configurations, it failed
Isuru Fernando
@isuruf
Jun 30 2015 07:53
What were the failures?
Sumith Kulal
@Sumith1896
Jun 30 2015 07:53
As per the leet fix, they install clang too
It didn't link to iostream and cctype headers
Not found or something like that.
Wait I have the build reports
Check the gmp installation part
Isuru Fernando
@isuruf
Jun 30 2015 08:03
I have no idea how to resolve those
Shall I stop the travis builds?
Sumith Kulal
@Sumith1896
Jun 30 2015 08:03
Ohh yes stop
I am running on my fork
The last commit might seem like a jump they are mostly taken from how they were fixed in leet
Isuru Fernando
@isuruf
Jun 30 2015 08:05
When I don't want to build in sympy travis, what I do is push to a separate branch in my fork, so that the pull request doesn't get updated
Sumith Kulal
@Sumith1896
Jun 30 2015 08:05
Will do next time on.
Also for cmake I dont have to give clang as compiler right?
Isuru Fernando
@isuruf
Jun 30 2015 08:10
Nope
clang picks up the compiler from $CC
Sumith Kulal
@Sumith1896
Jun 30 2015 08:11
Also one doubt
we run cmake, make and make install
before we give the compiler flags
which are done below, how does that work?
Isuru Fernando
@isuruf
Jun 30 2015 08:12

We don't need to give compiler flags to cmake, because UserOverride.cmake has the default flags.

Flags used below are used to compile a test program with the installed symengine library without cmake, to make sure make install works correctly

Sumith Kulal
@Sumith1896
Jun 30 2015 08:13
Okay, but does that use stdlib=libc++ over stdlib=stdlibc++?
If not, I have to pass stdlib=libc++ as a CXXFLAG
Isuru Fernando
@isuruf
Jun 30 2015 08:17
you need to pass libc++
Sumith Kulal
@Sumith1896
Jun 30 2015 08:30
Does the changes in test_travis in this commit look good:sympy/symengine@62b25eb ?
Isuru Fernando
@isuruf
Jun 30 2015 08:31
For make you don't need to give the flags
Sumith Kulal
@Sumith1896
Jun 30 2015 08:32
For cmake?
CXXFLAGS="-Werror" cmake "-stdlib=libc++" $cmake_line ${SOURCE_DIR}
Looks fine?
Sumith Kulal
@Sumith1896
Jun 30 2015 08:35
The -std=c++11 flag doesn't interfere with this, right?
Isuru Fernando
@isuruf
Jun 30 2015 08:36
Nope
Sumith Kulal
@Sumith1896
Jun 30 2015 08:36
Also in gmp installation should CXXFLAG be passed at configuration or make?
Isuru Fernando
@isuruf
Jun 30 2015 08:36
Not sure about that. At configuration time would be better
@certik, I updated the curl branch in github.com/isuruf/sage with symengine wrappers as well.
You can test it by downloading symengine-0.1.tar.gz here and putting it into upstream folder
https://drive.google.com/file/d/0B1xdAm0dyMndQjliYVZTbEVTRmM/view?usp=sharing
Sumith Kulal
@Sumith1896
Jun 30 2015 08:39
Are we having a release?
Isuru Fernando
@isuruf
Jun 30 2015 08:41
Not yet, that was just for testing
Sumith Kulal
@Sumith1896
Jun 30 2015 08:43
Cool
Isuru Fernando
@isuruf
Jun 30 2015 08:50
Did you try with giving cxxflags to configure script of gmp?
Sumith Kulal
@Sumith1896
Jun 30 2015 08:53
Yes, working on it now
Sumith Kulal
@Sumith1896
Jun 30 2015 09:06
@isuruf there?
Isuru Fernando
@isuruf
Jun 30 2015 09:07
yep
clang++ is not taking in libc++
don't know why!
Basically g++ doesn't accept libc++
clang should
Isuru Fernando
@isuruf
Jun 30 2015 09:23
That's because libc++ was not installed
Sumith Kulal
@Sumith1896
Jun 30 2015 09:24
it was installed, I ran an echo statement just to ensure it falls in the right if-else construct
I think I am not getting you
Isuru Fernando
@isuruf
Jun 30 2015 09:26
The following NEW packages will be installed:
  dietlibc-dev libc6-armel-cross libc6-armhf-cross libc6-dev-armel-cross
  libc6-dev-armhf-cross libgcc1-armel-cross libgcc1-armhf-cross libklibc-dev
  libowfat-dietlibc-dev libpurelibc-dev libpurelibc1
  linux-libc-dev-armel-cross linux-libc-dev-armhf-cross
The following packages will be upgraded:
  libc-bin libc-dev-bin libc6 libc6-dev linux-libc-dev
Sumith Kulal
@Sumith1896
Jun 30 2015 09:27
yes, just noted statements like this Note, selecting 'libc-dev' for regex 'libc++-dev'
Doesn't happen locally
why does this happen, I have no clue. Workarounds?
I think I have a workaround, let me try
Isuru Fernando
@isuruf
Jun 30 2015 09:32
libc++-dev is only for ubuntu 13.10 and above
travis uses ubuntu 12.04
Sumith Kulal
@Sumith1896
Jun 30 2015 09:32
Yes, now on I'll build from source
Sumith Kulal
@Sumith1896
Jun 30 2015 09:48
Building from source fixes that for now
Now I am getting same problems as @certik was getting I think
Sumith Kulal
@Sumith1896
Jun 30 2015 09:56
So I am positive about this passing as clang links are all fine, should be fixed if sympy/symengine#486 is fixed
@isuruf What do you suggest?
Sumith Kulal
@Sumith1896
Jun 30 2015 10:05
These two lines worry me for now
-- The C compiler identification is Clang
-- The CXX compiler identification is Clang
Why no mention of Clang++ ?
Sumith Kulal
@Sumith1896
Jun 30 2015 10:18
This is also what I suggested in sympy/symengine#491.
Could somebody explain this to me?
Isuru Fernando
@isuruf
Jun 30 2015 11:23

Look at the full log, it says

-- The C compiler identification is Clang
-- The CXX compiler identification is Clang
-- Check for working C compiler: /usr/local/clang-3.4/bin/clang
-- Check for working C compiler: /usr/local/clang-3.4/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/clang-3.4/bin/clang++
-- Check for working CXX compiler: /usr/local/clang-3.4/bin/clang++ -- works

Last line means, cmake is using clang++ and it points to a working CXX compiler.

#491 is a bug in the documentation

Sumith Kulal
@Sumith1896
Jun 30 2015 11:44
Okay what do I do for the build breaks, same as #486
Ondřej Čertík
@certik
Jun 30 2015 14:58
@Sumith1896 can you push in a patch fixing this: https://github.com/sympy/symengine/pull/484#discussion_r33581644 ?
Isuru Fernando
@isuruf
Jun 30 2015 15:00
@certik, https://github.com/Sumith1896/csympy/tree/catchtravis, this has some more things he tried
Summary is, he managed to get clang to compile and used it to build symengine.
Build breaks with #486. I patched it with a compiler option and then it failed with "cxxabi.h" not found
Ondřej Čertík
@certik
Jun 30 2015 15:02
Hm, I am looking at sympy/symengine#484, the latest patch that I can see there is 01f54284ed3e8546d9ea8663bf95f9323cb3f2b7
So this need to be pushed in, then we can talk about other failures. Or am I missing something?
Isuru Fernando
@isuruf
Jun 30 2015 15:04
Yes, it needs to be pushed in
Ondřej Čertík
@certik
Jun 30 2015 15:05
Can you post a link to cxxabi.h not found? I want to see the build log, as well as the commits.
It looks like libc++ is not being picked.
But let me see first.
we can also do make VERBOSE=1 to see exactly what's going on.
Ondřej Čertík
@certik
Jun 30 2015 15:06
Is @Sumith1896 still up? If not, let me create a new PR and get this resolved. We need to merge soon, so that we can continue working.
Isuru Fernando
@isuruf
Jun 30 2015 15:07
Don't know. It's just 2036h here. I think he'll be back
Ondřej Čertík
@certik
Jun 30 2015 15:07
@isuruf can you push in make VERBOSE=1 ?
This will tell us the exact command that clang was invoked with.
Isuru Fernando
@isuruf
Jun 30 2015 15:07
sure
Ondřej Čertík
@certik
Jun 30 2015 15:08
This seems to be a common problem, see e.g.: JuliaLang/julia#5669
Looks like clang is not installed properly.
I looked at what you did here: https://github.com/sympy/symengine/compare/master...isuruf:catch, and I think we are not installing the proper libc++ for the given clang. Let me see what clang version Travis has and how they recommend to install libc++.
Isuru Fernando
@isuruf
Jun 30 2015 15:11
Pushed it in. Will let you know once it is run
$ clang --version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Ondřej Čertík
@certik
Jun 30 2015 15:12
Cool. Let's see how to find the proper libc++.
Check out this answer here: http://stackoverflow.com/a/30925448/479532, updated today...
(see the comments to it as well)
Ondřej Čertík
@certik
Jun 30 2015 15:20
they say that essentially we need to install a newer gcc, so that clang uses a newer libstdc++.
then it will actually compile fine with a newer libstdc++.
Isuru Fernando
@isuruf
Jun 30 2015 15:24
To move to docker, we need to get bfd and ecm, whitelisted
Ondřej Čertík
@certik
Jun 30 2015 15:24
We can run without bfd
And we can install ECM from source, just like we do on OS X
Isuru Fernando
@isuruf
Jun 30 2015 15:26
in that case, let me try with it as well
Ondřej Čertík
@certik
Jun 30 2015 15:36
@isuruf here is an idea. It looks like the underlying problem is that the default installation of clang on Travis on Linux is not able to properly compile our code which uses C++11, because the libstdc++ installation that it finds is too old. It works on OS X though. Why don't we disable the failing test and merge?
Isuru Fernando
@isuruf
Jun 30 2015 15:36
Ondřej Čertík
@certik
Jun 30 2015 15:36
Our code will still be tested with clang on OS X. I think that's good enough.
and then we can figure out how to properly install clang on linux, either with newer libstdc++ or with libc++.
This message was deleted

That error is:

[  7%] Building CXX object symengine/teuchos/CMakeFiles/teuchos.dir/Teuchos_TypeNameTraits.cpp.o
cd /home/travis/build/isuruf/symengine/build/symengine/teuchos && /usr/local/clang-3.4/bin/clang++    -Werror  -std=c++11 -Wall -Wextra -fPIC -stdlib=libc++ -D__extern_always_inline=inline -g -Wno-unused-parameter -ggdb -I/home/travis/build/isuruf/symengine/build/symengine/teuchos -I/home/travis/our_usr/include    -o CMakeFiles/teuchos.dir/Teuchos_TypeNameTraits.cpp.o -c /home/travis/build/isuruf/symengine/symengine/teuchos/Teuchos_TypeNameTraits.cpp
/home/travis/build/isuruf/symengine/symengine/teuchos/Teuchos_TypeNameTraits.cpp:49:12: fatal error: 
      'cxxabi.h' file not found
#  include <cxxabi.h>
           ^
1 error generated.

Which seems properly compiled. Thus the libc++ must be incompatible with the given clang-3.4.

That might actually fix it.
Isuru Fernando
@isuruf
Jun 30 2015 15:43
That's what Sumith used I think
Ondřej Čertík
@certik
Jun 30 2015 15:46
Isuru Fernando
@isuruf
Jun 30 2015 15:51
I'm trying first with docker. Then I'll try that
Btw, docker queuing time is very slow and we should definitely use it
Ondřej Čertík
@certik
Jun 30 2015 15:53
For sure. It also doesn't use too much of Travis resources.
Ondřej Čertík
@certik
Jun 30 2015 15:58
Let's see if this works: sympy/symengine#492, if so, we should merge it.
Isuru Fernando
@isuruf
Jun 30 2015 16:54
@certik, you there?
Ondřej Čertík
@certik
Jun 30 2015 16:55
Yes.
Isuru Fernando
@isuruf
Jun 30 2015 16:55
installing g++-4.8 along with clang fixed the issues
Ondřej Čertík
@certik
Jun 30 2015 16:58
Cool!
Let's use that approach then.
Can you create a PR?
Isuru Fernando
@isuruf
Jun 30 2015 17:00
Sure. I need to turn off mismatched-tags warnings.
Which is better -Wno-mismatched-tags or -Wno-error=mismatched-tags
Ondřej Čertík
@certik
Jun 30 2015 17:02
The first one.
Shouldn't we rather fix the code?
Isuru Fernando
@isuruf
Jun 30 2015 17:03

Warning is from

template<>
    struct hash<SymEngine::Basic>
    {
        std::size_t operator()(const SymEngine::Basic& b) const
        {
            return b.hash();
        }
    };

To replace struct with class, but when I do that, there's another warning to replace class with struct

/home/travis/build/isuruf/symengine/symengine/basic-inl.h:75:5: error: 'hash'
      defined as a struct template here but previously declared as a class
      template [-Werror,-Wmismatched-tags]
    struct hash<SymEngine::Basic>
    ^
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_bvector.h:523:31: note: 
      did you mean struct here?
    template<typename> friend class hash;
vs
/home/travis/build/isuruf/symengine/symengine/basic-inl.h:75:5: error: 'hash'
      defined as a class template here but previously declared as a struct
      template [-Werror,-Wmismatched-tags]
    class hash<SymEngine::Basic>
    ^
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/functional_hash.h:58:5: note: 
      did you mean class here?
    struct hash;
Ondřej Čertík
@certik
Jun 30 2015 17:08
I see --- it's a bug in the header files.
Sure, disable it for now.
Sumith Kulal
@Sumith1896
Jun 30 2015 17:11
Sorry to off for a bit.
I tried a lot of different configs. and discussed with @isuruf
Good to see that there is a fix.
Sumith Kulal
@Sumith1896
Jun 30 2015 17:16
Let me know if I can be of any help
@isuruf's fix looks good
Sumith Kulal
@Sumith1896
Jun 30 2015 17:30
Does anybody actually use clang in linux?
Isuru Fernando
@isuruf
Jun 30 2015 17:37
@certik, -Wno-mismatched-tags does not turn off the flags
@Sumith1896, yes
Sumith Kulal
@Sumith1896
Jun 30 2015 17:37
@isuruf Thanks, I was just wondering :smile:
Ondřej Čertík
@certik
Jun 30 2015 17:39
@isuruf just leave the warnings be, i.e. on Clang on linux, remove the -Werror flag, but keep it there for all the other builds.
Submit it and lets get it merged.
We can tweak these little things later.
Sumith Kulal
@Sumith1896
Jun 30 2015 17:40
+1
Ondřej Čertík
@certik
Jun 30 2015 17:40
The general idea is to make warnings as errors in order for the tests to fail. As long as we do that for most builds, we are fine.
Ondřej Čertík
@certik
Jun 30 2015 18:09
@isuruf ping me when you post the PR.
Sumith Kulal
@Sumith1896
Jun 30 2015 18:09
@certik One minor thing
Isuru Fernando
@isuruf
Jun 30 2015 18:09
I will ping once I get it working fully
Ondřej Čertík
@certik
Jun 30 2015 18:09
ok!
Thank you for working on that, this has been a blocker. I am excited about improving the Travis tests to use docker.
Sumith Kulal
@Sumith1896
Jun 30 2015 18:10
Sorry, blocked cause of me :smile:
Isuru Fernando
@isuruf
Jun 30 2015 18:13
Done
One issue is that the OS X tests are going to be run as linux on forks and they do not have updated clang on them. So, those tests are going to fail in the forks, but not in the main repo
Sumith Kulal
@Sumith1896
Jun 30 2015 18:15
Yes, even I noticed this
@isuruf I think you can cancel other in queue temporarily
Sumith Kulal
@Sumith1896
Jun 30 2015 18:20
So that we can get it in quickly
Sumith Kulal
@Sumith1896
Jun 30 2015 20:05
Just realized that you can't do it, SymPy ones will be in queue too :smile:
Ondřej Čertík
@certik
Jun 30 2015 23:31
I posted #492 8h ago, and the tests didn't even start... That's why we have Shippable.