These are chat archives for bluescarni/piranha

7th
Feb 2016
Francesco Biscani
@bluescarni
Feb 07 2016 00:31
@isuruf sorry just came back, been away all day
sounds awesome, thanks for taking the time to look into this!
I think this is the report of the failing build right?
So the problem is here:
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/as.exe: CMakeFiles\base_series_multiplier.dir\base_series_multiplier.cpp.obj: too many sections (66067)
The too many sections error message was fixed by the big object flag in MinGW, which I noticed you removed
Francesco Biscani
@bluescarni
Feb 07 2016 00:37
unfortunately I think that the -mbig-obj flag has to stay if we want to be able to do debug build testing
awesome that the Release build works, great job!
Isuru Fernando
@isuruf
Feb 07 2016 02:37
@bluescarni, for Release building, I had to remove serialization_perf because it segfaults. Probably a Bzip2 error.
I removed -mbig-obj because of an earlier error, I'll enable it and see
Francesco Biscani
@bluescarni
Feb 07 2016 02:58
@isuruf ok great, thanks for looking into it
I actually never tested the bzip2 part on windows, as it was added after the last time I tried mingw compilation
Isuru Fernando
@isuruf
Feb 07 2016 02:59
@bluescarni, does GCC 4.9.1 support -mbig-obj?
Francesco Biscani
@bluescarni
Feb 07 2016 03:00
I am not entirely sure, it definitely worked when I tried last May but I cannot remember the mingw version right now
which mingw64 package are you using?
I can boot up windows tomorrow and tell you precisely
Isuru Fernando
@isuruf
Feb 07 2016 03:02
x86_64-4.9.1-release-posix-seh-rt_v3-rev1
Francesco Biscani
@bluescarni
Feb 07 2016 03:03
this is from the mingw-w64 official website?
Isuru Fernando
@isuruf
Feb 07 2016 03:03
yes
Francesco Biscani
@bluescarni
Feb 07 2016 03:05
https://sourceware.org/ml/binutils/2014-03/msg00110.html so it seems like it was added some time ago
and it's a linker flag so maybe the binutils version is the problem?
and this is a 64 bit build as well right?
Isuru Fernando
@isuruf
Feb 07 2016 03:06
yes
binutils is packaged with the mingw-w64 distribution right?
Francesco Biscani
@bluescarni
Feb 07 2016 03:07
yes that is my understanding... I think at the time I used the mingw-builds package, I am not sure if it coincides with what mingw-w64 publishes nowadays
but I'd be surprised if this feature wasn't available
is there a way to log into the VM in any capacity?
Isuru Fernando
@isuruf
Feb 07 2016 03:08
Yes, you can log in to the VM
Francesco Biscani
@bluescarni
Feb 07 2016 03:09
you have any pointers for that? I have never used appveyor
the other thing I can try is to reproduce the toolchain environment here and see if I can reproduce the issue
Isuru Fernando
@isuruf
Feb 07 2016 03:09
Do you have a remote desktop client like remmina?
Francesco Biscani
@bluescarni
Feb 07 2016 03:10
I think I have something like that for KDE, but I can install remmina if necessary
Isuru Fernando
@isuruf
Feb 07 2016 03:10
any remote desktop client would do.
started a new build. when the build fails, it will print out the credentials
https://ci.appveyor.com/project/isuruf/piranha/build/24/job/cibl66dh2nv358ni
Francesco Biscani
@bluescarni
Feb 07 2016 03:11
ok cheers... what is the protocol to use to log into the VM?
vnc, rdp, or else?
Isuru Fernando
@isuruf
Feb 07 2016 03:12
rdp
Francesco Biscani
@bluescarni
Feb 07 2016 03:12
ok should work then
is the VM going to stay up for a while?
Isuru Fernando
@isuruf
Feb 07 2016 03:13
1 hour from the start
Francesco Biscani
@bluescarni
Feb 07 2016 03:15
ah damn.. I think I will have to postpone to tomorrow as it's really late here... can I branch your branch and redo what you just did with that commit tomorrow or do you need to do it yourself?
Isuru Fernando
@isuruf
Feb 07 2016 03:15
you can do it yourself. you only have to add the project
Francesco Biscani
@bluescarni
Feb 07 2016 03:16
like travis then? ok awesome thanks
sorry about that, I really need to get to bed or tomorrow my son is gonna destroy me :) newborns sense the weakness and the tiredness and react accordingly :)
Isuru Fernando
@isuruf
Feb 07 2016 03:20
:D good night then. I also found it weird that you were up. It's morning over here
Francesco Biscani
@bluescarni
Feb 07 2016 03:22
:) I tend to stay up at night, not really a morning person, but with the baby here it's become more difficult
thanks a lot again for all the work, I'll hopefully be able to debug a bit tomorrow
have a nice sunday
:)
Francesco Biscani
@bluescarni
Feb 07 2016 09:42
@isuruf you there?
Francesco Biscani
@bluescarni
Feb 07 2016 09:50
nevermind I think I got the build queued on my branch
do you have any suggestion about good project settings for appveyor?
Francesco Biscani
@bluescarni
Feb 07 2016 11:28
@isuruf I think I am making some progress regarding the current debug build failure
adding the -Os flag to the build is enough to get base_series_multiplier linking without the "file is too large" issue, now I am trying to build the other tests from the remote desktop connection in order to see if more flags are needed
Isuru Fernando
@isuruf
Feb 07 2016 12:17
That's great.
Francesco Biscani
@bluescarni
Feb 07 2016 12:24
https://github.com/bluescarni/piranha/tree/appveyor there was also a problem with the monomial test that somehow was never triggered in linux builds, maybe it has something to do with boost changes
the VM shut down before I could finish testing, so now another build is running
let's see where it stops
@isuruf I kind of fiddled with appveyor setting to force testing on the appveyor branch, I will have to reset the settings to something more reasonable later... any suggestion/pitfalls in the setup?
Isuru Fernando
@isuruf
Feb 07 2016 12:34
All settings in the web interface can be done via appveyor.yml also. So, that's what I do. That way it allows the forks to run without any problem
Francesco Biscani
@bluescarni
Feb 07 2016 12:36
alright I will reset the web interface to the defaults later and use the configuration from the yml file then
Francesco Biscani
@bluescarni
Feb 07 2016 12:47
A couple of questions:
  • Boost_USE_STATIC_LIBS is this variable set by the FindBoost CMake macro?
  • any idea about the native() vs string() change you had to make to the perminov test?
is it related to the use of wchar_t vs char in native, as hinted here http://stackoverflow.com/questions/18366306/boostfilesystempathnative-returns-stdbasic-stringwchar-t-instead-of ?
Francesco Biscani
@bluescarni
Feb 07 2016 12:57
another random bit for the future (not needed right now): as far as I know we will need a shared library build of Boost when we start building/testing the Python bindings. Getting the libraries compiled as dlls should not be an issue, but I am thinking that maybe we will have to set some custom PATH variables in order to get the dlls located when running code linked against them
Isuru Fernando
@isuruf
Feb 07 2016 13:48
Boost_USE_STATIC_LIBS is not set by FindBoost. It's a variable for FindBoost to search for static libs which I give on the command line. This is a temporary fix and should be fixed.
Francesco Biscani
@bluescarni
Feb 07 2016 13:48
ahh ok I see
Isuru Fernando
@isuruf
Feb 07 2016 13:49
In MinGW 4.9.1 there was no implicit cast from wchar_t to char. Not sure about 5.3.0
Since we are installing boost into C:\mingw64\bin and it's already in the PATH
Francesco Biscani
@bluescarni
Feb 07 2016 13:54
ok
I am trying to workaround an internal compiler error in one of the tests
for some reason I cannot connect any more to the VM, might be some temporary glitch I hope
Isuru Fernando
@isuruf
Feb 07 2016 15:27
Yes, there was a glitch in appveyor build of symengine as well.
Francesco Biscani
@bluescarni
Feb 07 2016 15:27
yeah it seems to work now
I am still fiddling around with compiler flags and starting to split up big tests
it's gonna take a while before hopefully finding a setup that allows the whole test suite to run
The large tests often result in internal compiler errors and other shenaningans
I am hoping that by splitting in smaller parts the compiler manages to crunch through them
that's the approach I used to get the python bindings to compile in windows last year
at the very least now the polynomial test has been split in two parts, the travis timeout issue should be solved I hope
Isuru Fernando
@isuruf
Feb 07 2016 15:32
That's good.
You might want to package the MinGW distribution with gmp, mpfr and boost installed to save time.
One thing I can't figure out is if I install bzip2 into MinGW folder, there is a linker error
Francesco Biscani
@bluescarni
Feb 07 2016 15:33
might it be because there's another copy of bzip2 floating around the MinGW distribution?
Is there a copy of bzip2 already in MinGW?
Francesco Biscani
@bluescarni
Feb 07 2016 15:34
not sure.. but there should be a copy of GMP/MPFR somewhere, as GCC needs them
probably they are not usable from 3rd parties, I guess they are considered as internal libraries
that error message sounds like a linker path issue
Isuru Fernando
@isuruf
Feb 07 2016 15:35
Yes, gmp is included in gcc, but you can't use it for another library
Weird thing is CMake finds the Bzip2 library and seeing that it is in the linker's implicit directories uses -lbz2, but the linker can't find it
Francesco Biscani
@bluescarni
Feb 07 2016 17:31
ok I think this might work.. after the split in 2 files the poisson series test is finally compiling
next is the poly test
Francesco Biscani
@bluescarni
Feb 07 2016 18:00
@isuruf do you know about the -isystem GCC switch?
so basically that's a possible way to silence all the crap warnings coming from Boost
I don't get those under my build environment because Boost is installed as a system-wide package and thus common warnings are suppressed for it
but if you use Boost installed from a non-system directory you get all the warnings
https://cmake.org/cmake/help/v3.0/command/include_directories.html there is a SYSTEM argument to the cmake include macro
Isuru Fernando
@isuruf
Feb 07 2016 18:03
Boost warnings are a nuisance. if it works then we should add it.
Francesco Biscani
@bluescarni
Feb 07 2016 18:04
ok gonna give it a go in the next build attempt
Isuru Fernando
@isuruf
Feb 07 2016 18:07
Boost for some reason includes its headers in include\boost_1_60_0 instead of include\. If this was the case then headers would have end up in C:\mingw64\include which is a system directory
Francesco Biscani
@bluescarni
Feb 07 2016 18:11
you mean that the make install installs into C:\mingw64\include\boost_1_60_0?
Isuru Fernando
@isuruf
Feb 07 2016 18:12
yes b2 install
eg. C:/mingw64/include/boost-1_60/boost/mpl/aux_/integral_wrapper.hpp
Francesco Biscani
@bluescarni
Feb 07 2016 18:12
but then I would imagine it should be treated as system directory? because over here my boost includes are in /usr/include/boost and I don't get the warnings
I mean to say that I would expect all subdirs of a system directory are considered system directories themselves
Isuru Fernando
@isuruf
Feb 07 2016 18:14
@bluescarni, not really. You have to give C:/mingw64/include/boost-1_60 as a -I option because you include boost headers like boost/mpl/aux_/integral_wrapper.hpp
Francesco Biscani
@bluescarni
Feb 07 2016 18:15
ahhh my bad I did not see the extra boost/ directory!
in any case it seems a sensible thing to add the SYSTEM flag to boost includes, since it would also cover the use case of a local boost installation, e.g., in a user home dir
all those warning flags are there to debug Piranha not boost really :)
Isuru Fernando
@isuruf
Feb 07 2016 18:19
Good idea
Francesco Biscani
@bluescarni
Feb 07 2016 20:06
there's still some annoying warnings from #pragma directives, but I don't think we can shut those off
plus some GMP stuff, which I'll try to silence as well
Francesco Biscani
@bluescarni
Feb 07 2016 23:58
@isuruf so it seems like we are almost there: the debug build now finishes successfully! https://ci.appveyor.com/project/bluescarni/piranha/build/17
I am waiting for the test run now, but I already know there's at least one issue with the bz2 library
the test series_03 at least (possibly others) will not run, apparently when the executable starts it looks for libbz2.dll and it does not find it